XML-Signature WG Last Call Comments [ ascii]

Donald Eastlake 3rd <>
Joseph Reagle Jr. <>
David Solo <>

This page links to comments/issues raised on the list during first (Feb 28 - March 28 / April 5); second (September 18 - October 20)  Last Call; Candidate REC,   and how it was resolved. A style sheet declaration is used to not render issues that are considered 'done'. This page is a follow-on to the Editors' Page which had most all oustanding issues resolved prior to going to last call. The source need not be the first isntance the issue was raised, it also might reference a cogent description or WG poll.

Resolutions are expressed as {email,minutes} » (resulting) draft

Issues Raised During First Last Call

Source Isssue Resolution
Karlinger/Reagle Spec still includes some text/definitions referring to the IDREF attribute. There should be no mention of IDREF, all references are via the URI attribute, local references are specified via URI="#foo". removed » /Drafts/WD-xmldsig-core-200003plc/
Reagle Need better treatment of <any/> within the elements with open content models. Schema Update   » /Drafts/WD-xmldsig-core-200005plc/
Karlinger Should we use ANY or #PCDATA to denote an open content model for an element type within a DTD. Re: DTDs and ANY  » /WD-xmldsig-core-20000510/#sec-CoreSyntax
Karlinger Error in 2.1 Simple example and add DSA element types fixed errors and added DSA element types.» /WD-xmldsig-core-20000510/#sec-DSA
Karlinger Typos /Drafts/WD-xmldsig-core-200003plc/: didn't grok parenthesis, but otherwise done.
Carl Wallace X509Dat a : 1) Why impose the choice over X509IssuerSerial, X509SKI and X509SubjectName in the definition of X509Data? Victoria#KeyInfo » /WD-xmldsig-core-20000510/#sec-KeyInfo
Karlinger Canonicalization of Fragments (and SignedInfo) : We need further specification w/rspt to Canonical XML as applied to the SignedInfo element.


Possible Resolution:

  1. Wrap a fragment in an element.
This issue is addressed in /WD-xml-c14n-20000601
Karlinger sec 6.3.1 (HMAC)  Add sentence that in the absence of that parameter there is no truncation. Eastlake » /WD-xmldsig-core-20000510/#sec-HMAC
Karlinger Sec. 7.1 contradicts XML 1.0 : Is whitespace preservered in elements? Change to core section 7.1  » /Drafts/WD-xmldsig-core-200003plc/:
Christian Geuer-Pollmann Comments on 28022000 draft: Wrong URL    /Drafts/WD-xmldsig-core-200003plc/: corrected
Christian Geuer-Pollmann Comments on 28022000 draft: Typos  
  • move SignatureProperty namespace to SignatureProperties.
/Drafts/WD-xmldsig-core-200003plc/: typos corrected
Carl Wallace KeyInfo questions/comments --(thread)-> Fox's response. Victoria#KeyInfo » /WD-xmldsig-core-20000510/#sec-KeyInfo
Peter M. Hesse  RE: KeyInfo questions/comments : Making KeyValue required does little good in  a trusted environment (fine line between mandatory to implement and support). Shouldn't let people think it is sufficient since it might not be trusted.

Possible Resolutions: Do we clarify that KeyValue is a hint? Reiterate difference between signature and trust validation?

  1. KeyInfo and KeyValue: Clarify: There is no requirement that the verifying implementation use the specific information contained within KeyInfo in the actual signature validation, although (as in CMS) we expect that for efficiency reasons implementations will likely try the included key information first before hitting a database to look for other potential keys to use to validate the signature.
  2. RE: KeyInfo and KeyValue . Fox: Do you (Carl) have a suggested alternative for KeyValue that is semantically neutral?  I agree that we need some explanatory text on DSA parameters, but the parameters cannot be omitted from KeyValue for cryptographic reasons discussed previously. There is no scenario using KeyValue in which the parameters can be left out.
