[cabfpub] Ballot for limited exemption to RFC 5280 for CTimplementation

[Ben Laurie]

On 26 September 2014 07:43, Man Ho (Certizen) <manho at certizen.com> wrote:
> Does any existing certificate issuing software support "duplicate"
> certificate (that mean the issuer, same serial number, same public key,
> same subject info.) in the system? If not, many CAs will not be able to
> issue pre-cert.

Pre-certs do not require duplication - you can always issue them via
an intermediate.

Also, we have not heard of any CA unable to issue pre-certs.

>
>
> On 9/25/2014 5:57 PM, Ben Laurie wrote:
>> On 23 September 2014 00:11, Brian Smith <brian at briansmith.org> wrote:
>>> On Mon, Sep 22, 2014 at 7:02 AM, Ben Laurie <benl at google.com> wrote:
>>>> On 19 September 2014 22:41, Brian Smith <brian at briansmith.org> wrote:
>>>>> I understand. My point is that the specification doesn't say what
>>>>> transforms on the precert are to be done by the CA, which are to be
>>>>> done by the log, and which are to be done by the client. It just says
>>>>> that those transforms must be done in order to verify SCTs.
>>>> I'm not sure I understand your point - anyone who wants to generate or
>>>> verify an SCT must do those transforms. I think the spec is quite
>>>> clear that you start with a precert and from it derive an SCT by
>>>> transforming it in various ways. Certainly that's the intention - if
>>>> you think it is unclear perhaps you could suggest a change to the
>>>> wording (on the trans mailing list, I'd suggest)?
>>> My point is that it the RFC makes it unclear what the contents of a
>>> precert--the thing signed by the CA and sent to the log--are in the
>>> case a precertificate signing certificate is used. Consequently, it is
>>> difficult to write code or a prose explanation for comparing two X.509
>>> certificates to determine if one is a precert for the other. It is
>>> useful to be able to describe such a comparison, because that would
>>> allow any amendment to the BRs to be scoped appropriately, so that the
>>> amendment doesn't end up effectively allowing CAs to issue
>>> certificates with duplicate serial numbers in an unrestricted manner
>>> just by saying "that's not a certificate, it's a precertificate."
>> It seems to me the important point is not exactly what goes in a
>> precert vs. a cert, but the fact that a precert is unusable as a cert.
>> So, I'd suggest the language says that its OK to issue a cert with the
>> same issuer/serial number as another cert if and only if the
>> "duplicate" cert contains the CT poison extension. Or perhaps more
>> precisely, of all the certs with the same serial number/issuer, only
>> one does _not_have the poison extension.
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>