[cabfpub] Ballot for limited exemption to RFC 5280 forCTimplementation
Ben Laurie
benl at google.com
Wed Oct 1 10:37:30 MST 2014
On 1 October 2014 17:51, Ryan Sleevi <sleevi at google.com> wrote:
>
> 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".
I think its important to understand that this text comes from the
section describing how to calculate an SCT.
> 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
Neither of these options properly captures what's going on, I think.
The essence is:
1. When a precertificate is presented, the SCT is calculated over a
TBSCertificate that is derived from the precertificate as described
(this is unambiguous, since the text comes from the description of a
structure that is only used for precertificate log entries).
2. That TBSCertificate is calculated as defined above (note that two
methods are described, one from a precert and one from the
corresponding cert).
3. The structure that includes that TBSCertificate is only used in a
digitally-signed struct - this is a slightly confusing thing (that
comes from TLS, so don't blame me): the content of a digitally-signed
struct is used to calculate a signature, but does not actually appear
in the resulting data. So, this modified TBSCertificate only ever
exists as part of a signature calculation.
So, both the log, when calculating the SCT, and the client, when
verifying the SCT, need to construct this TBSCertificate. The log
constructs it from the precert, the client from the real cert (where
"client" in this case means a TLS client, not a log client!).
> 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
More information about the Public
mailing list