Victoria#KeyInfo » /WD-xmldsig-core-20000510/#sec-KeyInfo
TAMURA Kent Comments on last call draft: Byte Order Marks, XPath processing, and attribute ordering. Boyer's 000406 Version , Victoria#C14N, Victoria#Xpath » /WD-xmldsig-core-20000510/#sec-XPath

Also, minimal is no longer required, but optional.

Jonathan Marsh and James Clark XSL WG comments on XML Signatures
  1. the XPath element does not appear to be in the DTD. An example would be useful.
  2. Without a context node, the XPath cannot be applied against an XML tree.
  3. It appears quite easy in this syntax (being XML) to allow the user to declare namespaces for use within XPaths. XSLT and XLink both provide this capability. Using namespace-uri() and local-name() hinders readability and impacts performance significantly.
  4. ...

Possible Resolution:

Boyer's 000406 Version . and Victoria#XPath » /WD-xmldsig-core-20000510/#sec-XPath


Eric Rescorla RetrievalMethod : RetrievalMethod is supposed to specify a way to retrieve the sender's public key. However, it's unspecified what will be retrieved by dereferencing the URI in question. Victoria#Retrieval » /WD-xmldsig-core-20000510/#sec-RetrievalMethod
Paul Biron
(Schema WG)
XML Schema WG response to the DSig Last Call WD requests that the XML Sig WG rewrite all schema(s) used in defining dsig in terms of the schema specification current when schemas reaches CR. updated to last call: /WD-xmldsig-core-20000510/
Additionally, there are several cases in which more judicious use could be made of Schema Datatypes. For instance, Section 4.2 "The SignatureValue Element" contains the actual signature octet sequence, base64 encoded--it is declared as a string, it should be a binary with the encoding facet equal to base64; new binary type created, we may opt to constrain string mime types in the future » /WD-xmldsig-core-20000510/#sec-CoreSyntax
Section 4.5 "The Object Element" has a MimeType attribute, declared as a string that could be declared as a subtype of string, with a pattern facet that matched all legal mime type variations. No one on the list has opted to specify this yet.
The Schema WG also suggests that the XML Sig WG consider using a mechanism similar to that proposed in [4] for assigning schema datatypes to element/attribute declarations in the dsig DTD. List : "...while it would make the DTDs more expressive, I don't think it would further the typing capabilities of a 'out of the box' DTD processor; and as we are describing the syntax with schema in parallel, it would probably be of limited utility for us to add this as a work item."
Lastly, the dsig WD should make clear whether the schema and DTD included in Section 9 are normative or informative. Victoria#normative » /WD-xml-c14n-20000601
Susan Lesch Re: minor typos in WD-xmldsig-core-20000228   Re: minor typos in WD-xmldsig-core-20000228   » /Drafts/WD-xmldsig-core-200003plc/:
Martin Duerst (I18N WG/IG) I18N WG/IG last call comments See Response Follow-Up for further discussion of some of these issues.

URIs: For URIs and URI references, add a convention as in (all W3C specs that use URIs in XML are doing this)

