[Top] [All Lists]

Re: flexibility of the ESSCertID field

2005-11-08 11:18:41


The syntax from RFC 2634 is:

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

   Hash ::= OCTET STRING -- SHA1 hash of entire certificate

   IssuerSerial ::= SEQUENCE {
        issuer                   GeneralNames,
        serialNumber             CertificateSerialNumber

The "improved" syntax that you reference from RFC 3126 is:

   OtherCertID ::= SEQUENCE {
        otherCertHash            OtherHash,
        issuerSerial             IssuerSerial OPTIONAL

   OtherHash ::= CHOICE {
       sha1Hash     OtherHashValue,  -- This contains a SHA-1 hash
       otherHash    OtherHashAlgAndValue

   OtherHashValue ::= OCTET STRING

   OtherHashAlgAndValue ::= SEQUENCE {
     hashAlgorithm    AlgorithmIdentifier,
     hashValue        OtherHashValue

This seems more complicated than necessary to me.

Why not use:

   ESSCertIDv2 ::=  SEQUENCE {
        hashAlgorithm AlgorithmIdentifier DEFAULT id-sha1,
        certHash Hash,
        issuerSerial  IssuerSerial OPTIONAL

I prefer this approach because it is always fewer octets, and it generates the same ESSCertID output when SHA-1 is used.


At 08:43 AM 11/8/2005, Denis Pinkas wrote:

>Jim Schaad presented a concern about the algorithm flexibility of the
>ESSCertID field. Right now this field is limited to the use of the SHA-1
>algorithm, and Jim proposed the addition of an AlgorithmIdentifier to
>indicate the digest algorithm used to prepare the digest.

OtherSigningCertificate, as defined in RFC 3126, could be used for that purpose

id-aa-ets-otherSigCert OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
  smime(16) id-aa(2) 19 }

RFC 3126 was anticipating the need to use other algorithms.