[xcbf] SignedData message digest process

[Phil Griffin <phil.griffin@asn-1.com>]

Following is proposed text for describing the message
digest process used to create the signature in type
SignedData. For the purposes of this description, I
have included a simplified version of the ASN.1 types
used in the digest process. 

I have created this description based on similar text
provided in the RSA PKCS #7 and IETF SMIME standards.
These are used today to provide secure electronic mail.
Please refer to these works and compare the text you
find there to what I suggest below. I have proposed
similar text be included in the revision of X9.84,
in X9.96 XML CMS and in X9.95 Trusted Time Stamp, all
of which are based on CMS.

The actual signature is created using the results of
this message digest process. For RSA signatures the
resulting hash is encrypted using the private key of
the signer. That action and the description of how a
receiver will verify the signature is not described
below, but will need to be included in XCBF.

Comments welcome. The SignedData message digest process
has long been considered particularly difficult for 
programmers to understand and implement correctly. But
if you compare the signature processing described below
with the complexity of that in XMLDSIG work, I think 
you will agree that using CXER greatly simplifies the
task. 

In XCBF, there are no XML attributes, no name spaces, no 
exclusive vs inclusive canonicalization issues, no need
for XPath or XPointer operations, and a much more simple
and easy to read schema. Simply CXER encode, digest, 
encrypt and you're done. 

Phil

------------------------------------------------------

A message digest process is used to create the signature in
type SignedData when that type is represented as XML markup
generated using the Canonical XML Encoding Rules (CXER). The 
message digest is calculated on the value of the eContent 
component of EncapsulatedContentInfo, together with the value
of the optional signedAttributes component of SignerInfo if
the signedAttributes component is present.

The value of the eContentType component of EncapsulatedContentInfo
identifies the type of value being signed. It the value of the 
eContentType object identifier is id-data, then no signed attributes
are required. If the value being signed is identified by any other
object identifier, then the message digest is calculated on the
value of the eContent component of EncapsulatedContentInfo 
together with the value of the signedAttributes component of 
SignerInfo, and the signedAttributes component must contain at least
two attributes, the content type attribute and the message digest 
attribute. 

When the Canonical XML Encoding Rules of ASN.1 are used to create
a value of type SignedData, the starting and ending eContent tags 
are excluded from the message digest process. Only the "value" portion
of an encoding of eContent is digested. That is the wrapper that 
creates an OCTET STRING "hole", the <eContent> and </eContent>
tags, are not included in the message digest process.

When the signedAttributes component of SignerInfo is present,
these attributes are always included in the message digest process
following the eContent. A complete encoding of a value of type 
SignedAttributes is concatenated to the "value" portion of the
encoding of eContent. The signed attributes appear in the order
specified by the encoding rules being used.

------------------------------------------------------
The following ASN.1 shows the type and identifier
names discussed above.

EncapsulatedContentInfo ::= SEQUENCE {
   eContentType  ContentType,
   eContent      [0] EXPLICIT OCTET STRING  OPTIONAL
}

ContentType ::= OBJECT IDENTIFIER

SignerInfo ::= SEQUENCE {
   version             Version (v1 | v3, ...),
   sid                 SignerIdentifier,
   digestAlgorithm     DigestAlgorithmIdentifier,
   signedAttributes    [0] SignedAttributes  OPTIONAL,
   signatureAlgorithm  SignatureAlgorithmIdentifier,
   signature           SignatureValue,
   unsignedAttributes  [1] UnsignedAttributes  OPTIONAL
}

where SignedAttributes is identified by the name signedAttributes
and is defined as 

SignedAttributes ::= SET OF Attribute