- From: Mark Bartel <mbartel@thistle.ca>
- Date: Mon, 21 Feb 2000 09:36:26 -0500
- To: "'Carl Wallace '" <cwallace@erols.com>, "'dsig '" <w3c-ietf-xmldsig@w3.org>
Carl, 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 following: * 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 JetForm -----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 key." 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 values. Also, there are a few references that need to be updated: - sections 4.3.1, 4.3.2 and 4.3.3.2 refer to Section 5.1 where they should refer to 6.1 - section 4.3.3.1 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