AW: Errors and Questions

Hi Joseph,


>  > [GK2]Brackets must include the whole Reference block
>
> I don't understand.

Currently, the Reference block looks like:

  <Reference (URI=)? >
    (Transforms)?
    (DigestMethod)
    (DigestValue)
  (</Reference>)+

Correctly, it should look like:

  (<Reference (URI=)? >
    (Transforms)?
    (DigestMethod)
    (DigestValue)
  </Reference>)+


>  > [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).
> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0036.html

I see.


>  > [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.
>
> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0288.html
>
> Would you like to propose a change to the SignatureValue datatype?

I am OK with the current datatype definition, but currently it is
contradicting
with the explanation of section 4.2:

  Base64 [MIME] is the encoding method for all SignatureMethods specified
within
  this specification. While we specify a mandatory and optional to implement
  SignatureMethod algorithms, user specified algorithms (with their own
encodings)
  are permitted.

I suggest to tweak the text as follows:

  While we specify a mandatory and optional to implement SignatureMethod
algorithms,
  user specified algorithms are permitted. Both algorithms specified by this
  specification and user specified ones MUST use Base64 [MIME] as their
encoding
  method.


>  > [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.)

Now, with my suggested new text for [GK10], my remark [GK11] gets obsolete.
Both SignatureValues and DigestValues shall be Base64 encoded in any case.


>  > [GK16]Right: minOccurs='0'
>
> ?

Sorry, I missed that the any placeholder is embedded into a choice. So
minOccurs='0' is correct.


>  > [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?
>
> ?

The first sentence in section 4.4.4. reads:

  An X509Data element within KeyInfo contains one or more identifiers
  of keys/X509 certificates that may be useful for validation.

It says "one or more X509 certificates" in a X509Data element, which
seems reasonable, since I can include a whole certificate chain and
not only one EE certificate. But the grammar (now, in your latest
editorial copy both Schema and DTD) only allow for a single certificate.

>  > [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)>

See also my comment on [GK20] above.


>  > [GK26]Why is there still this superfluous
>  >SignatureProperties Element? Normally a number of SignatureProperty
> Elements
>  >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?

There has been some discussion:

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0154.html
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0155.html
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0157.html
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0177.html
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0178.html

ending with your message

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0188.html:

   >If we make this restriction (I do not see an argument against it), I
suggest
   >to reject the SignatureProperties element at all, since it only works as
   >an additional "container" level between Object and SignatureProperty,
but
   >nothing else.

  That's a good point. It is rather superflous. I'd be interested in what
  others have to say...

   >In this case I also suggest to reject SignatureProperties. Instead,
supply
   >each SignatureProperty element with an Id AND a Target attribute.

  Well, I changed the example to make it clearer this is what should happpen
  (though I'm hesitant to make the change of removing SignatureProperties'
ID,
  or the element itself without further discussion (though I agree with you
on
  removing it.))


Regards, Gregor
Liebe Grüße, Gregor
---------------------------------------------------------------
Gregor Karlinger
mailto://gregor.karlinger@iaik.at
http://www.iaik.at
Phone +43 316 873 5541
Institute for Applied Information Processing and Communications
Austria
---------------------------------------------------------------