Re: I18N WG/IG last call comments » /WD-xmldsig-core-20000510/#sec-Reference
Negotiated content: Signed objects are indicated using URIs. It is unclear which object is to be signed in case the URI is content- negotiated (e.g. language-negotiated). Either there must be some mechanisms to provide negotiation parameters (difficult to do in general), or some warnings at least that negotiated resources should not be signed (which may be an undue restriction). In any case, this has to be discussed in the specification. ... "Applications should be cognizant of the fact that HTTP state and protocol information, (such as a cookies, device profiles or content negotiation), may affect the content yielded by dereferencing a URI." /Drafts/WD-xmldsig-core-200005plc/:
MimeType and Charset on Transform: The Transform element has optional MimeType and Charset parameters. This raises several questions and problems:
  • When obtaining a resource (via <Reference>), the resource is supposed to come with its own Type/Charset information. If this is not the case, then all kinds of operations just cannot be performed. This information is certainly available in http, and the 'charset' (encoding) information is available for XML even on protocols that do not provide meta-information. This raises the question of priority.
  • The charset information provided as explained above may in some cases be absent (e.g. in many cases for HTML over http), and in some cases may be wrong. This MUST NOT provide a reason for XMLSig to make the attributes on <Transform> have higher priority than the information provided in the protocol or in the resource itself. Otherwise, this would deteriorate efforts to make absolutely sure this information is present and available.
  • Content negotiation is an additional reason for why the 'charset' information should be taken from the resource/protocol itself, rather than from the
  • In any case, the priority of the various information sources has to be clearly specified. It may also be possible to say that an error occurs if the informations don't match.
  • Type and charset seem to be on Transform because it is unclear how this information would get from one transform to the other. Because this information has to get from the original resource to the first Transform, a processing model that doesn't allow passing such information from one Transform to another even if needed seems inappropriate. [the spec currently doesn't say what the processing model for the sequence of transforms is; making this clear would help us a lot to check whether it is appropriate for i18n or not [describing a processing model in the spec does not mean that all implementations have to follow it; it's okay if they do something else provided they produce the same results]] This should be changed so that these parameters are eliminated on <Transform>, and the necessary information is passed from transform to transform automatically. The parameters may then be moved to <Reference>.
  • Some transforms may need other parameters, while many transforms won't need Type or charset. At the moment, for example, there seems to be no proposed transform that would need MimeType. Also, the result of most transforms is of a very well defined type and in many cases also of a defined 'charset', and having to add this information on the next transform is error-prone. If the parameters are kept on Transform, it should be stated clearly that each transform definition has to define whether they are actually used, and (in particular for MimeType) for what.
  • We also discussed the question of whether it would be better to have both Type and charset in a single attribute, but we didn't reach a conclusion.
Victoria#MimeType and Revised core section MimeType and Charset removed » /Drafts/WD-xmldsig-core-200005plc/:
Character encoding and transcoding: [Transcoding is the conversion from one character encoding (charset) to another.]
  • 'minimal' canonicalization is required, but it should be made very clear that this does not imply that conversion from all 'charset's to UTF-8 is required. A set of 'charset's for which support is required should be defined exactly, e.g. as UTF-8 and UTF-16. This is the same for other transforms.
  • There should be a clear and strong warning and an official non-guarantee in the spec about conversions from legacy 'charset's (i.e. encodings not based on the UCS) into encodings based on the UCS (i.e. UTF-8, UTF-16,...). The problem is that while for most 'charset's, all transcoder implementations produce the same result for almost all characters in these 'charset's, the number of 'charset's where all transcoding implementations behave exactly the same is rather limited. As an example, in "Shift_JIS", the 'charset' used on Japanese PCs, about 10 to 15 special characters are transcoded differently on Windows, on the Mac, and by Java.
  • Part of the above warning should be to recommend UTF-8 and UTF-16 to be used for the original documents, and to recommend to use numeric character references (e.g. &#xABCD;) for cases where differences are known.
  • We discussed the idea of having a transform that just does transcoding. This would allow to separate various issues clearly.
Re: I18N WG/IG last call comments , /WD-xmldsig-core-20000601/   » (these issues can be better addressed in the C14N spec) /WD-xml-c14n-20000601
Choice of Element names: There is a 'Transforms' element and a 'Transform' element. This is difficult to distinguing even for English speakers. For people used to languages without singular/plural distinctions, it will create even more confusion. We ask you to change 'Transforms' to something like 'TransformList'. Victoria#Internationalization :"It is suggested that we change Transforms to TransformList, SignatureProperties to SignaturePropertyList, etc., for easier understanding. Participants appreciate concern but consensus at meeting is not to change due to existing examples and code.
Individual Transforms
  • Both Base64 and Quoted-Printable are provided as encoding transforms. For Quoted-Printable, the only reason given is "Quoted-printable is provided, in addition to base-64, in keeping with the XML support of a roughly human readable final format.". We have serious doubts that this is really useful in the context at hand; if several transform steps are used, it should be enough that the data before applying base64 is readable, and in all the examples given, base64 is only applied to calculated numbers/hex sequences, which are not very readable either way. So we request to remove Quoted-Printable.
Victoria#QP : "Consensus to Drop Quoted Printable. It appears not to perform any function which could not be met with entities." » /WD-xmldsig-core-20000510/
Individual Transforms
  • XPath transform [Please note: there has already been discussion on the list about this with the XSL WG. The comments below are included to make sure they can be formally answered.]
  • The XMLSig draft contains some provisions to deal with the fact that input and output infrastructure (e.g. the equivalent of is missing in XPath. In particular, the evaluation context includes two variables: $exprEncoding: a string containing the character encoding of the XPath expression $exprBOM: a string containing the byte order mark for the XPath expression; set to the empty string if the document containing the XPath expression has no byte order mark. and makes these available to the XPath expression. The spec also says: "The XPath implementation is expected to convert all strings appearing in the XPath expression to the same encoding used by the input string prior to making any comparisons."
  • This should be changed so that: - The spec clearly says that all XPath operations have to work as if they were implemented in UCS (to conform to Conversion from the input encoding of the XPath expression and from the input encoding of the actual object are assumed to occur implicitly. This would also resolve the question of what lexicographic ordering to use in the output. - The encoding of the output be clearly specified as one of the following: - always, or by default, UTF-8 - always, or by default, the encoding of the input object - specifiable as a parameter to the 'serialize()' function. (We would prefer always UTF-8; this reduces implementation effort) - The above variables be scrapped. While the information is relevant to the XPath engine, it is in no way relevant to the XPath expression. 
Boyer's 000406 Version , Victoria#C14N, Victoria#Xpath: We believe the current specification addresses these issues » /WD-xmldsig-core-20000510/#sec-XPath

... The above considerations have led us to the conclusions below. We hope that you can help us with your experience on security issues to check them.

  • Make sure that the transforms defined do not *require* NFC. (any XML processor, and any transforms based on it, are always *allowed* to to do normalization, see the definition of 'match' in the XML spec).
Boyer's 000406 Version , Victoria#C14N, Victoria#Xpath: » /WD-xmldsig-core-20000510/#sec-XPath
(Reagle: I don't think any of our transforms require)
  • Provide a transform that *checks* for NFC. The transform fails if the input is not in NFC. If the transform succeds, the output is exactly the same as the input. [this is a bit different from the average transform, but fits very well into the general model].
Re: I18N WG/IG last call comments » /WD-xmldsig-core-20000601/
  • Advise users (and provide examples) to use this transform after e.g. Canonical XML, to avoid missing interactions between numeric character references and NFC.
Re: I18N WG/IG last call comments » /WD-xmldsig-core-20000601/
  • Advise users to provide their data in NFC (just to reinforce the general recommendation), and stress the importance of this in the context of digital signatures. - Provide a transform that actually does NFC, for cases where this is desirable, but add the necessary warnings.
Re: I18N WG/IG last call comments » /WD-xmldsig-core-20000601/
Various comments and non I18N comments. /Drafts/WD-xmldsig-core-200005plc/:
Hallam-Baker, EKR XML as (string versus nodes) and partial decomposition. Victoria#C14N : Making C14N REQUIRED, minimal optional.
Bartel, Lipp Using an algorithm identifier to represent a specific XPath transform for embedded signatures. Victoria#Identifier : agree to do it if we can write the proper XPath » /WD-xmldsig-core-20000601/
Lipp Why not remove the whole signature? (instead of just bits of the signature). Victoria#Identifier : agree to remove the whole Signature element.
Martin Duerst (I18N WG/IG)

added (000627)

Followup on I18N Last Call comments and disposition

It is not clear what "signature application" means. If this means an application that produces signatures, we do not understand the sentence in the last paragraph of 7.0 which recommends that such applications produce normalized XML. *** It has to be cristal-clear that no actual normalization should occur in connection with any signing calculation. The current text is not clear enough.

Proposed : We RECOMMEND that signature applications create XML content (Signature elements and their descendents/content) in Normalized Form C [NFC] and check that any XML being consumed is in that form as well (if not, signatures may consequently fail to validate).
  A note should be added explaining the security problem mentioned in our Last Call comments. **** E.g. in Section 8, at a convenient location (e.g. 8.1), add something like: Using character normalization (Normalization Form C of UTR #15) as a transform or as part of a transform can remove differences that are treated as relevant by most if not all XML processors. Character normalization should therefore be done at the origin of a document, and only checked, but never be done during signature processing. Re: Followup on I18N Last Call comments and disposition»/WD-xmldsig-core-20000711/: Includes new section on "See What You Sign".
  We insist on not providing character normalization as a transform. We do not insist that character normalization checking is provided as a transform. Ok.
  Editorial: in 7.0, avoid "coded character set", use "character encoding". *** These are two different concepts! Yes, it's a character encoding scheme. Re Followup... » /WD-xmldsig-core-20000711/:
  It should be mandated that, when a document is transcoded from a non-Unicode encoding to Unicode as part of C14N, normalization must be performed (At the bottom of section 2 and also in A.4 in the June 1st 2000 draft). **** Unicode-based encodings are e.g. UTF-8 and UTF-16. In most cases, the transcoding result is normalized just by design of Normalization Form C, but there are some exceptions. **** The above also applies to other transcodings, e.g. done as part of the evaluation of an XPath transform or the minimal canonicalization. C14N:

Also proposed to be added to 6.5 of Signature:

When a document is transcoded from a non-Unicode encoding to Unicode as part of C14N, normalization SHOULD be performed

accepted ( with suggested tweaks)

  In 4.3.3, the text on URI-Reference and "non-ASCII" characters should be alligned with that in XPointer to make sure all the details are correct. accepted ( with suggested tweaks)

Proposed: 4.3.3 The Reference Element

... The set of characters for URIs is the same as for XML, namely [Unicode]. However, some Unicode characters are disallowed from URI references: all non-ASCII characters and the excluded characters listed in Section 2.4 of [IETF RFC 2396], excluding the number sign (#) and the percent sign (%); and excluding the square bracket characters re-allowed in [IETF RFC 2732]. Disallowed characters must be escaped as described in section 4.1.1 URI Reference Encoding and Escaping of [XPtr]:

  1. Each disallowed character is converted to UTF-8 [IETF RFC 2279] as one or more bytes.
  2. Any octets corresponding to a disallowed character are escaped with the URI escaping mechanism (that is, converted to %HH, where HH is the hexadecimal notation of the byte value).
  3. The original character is replaced by the resulting character sequence.
  After 'Applications should be cognizant... protocol parameters and state information...', mention that if there is more than one URI to access some resource, the most specific should be used (i.e. e.g. .../interop-pressrelease.html.en instead of .../interop-pressrelease). Re Followup...» Proposed :

4.3.3 The Reference Element

...Applications should be cognizant of the fact that protocol parameter and state information, (such as a HTTP cookies, HTML device profiles or content negotiation), may affect the content yielded by dereferencing a URI.

If there a resource is identified by more than one URI, the most specific should be used (e.g. .../interop-pressrelease.html.en instead of .../interop-pressrelease).

  In, in "IANA registered character set", the term 'character set' should be put in quotes. This is the term that IANA uses, but it's technically incorrect. Re Followup...» Proposed

"IANA registered 'character set'"

  In the same paragraph, change 'no .... needs such information' to 'no .... needs such explicit information'. Re Followup...» Proposed » accepted [ a, b] The Transforms Element

.. Some Transform may require explicit MimeType, Charset (IANA registered "character set"), or other such information concerning the data they are receiving from an earlier Transform or the source data, although no Transform algorithm specified in this document needs such explicit information. Such data characteristics are provided as parameters to the Transform algorithm and should be described in the specification for the algorithm.

  4.5 The Encoding attribute of <Object> is not described. Is that something like 'charset', or something like base64, or what. This needs to be clearly described or removed. Re Followup...» Proposed » accepted [ a, b]

4.5 The Object Element

... The Object's Encoding attributed may be used to provide a URI that identifies the method by which the object is encoded (e.g., a binary file).

  6.5 "Canonicalization algorithms take one implicit parameter:" Wrong, the charset is also an implicit parameter, and is very important. The spec must say that this parameter is derived according to the rules for the relevant protocols and formats, and that in particular for XML, the rules defined in RFC 2376 or its successor apply. The spec should also say that in order to be able to correctly sign and verify web documents, it is important that this information is delivered correctly, and that this may require settings on the server side. The spec should also say that for some 'charset's, there may be differences for some characters in which Unicode character a given character is converted, and and should point to the XML Japanese Profile ( submission for an example and some advice. In particular, documents intended for digital signing should preferably be created using UTF-8 or UTF-16 from the start. The following sentence should also be added to 6.5: Various canonicalization algorithms require conversion to UTF-8. Where any such algorithm is REQUIRED or RECOMMENDED, this means that that algorithm has to understand at least UTF-8 and UTF-16 as input encodings. Knowledge of other encodings is OPTIONAL. [The disposition of comments says "(these issues can be better addressed in the C14N spec)", but because this also affects minimal canonicalization, XPath transform,..., this is not true.] Re Followup...» Proposed » accepted [ a, b, c]

Canonicalization algorithms takes two implicit parameter when they appear as a CanonicalizationMethod within the SignedInfo element: the content and its charset. (Note, there may be ambiguities in converting existing charsets to Unicode, for an example see the XML Japanese Profile [XML-Japanese] NOTE.) The charset is derived according to the rules of the transport protocols and media formats (e.g, RFC2376 [XML-MT] defines the media types for XML). This information is necessary to correctly sign and verify documents and often requires careful server side configuration. Various canonicalization algorithms require conversion to [UTF-8]. Where any such algorithm is REQUIRED or RECOMMENDED the algorithm MUST understand at least [UTF-8] and [UTF-16] as input encodings. Knowledge of other encodings is OPTIONAL. Transcodings from a non-Unicode encoding to Unicode as part of canonicalization SHOULD be performed "The XPath implementation is expected to convert": 'is expected to' is too vague. Please chage this to 'must behave as if it converted....'. » moved to Canonicalization spec 'the string converted to UTF-8': Change to 'the string encoded in UTF-8'. (you can convert from one encoding to another, but XPath deals with character independent of an encoding, so convert sounds a bit strange) [two times in the same paragraph]. A similar wording problem exists for 'by serializing the node-set with a UTF-8 encoding'. There is only one UTF-8! » moved to Canonicalization spec
  7.1, second list, point 2: 'except... and other character entities not representable...': This may be wrongly understood to mean that e.g. &eacute; in a HTML document shouldn't be expanded if the encoding is US-ASCII. This is of course wrong, &eacute; should in this case be changed to the appropriate numeric character reference (and the spec may have to say whether these should be decimal or hex,...). Proposed »

"All entity references (except "amp", "lt", "gt", "apos",
"quot", and other character entities not representable in the encoding chosen) are expanded and non-representable characters are replaced by
their numeric character reference."

Issues Raised After 1st Last Call

Source Isssue Resolution
LaMacchia Concern over continued ambiguity of the X509 element. Discussed at FTF, and new stab taken at less amigous formulation and substantive tweaks. Proposed by Eastlake/Gindin and included in WD-xmldsig-core-20000918/ (2nd last call) with no opposition
Karlinger Removing SignatureProperties as they are superflous. No concensus to accept change at FTF given stability of syntax » WD-xmldsig-core-20000918/ (2nd last call)
Simon Is there a way to using schema to limit an <ANY> content specification to a specific element w ithin a namespace? Unclear,  so we implement this via a specification proose and a comment in the schema definition of transform "should   be an xsl:stylesheet element" » WD-xmldsig-core-20000918/ (2nd last call)
Davis Question regarding "how to calculate legally enforceable signatures on behalf of human signers." Proposal for new paragraph in Introduction (introductory paragraph added stressing constrained scope of XML Signature)» WD-xmldsig-core-20000918/   (2nd last call)
Hugues RetrievalMethod 's encoding and type attributes optional? Ambiguity discussed and Eastlake proposes clarifying text. Reagle opposes mandatory type, which is accepted in 20000907 call and represented in » WD-xmldsig-core-20000918/   (2nd last call)
Roberts Reagle responded with rational for DTD design without subsequent opposition or counter-proposal.. no change » WD-xmldsig-core-20000918/   (2nd last call)
Boyer Proposed changes to processing model to work with latest Canonical XML so it operates over octets or XPath node-sets. We've changed the Reference Processing Model (section to permit the presentation and acceptance of XML node-sets between Transforms (and resulting from some URI References) when appropriate.» WD-xmldsig-core-20000918/   (2nd last call)
Karlinger In 6.4.2, regarding RSA signatures, ambiguity regarding the treatment of OIDs. Consensus on RSA signature structure : The pre-pended algorithm object identifier within the encoded RSA SignatureValue is required.» WD-xmldsig-core-20000918/   (2nd last call)
Steve Wang I just wonder if it should be hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14, i.e., the byte 1F should be 09. Fixed.

Issues Raised During 2nd Last Call

Source Isssue Resolution
Kent Comments on XML-Signature S&P draft. (Many typo/clarifying suggestions: substantive question of:

4.4.4 The X509Data Element The specification does not describe how to include certificate chain though certificate chain is used in the example. In the example, how does a signature application know which certificate has a key to verify the signature? )

Reagle: addressed  clarifications .

Gindin: The effective rule is that any certificate whose subject name matches the issuer name of any of the other certificates included is a CA from one of the included chains, and thus signature verification should only run on the remaining certificates.

Gindin: However, RFC 2459 section 3.2 contains the following: "In general, a chain of multiple certificates >may be needed, comprising a certificate of the public key owner (the end >entity) signed by one CA, and zero or more additional certificates of CAs >signed by other CAs." ...

Kawatsura   What should the version number be for the base64-encoded CRL? Wallace responds shouldn't have any.
  1. In section 6.4.2, change "IEEE P1363" to "IEEE 1363", the specification achieved release status on August 25th 2000 and hence the 'P' was dropped.
  2. Should signatures with partial message recovery be noted somewhere?
  3. Do we need a footnote for SHA-2?
  1. fixed .
  2. please make a case for it being noted.
  3. we allow arbitrary algorithms to be specified, many algorithms that can be used are not footnoted.

Issues Raised in Candidate REC

Source Isssue Resolution
Ashwood Signing an XML instance does not capture the meaning (DTD/schema/comments/spec) of that documents namespace, this is dangerous as that context might change. Reagle: The WG has decided that signing context is best served by explicitly including a Signature Reference to it.
Eastlake How  should we enable Keytypes (e.g., SPKIData, X509Data, PGPData) to be extend? Eastlake : proceed with option 2: extensions to the types may complement existing structures, but replacements should be a child of KeyInfo. 
Should we restrict the use of X509IssuerSerial, X509SKI, and X509SubjectName to identify the message signer's certificate only? Eastlake : These elements must refer to certficiates with the validation key.
Tamura What is returned by RetrievalMethod? Reagle: octets that are XML documents or elements.
? Should there be a KeyValue type? Eastlake : no substantial interest in changing this, we will leave the document as is, without a KeyValue level type but with the defined KeyValue children types.
Tamura Specification permits multiple KeyValues, what does this mean: must they apply to the validating key? Reagle : no consensus to change from a KeyValue is a "key that may be useful in validating the signature?"
Reagle Should we specify KeyInfo as a sequence of optionals, instead of (0,*) choices of mandatories? No support for this proposal .
Ken Goldman Is the X509SerialNumber an XSD integer type or binary/hex/base64? (If integer, why was it chosen given its verbose and computationally burdensome to translate into.) Eastlake : "as far as I know, X.509v3 defines CertificateSerialNumber as INTEGER." Would depend on implementors: Tamura: "I don't want to change our implementation and this change might cause performance penalty on Java because Java treats serial numbers as BigInteger instance.": "as far as I know, X.509v3 defines CertificateSerialNumber as INTEGER." and k: "I don't want to change our implementation and this change might cause performance penalty on Java because Java treats serial numbers as BigInteger instance."
Karlinger/Reagle XSLT child of Transform is of type string, should be changed or removed? Removed, since the instances were invalid against the string type regardless.
Glenn Adams   "... we request that the XML DSIG group add URNs for these algorithms, e.g.," Because of timing/scope, request was declined but added to informational document .
Eastlake/Reagle Should Minimal Canonicalization be removed? No implementations reported, Minimal Canonicalization removed ( added to an informational document).

Issues Raised in Candidate REC 2

Source Isssue Resolution
Eastlake MgmtData and the children of X509, PGPData, and SPKIData should be shown to to be implemented and interoperate. Eastlake : only there for extensibility, no specified behaviour so we retain as is. MgmtData is deprecated.
van der Koogh Questions/Proposals for more warnings about trustworthiness and changes to KeyInfo structures." Eastlake : The XMLDSIG standard is not about trust. Reagle: add clarifying sentence.
van der Koogh In 6.4.1 DSA you specify that p, g, q, y are to be mandatory in the DSAKey. And that J, seed, and pgenCounter are optional? First it's possible to have systemwide p, g, and q and have only y be the public key. So you don't have to repeat p, g and q in all communications and force people to use certain values... Now there's no reference to what J, seed and pgenCounter are exactly. I don't know what they are but because of "seed" I think this might have something to do with the seed of a PRNG? If this is the case then these optional elements tell way more than just the DSAKey and should therefor not be used. Eastlake/LaMacchia: drafted clarifying text
van der Koogh Why don't you have something like:
Eastlake : There doesn't seem to be much advantage in labeling the parts as you
suggest above.
Hughes "Forcing the CRL to be placed in a separate X.509 data element from the corresponding certificate material simply makes the process of identifying association harder." Eastlake : Consensus to tweak the schema.
Eastlake Is whitespace significant in DNames? Reagle : white space is significant
Hughes How to encode a strings in a DName in XML-Signature relevant structures (IssuerName, SubjectName) Reagle: included Karlinger's text.
Hughes XPath states that an element's namespace axis includes all non-overridden namespace declarations from all ancestors. C14N then states that we must write these out during canonicalization, whether or not they are used. This means, as we know, that signatures cannot be successfully moved into documents which have other namespaces in force. Reagle/Eastlake: an exclusive canonicalization will be developed orthogonally.
Dournaee / Hughes Are Object's Encoding and MimeType attributes redundant? If not, what do they mean when together? Reagle : Clarifying they may be used together but Transforms should be used.
Hughes & Oleary "A value of "collapse" means that a validating parser normalizes whitespaces in the string content of the DigestValue element. This behaviour could break the signature, if the signer produces a digest value containing sequences of whitespaces, and the verifier schema validates the signature." Reagle: please see resolution of next issue and that schema validation should be considered a transform.
Brian LaMacchia "do we really want/need line breaks every 76 characters?" Reagle: the Schema WG responds that there is no line length and may contain base64 characters plus any XML whitespace.

Issues Raised in Proposed REC

(These questions were raised during the extended Proposed REC while we waited for IESG approval. The threshold for inclusion are proposals "that don't upset *any* person, previous concensus, instances, or implementations: just small tweaks that make the spec better in everyone's eyes."

Source Isssue Resolution
LaMacchia Suggests we remove the restriction on elliding "at most one" URI attribute from a Reference. Reagle: Lack of consensus [ 1] for change.
Salz "SignatureProperty and Object element definitions should be modified to allow the xml:space attribute." Reagle: Lack of consensus [ 1, 2, 3] for the change.
Gregor Karlinger Question of DNAME encoding and compliance with RFC2253. Reagle: Publication in progrss so editorial tweak in the editors' draft, didn't make it into ietf-draft should be able to squeeze it in before RFC. semi-substantive changes need more advocacy and will be done only if we can accomodate it during final publicaiton.

Joseph Reagle <

Last revised by Reagle $Date: 2002/02/15 21:25:13 $