ietf-smime
[Top] [All Lists]

Re: Comments on the Cryptographic Message Syntax

1997-11-18 11:09:58
Jim:

1. ASN.1 Canonical Encoding Rules should be allowed

You say that CER requires indefinite length for constructed encodings, and
prohibits definite length for constructed encodings. Thus, CER, like DER,
provides gives a unique encoding of any structure.

I have never looked up CER, so I assume that you are correct.  How do other
people feel about adding support for CER?  This would require the addition
of a flag or the assignment for additonal OIDs to distinguish CER from DER.
 Is the increased possibility of non-interoperability wother the CER
improved handling for one-pass processing.

2. There is an ambiguity about which octets are input to hash and
encryption algorithms

Perhaps I'll try a concrete example to illustrate. Consider the data
string "Hello" whose characters are represented by the octets
48656C6C6F. This is encoded into an ASN.1 Octet String as
040548656C6C6F. If this is a Data Content Type, it is encoded in the
content field of a ContentInfo as A007040548656C6C6F.

The first paragraph says "the input [to the hash function] is the 
content octets of the DER encoding of the content field of the 
ContentInfo" - that means strip of the identifier and length octets from
the encoding of the content field to give 040548656C6C6F as the input to
the hash function. However, the second paragraph extracted above
suggests that the input to the hash function is just 48656C6C6F.

I will try and make it clear that the hash is calculated over "Hello"

3. User Keying Materials

You are adding additional overhead when there is only one recipient 
using that form of key management (as the algorithm-identifier is 
carried twice in your encoding) and some processing complexity in all
cases (the receiver needs a local table to indicate for which algorithms
to search for UKM) in order to achieve a small saving in message size 
when multiple recipients use the same form of key management.

You are also assuming that all algorithms that may use UKM will require 
the same UKM data for all recipients. This seems an unsafe assumption.

In my experience, most recipients will all use the same form of key
management.  The CMS allows every reipient to use a different key
management algorithm, but I expect this to be the exception, not the rule.

Two key management algorithms allow the same UKM to be used for each
recipient: X9.42 Diffie-Hellman and KEA.  There are certainly other
algorithms that require a different UKM-like value for each recipient.  In
these cases, the UKM is the wrong place to carry the value;; a parameter to
the algorithm identifier is better.

The whole point of the UKM field is to carry the relatively large value
once instead of once per recipient.  In my opinion, the reduced overhead is
worth the slightly more complex implementation.

4. RecipientKeyIdentifier

Why do you consider more than one recipient with the same subject key 
identifier to be an unlikely event? The subject key identifier might 
simply be an incremental counter of the certificates issued by a CA to 
each user, or the date on which the certificate was issued - in these 
cases several recipients having the same value would seem quite likely.
Why not allow the recipient's name to be present?

My experience with KEA in the MISSI PKI shows this to be the case.  The
whole point is to offer an alternative that is small.  If your PKI has many
subject public key identifier collisions, then you should use the isser and
serial number alternative.  This must be unique, but it is bigger than the
subject public key identifier.

5. Originator Certificate selection

Some key agreement algorithms use different originator keys for 
different recipients. It is therefore necessary to add an 
originator-cert-selector to RecipientInfo:

    RecipientInfo ::= SEQUENCE {
         version Version,
         rid RecipientIdentifier,
         keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
         encryptedKey EncryptedKey,
         originator-cert-selector CertificateAssertion OPTIONAL }

Okay, but I think that the location within the structure might be
incorrect.  It needs to come sooner to accompdate single-pass
processing.

I did not add this yet.  But I will add some form of selection in the next
version.  The CertificateAssertion syntax is far more complex that I
expected.  Unless others on the list think that this is the correct way to
preceed, I will make as simpler subset.  In fact, the two methods used to
identofy recipient certificates should be enough: subject public key
identifier and issuer plus serial number.

The  ASN.1 for CertificateAssertion follows so that readers can make up
their own minds....

Russ


CertificateAssertion ::= SEQUENCE {
       serialNumber            [0] CertificateSerialNumber     OPTIONAL,
       issuer                  [1] Name                        OPTIONAL,
       subjectKeyIdentifier    [2] SubjectKeyIdentifier        OPTIONAL,
       authorityKeyIdentifier  [3] AuthorityKeyIdentifier      OPTIONAL,
       certificateValid        [4] UTCTime                     OPTIONAL,
       privateKeyValid         [5] GeneralizedTime             OPTIONAL,
       subjectPublicKeyAlgID   [6] OBJECT IDENTIFIER           OPTIONAL,
       keyUsage                [7] KeyUsage                    OPTIONAL,
       subjectAltName          [8] AltNameType                 OPTIONAL,
       policy                  [9] CertPolicySet               OPTIONAL,
       pathToName              [10] Name                       OPTIONAL }

AltNameType ::= CHOICE { 
       builtinNameForm ENUMERATED {
                               rfc822Name                      (1),
                               dNSName                         (2),
                               x400Address                     (3),
                               directoryName                   (4),
                               ediPartyName                    (5),
                               uniformResourceIdentifier       (6),
                               iPAddress                       (7),
                               registeredId                    (8) },
       otherNameForm   OBJECT IDENTIFIER }