Subject: flexibility of the ESSCertID field

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 8 Nov 2005 14:43:50 +0100

>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.

Denis

---

From: Russ Housley <[email-masked]>
Date: Tue, 08 Nov 2005 13:02:02 -0500

Denis:

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.

Russ

---

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 8 Nov 2005 16:04:41 -0500

I like the "simpler" approach.

spt 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Tuesday, November 08, 2005 1:02 PM
To: Denis Pinkas; [email-masked]
Subject: Re: flexibility of the ESSCertID field

Denis:

    ESSCertID ::=  SEQUENCE {
         certHash                 Hash,

    OtherHash ::= CHOICE {

Why not use:

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

Russ

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

> >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.
>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 }
>

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 09 Nov 2005 16:38:57 +0100

>the same ESSCertID output when SHA-1 is used.

Adding new field at the end may be better for ASN.1 parsing

ESSCertIDv2 ::=  SEQUENCE {
         certHash Hash,
         issuerSerial  IssuerSerial OPTIONAL, 
         hashAlgorithm [0] AlgorithmIdentifier DEFAULT { algorithm id-sha1 }   
}

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: Russ Housley <[email-masked]>
Date: Wed, 09 Nov 2005 12:01:04 -0500

Peter:

Thanks for correcting my syntax.  I should have used 
"id-sha1-identifier" as the default, which is already defined for 
RSA-PSS and RSA-OAEP.

I prefer identifiers before the associated value, but that is just style.

Russ

>         issuerSerial  IssuerSerial OPTIONAL,         hashAlgorithm 
> [0] AlgorithmIdentifier DEFAULT { algorithm id-sha1 }
>}

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 09 Nov 2005 19:33:40 +0100

> "id-sha1-identifier" as the default, which is already defined for 

Depends on the module with the definition.

> I prefer identifiers before the associated value, but that is just style.
No, we are talking about an extension to an existing syntax.

Some decoders ignore unknown elements after the end of normal elements.
I don't remember whether this was an asn1 feature of BER.

Adding new fields into an existing syntax should be done at the end IMO.

---

From: Russ Housley <[email-masked]>
Date: Wed, 09 Nov 2005 16:35:37 -0500

Peter:

Not really.  To change the syntax, a new OID for the attribute will 
be assigned, so there will be no decode errors.

Russ

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 10 Nov 2005 14:20:55 +0100

Russ Housley wrote:

> Peter:
>
> Not really. To change the syntax, a new OID for the attribute will be 
> assigned, so there will be no decode errors.

Ok, for any new attribute you are free to choose whatever you want.
Where a new attribute is a good choice is another question.