Document: draft-eastlake-xmldsig-uri-07
Reviewer: Joel Halpern
Date: June 15, 2004 (at Last Call)

My guess is that this draft is basically ready for publication as a proposed standard, but has nits that should be fixed before publication.
The reason I have to guess is
1) This document is a summary of URIs, and I am not clear as to the value / purpose of the document.  But I presume that others have resolved that.
2) There are some questions that occurred to me during reading.  I believe that they are all easily resolved, but some of them are more than just nits.  They are the first block of questions below.


Some questions that occurred to mean when reading:
I presume that the w3c TR on XML Encryption is at a stability level such that the RFC Editor will allow a normative reference to it?

It seems that the normative reference in 2.4 to an algorithm documented only in a Proposed Standard RFC which has been superceded by a DS which does not include the algorithm would mean that this summary document can never advance past PS.  Does it really mean that, and if so is that our intent?

It seems strange in a document which starts out saying that it captures stuff declared elsewhere to suddenly find in section 3 "In section 3.1 below a new KeyInfo element child is specified."  Further, the use of the foo: namespace on the element, but simply xmlns= on the name space seems inconsistent (although I am not a sufficient XML name space expert to be sure this is wrong.)  Finally, the text earlier said that xmldsig-more was a base for URIs, not a name space itself.  But here it is used by itself?  And there is no "Identifier" in this section?

There appears to be inconsistency as to what the old URI base was.  In section 2, it is documented as http://www.w3.org/2000/09/xmldsig#.  That is what is used in section 2.4.  Then in section 3.2 and the IANA consideration section we find reference to http://www.w3c.org/2000/09/xmldsig-more#.  Was this intended to be just xmldsig or was it intended to be http://www.w3c.org/2001/04/xmldsig-more?

The IANA considerations section lists only one base URI, and says taht nothing more should be allocated under it.  I presume that the intent is taht nothing more be allocated under either URI called out in section 2, but it is hard to tell since there is only 1 value and it is hybrid of the two values in section 2.


There are some typographic artifacts which need to be fixed.
In section 2.1.1, the example of an MD5 DigestAlgorithm element probably is supposed to read:
     <DigestAlogirthm
        Algorithm="http://...
However, everything up to that opening quote is missing.

In section 2.3.1, the third text paragraph begins with the construct "Signature generation for the RSASSA-PKCS1-v1_5 signature scheme."  This construct is not a sentence.  I have no idea what words are missing, but something is.


And some minor comments, all basically about internal inconsistency:
Why is there no example for HMAC-RIPEMD160?  The reference to "as described in section 2.2.1" does not seem to explaining skipping the example that occurs in all other cases.

Why include the ASN.1 BER MD5 identifier explicitly, and then not include the ASN.1 BER identifiers for the other (recommended) public key signature algorithms?

Should 2.3.6 include one example of use, since 2.3.7 does?

Is there a reason that 2.6.1 does not include a description of the parameter to ARCFOUR, nor does it include the schema or DTD fragment declaring that KeySize takes an integer paramater, as was done with all earlier elements?

Shouldn't 2.6.3 include an example of use of Camellia Key Wrap?

In section 2.6.4 PSEC-KEM appears to have a lot of parameters.  Practice up to this point in the document was to describe the parameters.  This may be too complex to describe, but if so at least a sentence indicating that the definition of the XML parameters is in a specific place in a specific document would seem appropriate.