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

RE: draft-ietf-xmldsig-core-04 question

From: Mark Bartel <mbartel@thistle.ca>
Date: Mon, 21 Feb 2000 09:36:26 -0500
Message-ID: <3C4B400C1E317E4799AAAF2317BDCED102E5B8@arafel.ealdwood.thistle.ca>
To: "'Carl Wallace '" <cwallace@erols.com>, "'dsig '" <w3c-ietf-xmldsig@w3.org>

The e.g. in 4.2 might better be expressed as

    (e.g. "rsawithsha-1andecdsawithsha-1")

The idea being that there would only be one SignatureMethod and one
SignatureValue, the former containing the identifier above and the latter
containing (for example) the concatenation of an rsa-sha1 signature and a
ecdsa-sha1 signature.  The motivation being to provide protection in case
one of the algorithms is proved weak.  Using a single algorithm the
semantics can be specified in the algorithm definition, whereas it would be
ambiguous what multiple SignatureValues would mean.

Section 4.4 is certainly not clear.  I believe the idea is to convey the

* several certificates could be present, all on the same key, but with
different issuers, to accomodate the requirements of different recipients (I
won't say that this is necessarily a good idea)

* in the case of combined signature schemes as mentioned in 4.2, you might
need both a rsa key and an ecdsa key

* perhaps it is also referring to the possibility of a signature chain,
where some of the certificates might need to be verified

I think having the concatenated identifier in the example would clarify 4.2.
Perhaps the text in 4.4 could be expanded a bit.

-Mark Bartel

-----Original Message-----
From: Carl Wallace
To: dsig
Sent: 2/21/2000 8:36 AM
Subject: draft-ietf-xmldsig-core-04 question

I don't understand the following statements from sections 4.2 and 4.4.
Section 4.2 states:

"The ability to define a SignatureMethod and SignatureValue pair which
includes multiple distinct signatures is explicitly permitted
(e.g."rsawithsha-1 and ecdsawithsha-1")."

Since the schema and DTD indicate that there must be one SignatureMethod
and one SignatureValue how does this work?  Section 4.3.2 also mentions
"multiple, distinct signature values" but provides no clarification as
to how this is done using the defined structures.  

Section 4.4 states:

"KeyInfo is an optional element which enables the recipient(s) to obtain
the key(s) needed to validate the signature. If omitted, the recipient
is expected to be able to identify the key based on application context
information. Multiple declarations within KeyInfo refer to the same

If multiple references must refer to the same key then "key(s)" should
be changed to "key".  This conflicts with the use of multiple signature

Also, there are a few references that need to be updated:

    - sections 4.3.1, 4.3.2 and refer to Section 5.1 where they
should refer to 6.1
    - section refers to Section 5-6 where it should refer to 6.6

Carl Wallace   
CygnaCom Solutions
Received on Monday, 21 February 2000 09:36:34 UTC

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