Countersignature capabilities in the current draft

Dear all,

As you know the RFC 2630 "Cryptographic Message Syntax" defines
an ASN.1 structure for digitally signed structures. In that document 
provisions are made for adding properties, signed and unsigned,
to the digital signature itself. One of these properties is the 
Countersignature, that is defined as: 
 
 " The countersignature (...) specifies one or more signatures
   on the contents octets of the DER encoding of the signatureValue
   field of a SignerInfo value in signed-data.  Thus, the
   countersignature (...) countersigns (signs in serial)
   another signature"

What is said here is that once one document has been signed by
somebody, somebody else can take the octets encoding the signature value
and sign them in turn, generating a new signature structure that could be
placed as an unsigned property of the origninal signature structure. 

In terms of XML this would be equivalent to generate a first <Signature>
element,
take its <SignatureValue> element, compute its digital signature, generate
a second <Signature> element and include it as content of an unsigned 
<SignatureProperty>

I would like to point out a couple of things and make some questions:

1. Would it be correct to assume that  a <SignatureProperty> could 
contain this kind of information, ie, other <Signature> element? My view
is that taking into account what is said in the draft ("Additional
information items
concening the generation of the signature(s) can be placed in a
SignatureProperty element"
in section 5.2), it would be OK.

2. Assuming that in XML this kind of behaviour should be allowed, what the
second <Signature> would sign is the <SignatureValue> element of the first
<Signature> element. So, a <Reference> to this <SignatureValue> should appear
within the second <Signature>, but NO Id attribute has been specified for the
<SignatureValue> element, so it seems not possible to reference it unless a
redefinition
of the <SignatureValue> element is made.

3. A way of overcoming this problem would be to put this signature value
within 
an object. This would allow to reference the signature value making use of 
an URI, but it seems a bit redundant.

4. My final question is Is there any strong reason why an Id attribute
could not
be added to the definition of the <SignatureValue>?

The reason for making these questions and requests is that ETSI (European
Telecommunications Standards Institute)
is working in complementing one of its current standards (ES 201 733 on
Electronic Signatures) with
definition of new XML types for signed and unsigned properties that could
accomodate relevant information for the European electronic signatures
that it has standardised, and one of these properties is the countersignature.
 I circulated some time ago in this list a first
version of the document, and we are currently progressing in our work.

Regards.

Juan Carlos Cruellas.

Received on Wednesday, 15 November 2000 11:13:23 UTC