[cabfpub] Ballot for limited exemption to RFC 5280 forCTimplementation

Fri Sep 19 02:14:57 MST 2014

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.

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)
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.
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)
6) If at the last second the real certificate cannot be issued then no harm
no 
foul.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4256 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20140919/519754f9/attachment.bin 