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

[Brian Smith]

On Thu, Sep 18, 2014 at 11:04 PM, Erwann Abalea
<erwann.abalea at opentrust.com> wrote:
> Le 19/09/2014 01:40, Brian Smith a écrit :
>> On Thu, Sep 18, 2014 at 3:09 PM, Erwann Abalea
>> <erwann.abalea at opentrust.com> wrote:
> The poison extension is added so that the Precertificate, as issued by the
> CA, doesn't fall into the scope of the BR.
> AKI and issuer fields are not mentioned because they have no special
> treatment by the CA. That is, the AKI points to the Precert Signing
> Certificate's SKI, and issuer is equal to Precert Signing Certificate's
> subject name.

Like I mentioned in my reply to Rob, I understand that that seems to
be the way implementations work, but the spec doesn't seem to say that
that is the case. My main point is that CABforum shouldn't defer to
the RFC's text here, because the RFC isn't clear.

>> Further, nowhere does it indicate that the Precertificate Signing
>> Certificate must have a different subject name or a different public
>> key from the issuing CA certificate.
>
>
> If the Precert Signing Certificate has the same subject name as the final CA
> certificate, then it's the same CA (with or without a different key).
> Are you suggesting that this RFC should explicitely distinguish all the
> following cases (variations on subject name and key):
>  - the Precertificate Signing Certificate is another certificate belonging
> to the final CA (same subject name), with the same key, and special purpose
> EKU
>  - the PSC is another certificate belonging to the final CA, with a
> different key, and special purpose EKU
>  - the PSC is a different CA (different name), special purpose EKU, directly
> issued by the final CA, with the same key as the final CA
>  - the PSC is a different CA, special purpose EKU, directly issued by the
> final CA, with a different key
>  - the PSC is the exact same final CA certificate
>
> and reject the first 3?

The way the RFC is written, it is allowed for the precertificate
signing certificate to have the same subject name as the certificate
that is the issuer of the final certificates. Thus, the duplicate
serial number issue also has the potential to affect the
precertificate signing certificate case. The CA can easily avoid the
problem by using a different subject name for the percertificate
signing certificate, but it isn't required by the spec.

I do think there should be additional restrictions on precertificate
signing certificates to avoid some of the problematic cases you
mention and other cases, but I think that's better discussed on the
trans mailing list.

>> It would be very strange for the log to take a precertificate and
>> modify its AKI and issuer name before logging it. Remember that the
>> purpose of the log is to accurately record the output of the CAs. Any
>> substitutions of the CAs output is counter to that purpose.
>
> True. But it's what it does already (with the poison extension).
> The AKI and issuer changes are necessary so the browser can build
> "something" signed by the log out of the certificate sent by the web server,
> and verify this signature (which is present in the SCT extension of the
> final certificate).

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.

>> (Also, it is a terrible mistake that the precertificate signing
>> certificate has basicoConstraints.cA == true. Implementations will now
>> Precertificate Signing Certificates to issue certificates, not just
>> precertificates, and also this interacts poorly with path length
>> constraints on the issuing CA.)
>
> This decision has impacts on what to do regarding the CABF or BR rules.
> Because these are not technically-constrained CAs as defined by BR, and are
> CAs under a public root. So they have other duties than just generate
> PreCerts.

Right. In particular, there's nothing disallowing the use of a
precertificate signing certificate for issuing real certificates in
addition to precertificates.

Cheers,
Brian