Re: Countersignature capabilities in the current draft

     Responses to your first two points below.

          Tom Gindin

Juan Carlos Cruellas <cruellas@ac.upc.es>@w3.org on 11/15/2000 12:14:21 PM

Sent by:  w3c-ietf-xmldsig-request@w3.org


To:   w3c-ietf-xmldsig@w3.org
cc:
Subject:  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.

[Tom Gindin] One of the original motivations IMHO for SignatureProperty was
to provide a home for the analogues of PKCS #7 authenticated attributes.
It is not much of a stretch to include an unauthenticated attribute, and it
doesn't seem to violate the current syntax, but should we have a different
variant of "Object" for this?

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.

[Tom Gindin] You might have to sign the provided Signature element instead
of SignatureValue.  That would also incorporate a reference to KeyInfo,
which has some advantages.

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 18:51:13 UTC