Document: draft-ietf-ltans-dssc-08.txt Reviewer: Miguel Garcia Review Date: 17 June 2009 IESG Telechat date: 18 June 2009 Summary: This draft is on the right track but has open issues, described in the review. Major issues: none Minor issues: - The draft lacks formality about the XML. I suspect no one from the XML directorate has reviewed this draft. I am trying to do my best, but I highly recommend that someone from the XML directorate reviews and provide additional comments to the XML. I also recommend the authors to read RFC 3470 and follow the guidelines described in there. - I am surprised to see that the namespace of the XML document is not in the IETF tree, but instead set to http://www.sit.fraunhofer.de/dssc. According to RFC 3470: In the case of namespaces in IETF standards-track documents, it would be useful if there were some permanent part of the IETF's own web space that could be used for this purpose. In lieu of such, other permanent URIs can be used, e.g., URNs in the IETF URN namespace (see [11] and [12]). Although there are instances of IETF specifications creating new URI schemes to define XML namespaces, this practice is strongly discouraged. Also please, consider RFC 3688, in which case, the namespace of the XML document should be: urn:ietf:params:xml:ns:dssc which, of course, MUST be registered with IANA (but this is another story described below). - Central to this document is the definition of the XML schema. I don't like to see the XML schema buried to a middle appendix, even when the appendix is classified as normative. The recommendation is to promote the XML schema to its own section, for example, between Sections 5 and 6. I would also move the complete XML example to its own section as well. - I am missing some normative text saying that implementations according to this specification MUST implement this XML schema. For your convenience, let me provide an example of other RFCs that have captured the text. You can adapt it to your document as you wish: DSSC is an XML document [xx] that MUST be well-formed and SHOULD be valid. DSSC documents MUST be based on XML 1.0 and MUST be encoded using UTF-8 [yy]. This specification makes use of XML namespaces for identifying DSSC documents. The namespace URI for elements defined by this specification is a URN [zz], using the namespace identifier 'ietf'. This URN is: urn:ietf:params:xml:ns:dssc Notice also the normative references to: [xx] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000. [yy] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [zz] Moats, R., "URN Syntax", RFC 2141, May 1997. which are also missing from this document. - Associated MIME type. Many IETF XML documents have an associated MIME type. Well, this depends on whether someone is going to use the MIME type or not. Assume you want to attach a DSSC document to a web page, e-mail, etc. In that case, a MIME type might be beneficial. If you need one, you should add the following text (after the previous comment): DSSC documents are identified with the MIME type "application/dssc+xml" and are instances of the XML schema defined in Section sss. - XML schema extensibility and Unique Particle Attribution Constraint. So, the first thing is that the XML schema does not offer any extensibility point, other than adding more parameter types. I don't know if there is an extensibility strategy behind, but I believe this XML schema will need to be extended in the future, perhaps with additional information parameters. Assume that you need to add, for example, the "reason" why an algorithm is no longer valid, a new element within the Algorithm element, a pointer to the certificate of the examiner, or something like that. Currently it is no possible to add these extensions. So, you should add hooks (e.g., elements) more often. However, you must be careful and bear in mind the Unique Particle Attribution Constraint rule to avoid ambiguity. - Have you validated your XML schema and the XML example with a suitable validator, for example, http://validate.openlaboratory.net/ ? I haven't done it myself, just prefer to ask first. - Section 3.4 provides a partial XML schema whose purpose is to hold a civic address. A question first... Why do you need to split the civic address into each of their components? Is it because an automata is suppose to read it, parse it, and point some address on a map (or something like that). If the information is merely be read by a human being, then it is much simpler to add a string element called
that can hold the full address in a human readable format without further subelements. But if you have requirements for automata parsing of the address, then the elements you have defined in the current
is FAR from being useful. For example, you cannot represent a Post Office Box. You cannot represent many complex civic address used in different places in this planet. The Geopriv WG went to the nightmare of representing all possible address in the world, and they failed at the first time. Presumably they have succeeded on their second attemp, so, I recommend you to read RFCs 4119 and 5139 and investigate whether you can import and reuse the civicAddress element defined there. - Section 3.7 defines the Usage element. It is currently a string, so, it seems like a free-format text intended for human consumption. Is this correct? If not, I would suggest an enumeration of possible values. So, what is the intended use of this Usage element? - Section 3.9 defines the AlgorithmIdentifier. I think the "Name" of the AlgorithmIdentifier cannot be a free format text (string). because it would be valid, but useless, to have, for example, different policies referring to "SHA1", "sha1", "SHA-1", and "sha-1". This is because implementations will recognize one or a subset of all the possible "free formats" for each algorithm. One possible solution is to say in the verbal text that possible values are those included in a registry. For example, if you were using cryptographic hash algorithms, then you could use the following registryt: http://www.iana.org/assignments/hash-function-text-names/ But in your examples, I've noticed that you are referring to other algorithms that are not listed there. You can try to find any other existing registry, or use one and extend it with new values. - Section 3.11 defines 3 elements, , , and . I don't understand why you need 3. I think you should need either or , but not all 3. Specially, says that it consist of a minimum and a maximum value. So can't you survive with and if you allow both to be present at a given time? Then you have the means to define a range. - I've noticed in Sections 3.14, 4, and 6 that there are many lower-case normative words, where it appears that they should be capitalized according to RFC 2119. For example: "The signature must relate to the SecuritySuitabilityPolicy element. " "... the SecuritySuitabilityPolicy element must have the optional id attribute" "This attribute must be used to reference the SecuritySuitabilityPolicy element... " "... the signature must use the transformation algorithm ..." "The parameter of RSA should be named "moduluslength". " "The parameters for DSA should be "plength" and "qlength"." "Publishers must ensure" "Operators should only accept" etc... Please consider the capitalization of those normative reserved words. - Section 6, the 2nd bullet point reads: "It must not be possible to alter or replace a security suitability once accepted by the client." Honestly, I don't understand how to implement this requirement. Which entity has to do what? - Section 7, IANA considerations, says that there are no actions to IANA. If my previous comments are accepted, then you need to add IANA considerations to register: + the XML schema + the URN Sub-Namespace + the MIME type