Some comments on the Cryptographic Message Syntax spec:
1. ASN.1 Canonical Encoding Rules should be allowed
Single-
pass operation has one significant drawback; it is difficult to
perform encode operations using the Distinguished Encoding Rules
(DER) encoding in a single pass since the lengths of the various
components may not be known in advance. Since DER encoding is
required by the signed-data content type, an extra pass may be
necessary when a content type other than data is encapsulated.
Why does the signed-data content type require DER? Why doesn't it allow the
choice of CER or DER, with the digest algorithm-identifier indicating which?
For example, SHA-1 on the CER encoding would have a different
algorithm-identifier to SHA-1 on the DER encoding. [For anyone unfamiliar with
CER, it is defined in the 1994 version of ASN.1, and is identical to DER except
that CER uses indefinite length encoding (which permits single-pass encoding)
and constructed encoding of strings.]
2. There is an ambiguity about which octets are input to hash and encryption
algorithms
The message digest calculation process computes a message digest on
either the content being signed or the content together with the
signer's authenticated attributes. In either case, the initial input
to the message digest calculation process is the "value" of the
content being signed. Specifically, the initial input is the content
octets of the DER encoding of the content field of the ContentInfo
value to which the signing process is applied. Only the contents
octets of the DER encoding of that field are input to the message
digest algoritm, not the identifier octets or the length octets.
When the content being signed has content type data and the
authenticatedAttributes field is absent, then just the value of the
data (e.g., the contents of a file) is input to the message digest
calculation. This has the advantage that the length of the content
being signed need not be known in advance of the encryption process.
Although the identifier octets and the length octets are not included
in the message digest calculation, they are still protected by other
means. The length octets are protected by the nature of the message
digest algorithm since it is computationally infeasible to find any
two distinct messages of any length that have the same message
digest.
The first of the three paragraphs above says something different about which
octets are input into the hash function than the implication of the second and
third paragraphs. Consider the encoding of the content field of the ContentInfo
in the following examples:
For the data content type:
Identifier Length Contents
[0] nnn
Identifier Length Contents
OctetString nnn xxxxxxxxx
For the signed-data content type:
Identifier Length Contents
[0] nnn
Identifier Length Contents
Sequence nnn
Identifier Length Contents
Integer 1 1
The first paragraph above says that it is the contents octets of the content
field which is input to the hash function - i.e. octets starting with the
identifier for OctetString in the case of the data content type - but the
second paragraph implies that it is just the contents octets of this
OctetString. Should the first paragraph be changed to replace "content octets
of the DER encoding of the content field" by "DER encoding of the content
octets of the type within the content field"? That is, does the input to the
hash start with the identifier for Integer in the case of signed-data?
3. User Keying Materials
Surely these should be included within the parameters component of the
algorithm-identifier for algorithms which require such material.
4. RecipientKeyIdentifier
RecipientKeyIdentifier is not an adequate identification of a recipient, since
subjectKeyIdentifier is only unique within the scope of an individual
recipient, and it is not accompanied by any other identification of the
recipient. I suggest that the more general CertificateAssertion syntax from
X.509 should be used instead of the restrictive subjectKeyIdentifier:
RecipientKeyIdentifier ::= SEQUENCE {
recipient-name Name,
recipient-certificate-selector CertificateAssertion}
5. Originator Certificate selection
Some key agreement algorithms use different originator keys for different
recipients. It is therefore necessary to add an originator-certificate-selector
to RecipientInfo:
RecipientInfo ::= SEQUENCE {
version Version,
rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey,
originator-certificate-selector CertificateAssertion OPTIONAL }
Jim Craigie
NET-TEL Computer Systems Ltd
1 Wyld Farm, Hampstead Norreys, Newbury, Berkshire, RG18 0TF, UK
Tel: +44 1635 202124 Fax: +44 1635 201424
X400: G=Jim; S=Craigie; O=Net-Tel Computer Systems Ltd; P=Net-Tel; A=Gold 400;
C=GB
Internet: Jim(_dot_)Craigie(_at_)net-tel(_dot_)co(_dot_)uk