Re: [Trans] Draft agenda

[Ben Laurie <[e-mail]>]

On 26 February 2014 11:57, Rob Stradling <[e-mail]> wrote:
> On 26/02/14 11:28, Ben Laurie wrote:
>>
>> On 25 February 2014 12:36, Phillip Hallam-Baker <[e-mail]> wrote:
>>>
>>> On Tue, Feb 25, 2014 at 2:23 AM, Ben Laurie <[e-mail]> wrote:
>>>>
>>>> On 24 February 2014 19:17, Phillip Hallam-Baker <[e-mail]>
>>>> 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".

Ah. I like that idea. Rather less than I like the idea of fixing the
need for ritual compliance, though.