[cabfpub] Ballot for limited exemption to RFC 5280 forCTimplementation

Steve Roylance steve.roylance at globalsign.com
Fri Sep 26 06:37:34 MST 2014


Thanks Ben.  Feedback below

> -----Original Message-----
> From: Ben Laurie [mailto:benl at google.com]
> Sent: 26 September 2014 13:53
> To: Steve Roylance
> Cc: Rob Stradling; Erwann Abalea; Brian Smith; CABFPub
> Subject: Re: [cabfpub] Ballot for limited exemption to RFC 5280
> forCTimplementation
>
> 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?

[Steve Roylance] Let's use the words "non publically trusted" rather than
test.  It's simply a CA created from a CT Root to avoid breaking 5280 and 
duplicating serial numbers:-

Root1	- CA1 - EE1
	- CA1 - CA1a - TBSEE1a
	- CA2 - EE2
	- CA2 - CA2a - TBSEE2a
Root2	- CA3 - EE3
	- CA3 - CA3a - TBSEE1a
	- CA4 - EE4
	- CA4 - CA4a - TBSEE4a

Where Root1 and Root2 are publically trusted and CA1,CA2,CA3,CA4 are 4 product
lines and where CA1a etc is a CA that breaks P/L constraints to issue a
TBSCertificate TBSEE1a etc that would be used to get the SCT for EE1

With the Non Publically Trusted way you would have

CT Root - CA1a - TBSEE1a
	- CA2a - TBSEE2a
	- CA3a - TBSEE3a
	- CA4a - TBSEE4a

Root1	- CA1 - EE1
	- CA2 - EE2
Root2	- CA3 - EE3
	- CA4 - EE4

Only the CT Root is extra here as all other CAs need to be created but P/L is 
not
broken.  CA1a can be 99.9% the same as CA1 with the only exception being SKI
meaning that TBSEE1a can be 99.9% the same as EE1 apart from the AKI.....but
in saying this that's true today for the previous model (A point I missed
prior to drawing it so see my conclusion)

>
> > 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?

[Steve Roylance] Yes but only one CT Root

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

[Steve Roylance] Agreed if you wanted to use the other methods...but if those
other methods were viable across all platforms, which they are not, you don't
gain anything.   Maybe in time the precert model dies and other models stick,
but today we need the precert to work.

>
> > 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!

[Steve Roylance] Sorry for not being clear.  I understand that you can't
simply allow any old root cert to be accepted by the logs as this allows
anyone to submit a TBScertifiacte including a valuable domain and suddenly
alarm bells go off, so you need to only accept Roots (Public or as I'm saying
Non Public) from CAs to avoid false positives.

>
> > 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?

[Steve Roylance] In drawing out the cert hierarchy above I concluded that you
either must be ignoring the AKI of the issuing CA in the TBSCert already or
forcing the use of dual serial numbers.   I suppose what I'm lacking is a
simple explanation of the relevant building blocks of the TBSCertificate that
the SCT's hash is based on.  We know it misses out the Poison Extension
and the not before but does it also miss out the AKI and then grab it from the
issuing CA further up the chain?  If you have a reference to a page where this
is detailed that would be great.  I saw others asking for it on the lists and
the answer from Brad was "everything". 
http://www.ietf.org/mail-archive/web/trans/current/msg00498.html but that 
can't include AKI UNLESS you duplicate the S/N and break RFC5280.

I appreciate your time in looking at this for me.

> >
> > 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
> >
-------------- 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/20140926/44ec6624/attachment-0001.bin 


More information about the Public mailing list