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

AW: Errors and Questions

From: Gregor Karlinger <gregor.karlinger@iaik.at>
Date: Thu, 27 Jul 2000 09:44:08 +0200
To: "Joseph M. Reagle Jr." <reagle@w3.org>, "Gregor Karlinger" <gregor.karlinger@iaik.at>
Cc: "XML" <w3c-ietf-xmldsig@w3.org>, "Barbara Fox" <bfox@Exchange.Microsoft.com>, "Brian LaMacchia" <bal@microsoft.com>
Message-ID: <NDBBIMACDKCOPBLEJCCDGENJCIAA.gregor.karlinger@iaik.at>
Hi Joseph,

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

Currently, the Reference block looks like:

  <Reference (URI=)? >

Correctly, it should look like:

  (<Reference (URI=)? >

>  >[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
with the explanation of section 4.2:

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

I suggest to tweak the text as follows:

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

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


ending with your message


   >If we make this restriction (I do not see an argument against it), I
   >to reject the SignatureProperties element at all, since it only works as
   >an additional "container" level between Object and SignatureProperty,
   >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,
   >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'
  or the element itself without further discussion (though I agree with you
  removing it.))

Regards, Gregor
Liebe Gre, Gregor
Gregor Karlinger
Phone +43 316 873 5541
Institute for Applied Information Processing and Communications

Received on Thursday, 27 July 2000 03:45:08 UTC

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