Re: [Trans] Alternate formats for Precertificates

[Rob Stradling <[e-mail]>]

On 26/02/14 16:58, Paul Hoffman wrote:
> RFC 4211 is also somewhat ambiguous. It says:
>
>     CertTemplate ::= SEQUENCE {
>        version      [0] Version               OPTIONAL,
>        serialNumber [1] INTEGER               OPTIONAL,
>        signingAlg   [2] AlgorithmIdentifier   OPTIONAL,
>        issuer       [3] Name                  OPTIONAL,
>        validity     [4] OptionalValidity      OPTIONAL,
>        subject      [5] Name                  OPTIONAL,
>        publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,
>        issuerUID    [7] UniqueIdentifier      OPTIONAL,
>        subjectUID   [8] UniqueIdentifier      OPTIONAL,
>        extensions   [9] Extensions            OPTIONAL }
>
> And:
>
>        serialNumber MUST be omitted.  This field is assigned by the CA
>        during certificate creation.
>
>        signingAlg MUST be omitted.  This field is assigned by the CA
>        during certificate creation.
>
> If it "MUST be omitted", it is not optional. So, a document updating RFC 4211 to fix this error, at least for the limited use of CT, seems fine.

Can a CA private key sign a CertTemplate structure?
Or rather, could RFC5280-compliant software verify a CA-signed 
CertTemplate if the corresponding CA certificate has the keyCertSign Key 
Usage bit set but _not_ the digitalSignature bit set?
I don't think it could.

So, I think we'd have to update RFC5280 - relaxing some of the Key Usage 
rules - in order to permit the RFC4211 CertTemplate structure to be used 
for Precertificates.

And if we're going to update RFC5280, surely the simplest update would 
be to permit an RFC6962-compliant Precertificate/Certificate pair to 
share the same serial number?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online