Re: [Trans] Alternate formats for Precertificates

[Paul Hoffman <[e-mail]>]

On Feb 26, 2014, at 9:05 AM, Carl Wallace <[e-mail]> wrote:

> 
> On 2/26/14, 11:58 AM, "Paul Hoffman" <[e-mail]> 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.
> 
> If this is all that is sought, why not just use TBSCertificate as Rob
> suggested and be done?  How would that run afoul of ritual compliance?

Because I couldn't figure out what he meant, and he followed by a smilely so I figured it wasn't serious.

When you say "just use a TBSCertificate", you mean that CT use that instead of a certificate structure, yes?

--Paul Hoffman