I think the best way to change a Certificate into a Precertificate would be to
alter the first field of the tbsCertificate to be non-optional and explicitly
tagged as something other than tag [0]. Then, reconstruct the actual
tbsCertificate by changing the first field to tag [0], perform any other
necessary edits (like, for name redaction), re-encode the validly-tagged
tbsCertificate to DER, and digest the encoded data.
But, I also proposed (a few years ago) a way to include an issued certificate
list in a CRL extension to mitigate the Diginotar-style "we didn't know it had
been issued" problem, and to be able to feed CRL-based OCSP responders with a
minimum of code changes. That didn't go anywhere, and I expect this suggestion
to go nowhere as well.
-Kyle H
On September 9, 2014 12:56:11 PM PST, Brian Smith <[email protected]> wrote:
>On Mon, Sep 8, 2014 at 4:24 PM, Rick Andrews
><[email protected]> wrote:
>>> The CA may use a Precertificate Signing Certificate to sign the
>Precertificate, and then sign the final certificate with the production
>CA certificate. Then, there would be no duplicate serial number issues.
>>
>> Brian, even if the CA uses a Precert signing cert, the precert's
>issuer name has to be that of the ultimate issuer, and the serial
>number has to be that of the ultimate certificate, so I don't think
>that solves the problem.
>
>Thanks for pointing that out. Basically, the cause of that problem is
>that a Precertificate is a syntactically-valid X.509 certificate, and
>so it could be considered a duplicate of the final certificate. If the
>Precertificate weren't a syntactically-valid X.509 certificate, then
>there would be no way it could be considered a duplicate. So, why not
>make this simple change to the syntax:
>
>enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType;
>
> struct {
> LogEntryType entry_type;
> select (entry_type) {
> case x509_entry: ASN.1Cert;
> case precert_entry: ASN.1Precert;
> } entry;
> ASN.1Cert certificate_chain<0..2^24-1>;
> } LogEntry;
>
> opaque ASN.1Cert<1..2^24-1>;
> opaque ASN.1Precert<1..2^24-1>;
>
>where the internal syntax of ASN.1Precert is (in ASN.1):
>
> ASN1Precert ::= SEQUENCE {
> precertSigningCert [0] EXPLICIT OptionalCertificate,
> tbsCertificate TBSCertificate,
> signatureAlgorithm AlgorithmIdentifier,
> signatureValue BIT STRING }
>
> OptionalCertificate ::= certificate Certificate OPTIONAL;
>
>In other words, ASN1Precert is exactly an X.509 Certificate except
>that it starts with an explicitly-tagged, possibly-empty
>precertSigningCert field. Thus, no X.509 certificate parser would
>parse a precert as though it were a real certificate, and so the
>precert could never be considered a duplicate of the final cert.
>Additionally, there would be no need for the "poison extension"
>because the added precertSigningCert field serves the same purpose.
>
>This strawman only attempts to solve the "duplicate certificate"
>problem, not the "must reserve the serial number in advance" problem.
>However, I suspect that this change would make it more difficult for
>some CAs to create precertificates.
>
>Cheers,
>Brian
>
>_______________________________________________
>Trans mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/trans
--
Sent from my Android device with K-9 Mail. Please excuse my brevity._______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
