[cabfpub] Ballot for limited exemption to RFC 5280 forCTimplementation

Fri Sep 26 12:52:36 UTC 2014

On 19 September 2014 10:14, Steve Roylance
<steve.roylance at globalsign.com> wrote:
> Hi all,
>
> I've recently (For my own interest and not because I'm the responsible
> person
> within GlobalSign to debate such matters) been thinking of ways NOT to break
>
> 5280 but keep the same basic principle of CT intact.   If we have some
> freedom with AKI
> then for me we have a very simple alternative which allows CA's to construct
>
> 5280 compliant certificates.  Here goes...
>
> Initially you need a nonpublic "CT root" creating.  You then create a 'test
> issuing CA' from this root which exactly matches the 'real' issuing CA that
> you intend to use in every way (such that the only differences are based on
> the key materials from these new CAs (bare with me on this part).  You can
> of
> course make S/N, dates etc all 100% the same if you wish.

Why you call this a "test" issuing CA?

> You then issue the TBScertificate from the 'test issuing CA' (Here you
> ensure
> that 100% of the content of the EE matches the final 'real' certificate into
>
> which you'll also add the SCT, except that the AKI can never match the final
>
> cert without breaking 5280.... but we don't want to break it, so AKI remains
>
> correct for the TBScertificate based on the test CA and therefore chaining
> can
> be verified by the log server).   Everything will validate correctly as it's
> a
> working RFC/BR complaint EE cert.
> In terms of logging, the CA submits the TBScertificate and the alternative
> 'real' AKI that the CA intends to use for the real certificate.  The CT log
> server can then check chaining of the TBScertificate to the non public CT
> root, extract all items from the cert, replace the AKI and calculate the
> hash
> of the cert (Noting that issue date will change as we don't want to play
> with
> times for issuance but end date will stay the same) and you get back the SCT
>
> which will match your final 'real' certificate as intended.   The SCT is
> effectively the CT log's reply that it promises to create an entry in the
> log,
> and the test cert is CA's promise that it 'intends' to create a certificate
> with all of the items in the test cert (and the changed AKI). So everyone is
>
> happy as nothing has to be broken.  So the net result is:-
>
> 1) CA's don't have to break RFC5280 at all (No S/N issues, same s/w they use
>
> today etc.)
> 2) CA's only have to submit one root to a log  server and therefore avoid
> having to run around the log servers in the future adding new roots as and
> when they create them (Caveat...maybe you need one test ECC root and one
> test
> RSA root)

Perhaps I'm misunderstanding, but this seems wrong:

a) You'd need one of these "test" CAs for each real CA, because the
subjects have to match, right?

b) You'd have to register the real roots anyway to allow non-pre-cert
SCTs to be obtained.

> 3) CA's only need to create one CA hierarchy for testing (which is a
> duplicate
> in terms of subject naming as a minimum) therefore making it very clear
> what's
> real and needs to be BR audited and what's not
> 4) It achieves 100% of the requirement from CT in that 100% of the
> deconstructed cert content
> must be the same between TBSCertificate and real cert so there are no
> padding possibilities.

As I understand it, the AKI would be different? So the log would
presumably have to log the pre-cert _and_ the AKI submitted alongside
it? And we'd have to have some mechanism for CAs to sign the AKI so
the log couldn't swap in a different one, I guess?

> 5) As the "CT root is unique to the CA, you will not get a DoS even from a
> hacker by the hacker simply sending a test cert to the log as the log only
> accepts certs based on the pre-registered roots (even if they are test ones
> and not real ones they are still the CA's statement of issuance and all
> CT benefits therefore apply)

I don't understand this point at all!

> 6) If at the last second the real certificate cannot be issued then no harm
> no
> foul.

I believe this is true in general - if a precert is issued but no
corresponding cert, then a CA has done nothing wrong. If the precert
is a promise for a cert that would be mis-issued, then the CA would
still have to revoke it, regardless of whether (it is claimed that) it
was actually issued or not.

> Does that solve some/all of the issues or should I go back to my day job?
>
> Kind Regards
>
> Steve Roylance
>
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
>> Behalf Of Rob Stradling
>> Sent: 19 September 2014 09:24
>> To: Erwann Abalea; Brian Smith
>> Cc: CABFPub
>> Subject: Re: [cabfpub] Ballot for limited exemption to RFC 5280
>> forCTimplementation
>>
>> On 19/09/14 07:04, Erwann Abalea wrote:
>> <snip>
>> > The logic:
>> >    - CA produces a PreCert by including the poison extension
>> >    - log extracts the TBSCertificate from the PreCert, removes the
>> > poison extension, and changes issuer and AKI if the PreCert was issued
>> > under a PreCert Signing Certificate => the PreCert and what is signed
>> > by the log are now different (signature and signatureAlgorithm have
>> > been removed, poison extension has been removed, issuer and AKI has
>> > been changed if PreCert issuer is different than the final CA)
>> >    - log signs this result and sends the SCT back to the publisher
>> >    - CA includes a set of SCT in the final certificate
>> >
>> > Later:
>> >    - the browser receives the final certificate
>> >    - it extracts the TBSCertificate from it, takes the content of the
>> > SCT extension apart (keeps it for future use) and removes the extension
>> >    - it verifies the resulting modified TBSCertificate against the
>> > signatures contained in the SCT extension it kept => if issuer and AKI
>> > weren't changed by the log, this verification would always fail if
>> > PreCert SC is different than final CA, and the browser can't know what
>> > these values were before modifications
>>
>> Thanks Erwann.  This logic is exactly correct.  The test cases in the
> certificate-
>> transparency.org code demonstrate that this is correct.
>>
>> Brian's error (which I shared until Emilia corrected me privately last
> week, and
>> which you also shared until I corrected you on TRANS earlier this week) is
> in
>> thinking that the AKI and Issuer modifications are done by the CA and are
>> reflected in the Precertificate.  They're not.
>> They're done by the log when it transforms the Precertificate's
> TBSCertificate into
>> the "modified TBSCertificate".
>> (When a Precertificate Signing Certificate signs a Precertificate, that
>> Precertificate's Issuer and AKI match the Precertificate Signing
> Certificate's
>> Subject and SKI).
>>
>> When verifying a precert_entry SCT, a TLS Client needs to reconstruct the
>> "modified TBSCertificate", *NOT* the Precertificate's TBSCertificate.
>>
>> Since we've each independently reached the same wrong conclusion on this
>> issue and have needed to be corrected, I think we can safely say that
> relevant text
>> in RFC6962 is insufficiently clear!
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>