- From: Denis Pinkas <Denis.Pinkas@bull.net>
- Date: Mon, 25 Oct 1999 16:10:12 +0100
- To: XML-DSIG <w3c-ietf-xmldsig@w3.org>
This is first version of the document has already a good shape. However, I would like to raise several related comments: It would be nice to be able to get the same features as those present in CMS (Cryptographic Message Syntax). This seems nearly there, but not completely. A major feature of CMS is the concept of signed attributes which should be mirrored in this document. In section 2.0, SignedInfo is defined as: the actual data over which the signature is calculated. It contains control information (algorithm identifiers, pre-processing transformations) and digest(s) over the object(s) being signed. In section 1.3.4 it is said that: "additional objects have been defined which may be referenced by SignedInfo. The Manifest element is provided which similarly contains a collection of references and objects (like SignedInfo), but leaves it entirely up to the application which digest or digests it will verify." This does not seem crystal clear. These additional objects are equivalent to the signed attribuytes from CMS (what don't we use that term as well ?) and thus must be verified by the application. In section 4.0, it is mentioned that: SignedInfo does not include explicit signature attributes. If an application needs to associate attributes (such as signing time, signing device, etc.) with the signature, it may add an additional Object that includes that data and reference that Object via an ObjectReference. It would be very nice to define such "useful attributes" in the document itself. A last, but related comment. In section 1.3.1 it is said: KeyInfo indicates what key was used to create the signature. It is optional because in some applications the key is implied by the circumstances. A wide variety of KeyInfo forms are available including certificates, key names, key agreement algorithms and information, etc. The keying information is outside of the signed information so that it need not be signed. KeyInfo might contain auxiliary information it is not desired to reveal to all signature verifiers. If KeyInfo were signed, it would be necessary to pass all of it to all verifiers. On the other hand, if it is desired to bind the keying information in to the signature, its digest and a pointer to it can easily be included in the signed information. In order to prevent some substitution attacks of certificates holding the same public key value, it is necessary to sign the KeyInfo. Providing a standard way to do this (using the equivalent of a signed attribute) would be most useful. Denis
Received on Monday, 25 October 1999 10:11:04 UTC