[cabfpub] Ballot for limited exemption to RFC 5280 forCTimplementation
Ryan Sleevi
sleevi at google.com
Wed Oct 1 09:51:29 MST 2014
On Oct 1, 2014 9:45 AM, "Ben Laurie" <benl at google.com> wrote:
>
> On 26 September 2014 14:37, Steve Roylance
> <steve.roylance at globalsign.com> wrote:
> > 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.
>
> SCTs delivered via OCSP or TLS extension require fewer SCTs, so there
> is definitely a benefit. But in any case, if you want to permit the
> other methods at all, logs have to know the CA roots. Not that this is
> really a problem for CAs anyway ... logs should largely accept
> whatever browsers accept...
>
> >> > 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.
>
> Ah! Actually, false positives are less of a concern (because a cert
> issued by a CA no-one accepts is not a positive) than simply filling
> the log with nonsense...
>
> >> > 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.
>
> >From RFC 6962:
>
> ""tbs_certificate" is the DER-encoded TBSCertificate (see [RFC5280])
>
> component of the Precertificate -- that is, without the signature and
> the poison extension. If the Precertificate is not signed with the
> CA certificate that will issue the final certificate, then the
> TBSCertificate also has its issuer changed to that of the CA that
> will issue the final certificate. Note that it is also possible to
> reconstruct this TBSCertificate from the final certificate by
> extracting the TBSCertificate from it and deleting the SCT extension.
> Also note that since the TBSCertificate contains an
> AlgorithmIdentifier that must match both the Precertificate signature
> algorithm and final certificate signature algorithm, they must be
> signed with the same algorithm and parameters. If the Precertificate
> is issued using a Precertificate Signing Certificate and an Authority
> Key Identifier extension is present in the TBSCertificate, the
> corresponding extension must also be present in the Precertificate
> Signing Certificate -- in this case, the TBSCertificate also has its
> Authority Key Identifier changed to match the final issuer."
>
> In other words, yes, the AKI is changed to the "right" one.
>
I believe the question is "by whom".
Does the log, upon ingesting such a certificate (which includes the SCT
intermediate) substitute the AKI prior to logging the SCT, such that the
produced SCT only requires the client remove the poison extension? Call
this LOG MODIFIES
Or does the client/UA, upon receiving an SCT, perform this substitution
based upon the SCT+Chain presented the client, much in the same way they
remove poison. Call this CLIENT MODIFIES
I know what the answer is from implementation, but Brian's and Steve's
remarks and feedback is that they see it as ambiguous in text, and thus
confusing unless one reads implementation.
> >
> > 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
> >> >
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141001/2cde2243/attachment-0001.html
More information about the Public
mailing list