Re: additional XML Digital Signature clarifications

Hi,

From:  "Frederick J. Hirsch" <hirsch@caveosystems.com>
To:  <w3c-ietf-xmldsig@w3.org>
Date:  Sun, 21 Jan 2001 16:06:21 -0500
Message-ID:  <NEBBLPMKCKBLFHBJIHPCOEHGCIAA.hirsch@caveosystems.com>

>The XML Digital Signature recommendation is an excellent document, and improves
>tremendously with each versions. I have a few questions, just clarifications:
>
>1) I assume a Manifest is not required to be within a Signature element. If a
>Manifest is within a Signature element it must be within an Object element, but
>not otherwise.

You are correct.

>This allows a Manifest to be included in multiple signatures, as discussed in
>section 2.3 (Extended Example). Ignoring namespaces and content:
>
><document>
><Signature>,,,<Reference URI=#Manifest
>Type="http://www.w3.org/2000/09/xmldsig#Manifest">... </Reference></Signature>
><Signature>,,,<Reference URI=#Manifest
>Type="http://www.w3.org/2000/09/xmldsig#Manifest">... </Reference></Signature>
><Signature>,,,<Reference URI=#Manifest
>Type="http://www.w3.org/2000/09/xmldsig#Manifest">... </Reference></Signature>
><Manifest Id=>
><Reference>...</Reference>
><Reference>...</Reference>
>...
></Manifest>
></document>
>
>2) In 4.3.2 on the SignatureMethod,the specification states "While there is a
>single identifier, that identifier may specify a format containing multiple
>distinct signature values".
>
>I'm not sure what this sentence is trying to say. Does it simply mean that the
>signature values will vary for an algorithm based on the input? Is there an
>example of what this is getting at

The concept is that you can have a single identifier which actually
identifies two or more of what are usually considered signature
algorithms and have as the signature value the binary concatenation of
the values they produce.  (Of course, from another point of view, you
are just specifying a single more complex signature algorithm that
produces a longer value.)  This would have the advantage that each
"sub-signature" could be cryptographically verified separately and you
would still be secure as long as one of them hadn't been broken.

>3) The KeyInfo section mentions a rawX509Certificate type, but this is not
>referenced in the KeyInfo schema.  Should it be one of the choices? Wouldn't the
>X509Data element with the X509Certificate contain a base64 encoded binary
>certificate value as well?

I believe the idea behind the "raw*" type was for use in connection
with RetrievalMethod, if the item being retrieved happens to be a
binary Certificate sitting in a file or something, as opposed to a
Base64 encoded Certificate.

>4) A minor typo in 4.4, KeyInfo, 3rd paragraph: octect should be octet (end of
>paragraph).
>
>< Frederick

Thanks,
Donald

Received on Monday, 22 January 2001 12:33:21 UTC