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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
