On 26/02/14 11:28, Ben Laurie wrote:
On 25 February 2014 12:36, Phillip Hallam-Baker <[email protected]> wrote:
On Tue, Feb 25, 2014 at 2:23 AM, Ben Laurie <[email protected]> wrote:
On 24 February 2014 19:17, Phillip Hallam-Baker <[email protected]> wrote:
What exactly is a 'precertificate'. Either something is a cert or it is
not.
If it parses as an X.509v3 certificate then it is an X.509v3 certificate
and thats an end to it.
Indeed, and a precertificate is a certificate. RFC 6962 defines what
exactly it is.
Not sure where you're going with this.
Ritual compliance with the existing PKIX spec.
Having two end entity certs with the same serial number is going to be a
problem.
Not for ritual compliance. Same serial number _and issuer_ is a
problem. CT does not require this.
That's true, but CT does _permit_ same serial number and issuer.
I think Phill is saying that he wants ritual compliance to be the only
option available.
If it is not then it is probably a CSR which would seem to be the
existing PKIX structure that fits its purpose.
Actually, I disagree with that. A Precertificate is not a certificate
signing _request_. It's a certificate signing _promise_.
Not really - a precertificate needs to be signed.
CSRs are signed.
But not by the right key - i.e. a change of spec would be required. I
think you might be able to cram the missing fields into attributes in
PKCS#10, though (which would also require additional spec).
That would involve reinventing several wheels and making the whole thing
far more complicated. All just to achieve ritual compliance.
But if we must have ritual compliance with 5280, then my preferred
solution is to "poison" the Issuer Name in the Precertificate.
For example...
Certificate Issuer Name: C=GB, O=My CA Ltd., CN=My CA
Precertificate Issuer Name: 1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA
Sign both the Precertificate and the Certificate with the same CA
private key. Use the same serial number for both.
It wouldn't matter whether or not there exists a CA Certificate with the
Subject Name "1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA".
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
