On Feb 26, 2014, at 9:05 AM, Carl Wallace <[email protected]> wrote:
> > On 2/26/14, 11:58 AM, "Paul Hoffman" <[email protected]> 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 _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
