ietf-smime
[Top] [All Lists]

Re: I-D ACTION:draft-ietf-smime-escertid-00.txt

2006-03-30 08:19:33

My preference is:

      ESSCertIDEx ::=  SEQUENCE {
           hashAlg                  AlgorithmIdentifier DEFAULT {id-sha256},
           certHash                 Hash,
           issuerSerial             IssuerSerial OPTIONAL
      }

I would rather see the algorithm identifier before the hash value.

Since a new OID is going to be assigned, it is not really important to me whether the default is sha256 or sha1. If implementors see a reason to go with sha1, I can live with it.

Russ


At 09:58 AM 3/30/2006, Denis Pinkas wrote:
Jim, and the working group


1 - This topic has been debated on the PKIX mailing list and a
    proposal has been made. The proposed ASN.1 structure is different
    from the one described in draft-ietf-smime-escertid-00.txt.

The current ASN.1 in RFC 2634 is:

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

The proposal from draft-ietf-smime-escertid-00.txt is:

      ESSCertIDEx ::=  SEQUENCE {
           certHash                 Hash,
           hashAlg                  AlgorithmIdentifier DEFAULT {id-sha256},
           issuerSerial             IssuerSerial OPTIONAL
      }

The proposal made on the PKIX mailing list is:

ESSCertIDv2 ::= SEQUENCE {
    certHash         OCTET STRING,
    issuerSerial     IssuerSerial,
    hashAlgorithm    AlgorithmIdentifier DEFAULT { sha-1 }

The advantage of the last proposal is backward compatibility with the existing
structure. The disadvantage is that it is less "natural" than invented from
scratch, but some explanations can easily overcome this drawback.

I would propose to adopt the proposal made on the PKIX mailing list.

In addition, I would take advantage of the rewriting of this section to correct
some past "errors" in section 5.4.1.

2 - Proposed rewritting:

"5.4.1. Certificate Identification

   The best way to identify certificates is an often-discussed issue.

   When an issuer/serial number pair is included in the SignedData
   object, that information is not part of the message digest
   calculation process may thus be changed without being detected.
   That information may only be used as an hint and by itself, does
   not allow to make sure that the right certificate is being accessed.

   A hash of the entire certificate allows a verifier to verify that
   the certificate that was chosen by the signer is being used when the
   signature is verified. It permits a detection of certificate
   substitution attacks.

   Duplication of the issuer/serial number pair within the Signing
   Certificate attribute is not fully necessary, but has the
   advantage to get the whole information from that attribute.

   Attribute certificates and additional public key certificates
   containing authorization information do not have an issuer/serial
   number pair represented anywhere in a SignerInfo object. When an
   attribute certificate or an additional public key certificate is not
   included in the SignedData object, it becomes much more difficult to
   get the correct set of certificates based only on a hash of the
   certificate. For this reason, these certificates SHOULD be identified
   by the IssuerSerial object."

3 - It is a matter of taste, but I would rather prefer:
    SigningCertificatev2 instead of SigningCertificateEx

4 - It would be nice to correct the typos from RFC 2634, e.g. "requred".
There are other typos like: "certficates", "subsiquent", "Indentification", ...
    Please use a spell checker.

Denis