W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

Errors and Questions

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Wed, 26 Jul 2000 13:09:30 -0400
Message-Id: <>
To: "Gregor Karlinger" <gregor.karlinger@iaik.at>
Cc: "XML" <w3c-ietf-xmldsig@w3.org>, "Barbara Fox" <bfox@Exchange.Microsoft.com>, Brian LaMacchia <bal@microsoft.com>
[Barb/Brian: I'm deferring GK13-16,20 to you.]

At 15:23 7/26/2000 +0200, Gregor Karlinger wrote:
 >please find attached my comments regarding the 10/07/00 XML-Signature

Thanks! As always, very thorough. <smile> [1] has the sometimes latest of
the editors version I'm working (that's what I'm talking about below) and
has most of your changes (aside when I ask a question back.)

[1] http://www.w3.org/Signature/Drafts/WD-xmldsig-core-latest/

 >  * Errors are highlighted in red and followed by a linked comment
 >  * Questions/suggestions are highlighted in green and followed by a linked

 > [GK1]CanonicalizationMethod is obligatory

Noted/fixed in editors' copy.

 > [GK2]Brackets must include the whole Reference block

I don't understand.

 > [GK3]CanonicalizationMethod is obligatory

Noted/fixed in editors' copy.

 > [GK5]Do whitespace normalization according to
 >chapter 7.1

" #AMadeUpTimeStamp "  --> "#AMadeUpTimeStamp"  

 > [GK6]Do whitespace normalization according to
 >chapter 7.1

" #MySecondSignature [GK6] "> --> "#MySecondSignature"> 

 > [GK7]CanonicalizationMethod is obligatory

Create SignedInfo element with SignatureMethod, CanonicalizationMethod and

 > [GK8]Why canonicalize in reference validation?

To ensure the appplication "see what it signs" (If SignedInfo is
canonicalized, then it should process the canonical form).

 > [GK9]Only correct for values created with methods
 >specified by XML-Signature standard

This is true. If someone wanted to create a structured XML Signature Value
they would be prohibited. When we last left this issue:

        2. There's no proposal nor agreement to change the 
        definitions or dataytpes of SignatureValue, SignatureProperty, 
        or KeyInfo.
        or KeyInfo.


Would you like to propose a change to the SignatureValue datatype?

 > [GK10]Better: document root

Editors' copy reads "root node" based on earlier suggestion.

 > [GK11]Why is it always base64 encoded? I suggest the
 >same mechanism as with SignatureValue, i. e. the encoding (if any) is
determined by the DigestMethod.

Do you mean there is an attribute in DigestMethod, or that it is an implicit
parameter? (Please include complete proposal.)

 > [GK12]Right: minOccurs='0'

Agreed, now reads:

      <any processContents='lax' namespace='##other' minOccurs='0'

 > [GK13]Why key(s) and not key? How can more than
 >exacly one key be used?

I believe that might be because more than one key might be required for
trust, but not for Signature validation, so I'd agree with you. Barbara?

 > [GK14]How can more than exacly one key be used?


 > [GK15]Here the value for exactly one key can be

Yes, the schema and prose are in conflict.

 > [GK16]Right: minOccurs='0'


 > [GK17]Must satisfy RFC 2253

Yes, noted and corrected in editors' copy.

 > [GK18]Must satisfy RFC 2253

Yes, noted and corrected in editors' copy.

 > [GK19]Consider a grammar satisfying  RFC 2253

Yep, if someone writes up a regexp facet, I'll be happy to put it in.

 > [GK20]Only a single certificate possible here?


 > [GK21]Consider a grammar satisfying  RFC 2253

Yep, if someone writes up a regexp facet, I'll be happy to put it in.

 > [GK22]Content Model is different from that in the
 >Schema Definition

Based on previous comment Editors' copy reads:

   <!ELEMENT X509Data ((X509IssuerSerial | X509SKI | X509SubjectName)+ |
                      X509Certificate | X509CRL)>

 > [GK23]Right: minOccurs='0'

      <any namespace='##other' processContents='lax' minOccurs='0'

 > [GK24]Content Model is different from that in the
 >Schema Definition

PGPData needs a re-work.

   Schema Definition:

   <element name='PGPData'> 
     <complexType content='elementOnly'> 
       <choice minOccurs='1' maxOccurs='1'>
         <any namespace='##other' processContents='lax' minOccurs='0' 
         <sequence minOccurs='1' maxOccurs='1'>
           <element name='PGPKeyID' type='string' minOccurs='1'
           <element name='PGPKeyPacket' type='ds:CryptoBinary' minOccurs='1' 


   <!ELEMENT PGPData (PGPKeyID, PGPKeyPacket)  >
   <!ELEMENT PGPKeyPacket  (#PCDATA)  >

 > [GK25]Right: minOccurs='0'

Since a Manifest isn't required either, they should both be 0, with a choice
requiring one.

  <element name='Object' > 
    <complexType content='mixed'>
      <choice minOccurs='1' maxOccurs='1'>
       <element ref='ds:Manifest' minOccurs='0' maxOccurs='unbounded'/>
       <any namespace='##any' processContents='lax' minOccurs='0'
      <attribute name='Id' type='ID' use='optional'/> 
      <attribute name='MimeType' type='string' use='optional'/> <!-- add a
grep facet -->
      <attribute name='Encoding' type='uriReference' use='optional'/> 

 > [GK26]Why is there still this superfluous
 >SignatureProperties Element? Normally a number of SignatureProperty
 >are grouped into a Object Element anyway 

I don't recall the state of this issue. Was there a proposal that it be
removed, was it agreed to?

 > [GK27]"document" does not seem appropriate here,
 >better something like "XML data item"


Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Wednesday, 26 July 2000 13:09:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:34 UTC