[cabfpub] A few technical details about the case by TURKTRUST

Ryan Sleevi sleevi at google.com
Wed Jan 9 19:18:00 UTC 2013


On Wed, Jan 9, 2013 at 3:35 AM, Gervase Markham <gerv at mozilla.org> wrote:
> On 08/01/13 18:53, Ryan Sleevi wrote:
>> Depends on which cert you're talking about having the
>> pathLenConstraint. If we're talking about the existing TURKTRUST
>> intermediate, then yes, it would have acted as a mitigation, since EE
>> -> *.EGO -> TT-I -> TT-Root would have violated the pathLenConstraint
>> of TT-I. However, if you're talking about putting it on the *.EGO,
>> then no, it would not have worked.
>
> Yes, I meant the TT intermediate.
>
>> The failure mode of a client not observing pathLenConstraint is going
>> to be failing open, so I don't see browser support as an argument
>> against it.
>
> Right.
>
>> The other thing to consider is that these constraints do work
>> retroactively for existing intermediate. They only apply when a CA
>> issues a new intermediate - which is a very rare event to begin with.

Wow, I accidentally dropped a "not" in here. That is, they *do not*
work retroactively.

>
> Why should that be necessarily so? Is it simply the hassle of getting
> the root key out of storage which means that CAs don't issue new
> intermediates (for the purposes of end-entity issuance) say once a year?
>
> Gerv

Is your question about why is issuing new intermediates a rare event,
why re-issuing is a rare event, or why does this not apply
retroactively?

Issuing new intermediates is rare because it's unnecessary if you have
existing intermediates. Most of the CPSes I've seen also describe the
Root+Intermediate hierarchy, so it potentially means an audited key
signing ceremony and an update to the CPS. It's typically only
necessary when there's a chance in issuance policies or a change in
crypto (eg: SHA-1 -> SHA-256 intermediates)

Re-issuing intermediates is a rare event because
1) It does nothing for client validity if the old intermediate is
still unrevoked
2) It creates lots of confusion for subscribers and RPs, because you
get into situations where servers are misconfigured and either not
sending the intermediate at all or sending the (old) intermediate.
It's then dependent upon the client to either do AIA chasing
(not-Firefox) or, if you've visited a properly configured site with
that same intermediate before, relying on Firefox's in-memory cache
and it's behaviour of caching observed intermediates to it's cert DB
on disk. So one client may work, another won't, and for customers,
it's not entirely obvious to them why that is.

Retroactive application:
1) If you issue a new cert with the old key + subject name, but fail
to revoke the old cert, then both certs are valid and the effective
trust is the equivalent to whichever cert is least constrained (eg: no
pathLen)
2) If you issue a new cert with the old key + subject name, and do
revoke, you get into a mess with clients that perform chain discovery
linearly, rather than as a DAG. Their constructed chains will contain
the revoked cert, and thus treat the chain as revoked, even when
there's an unrevoked equivalent cert. This goes back to the server
misconfiguration case as well.
3) If you issue a new cert with a new key + subject name, and don't
revoke the old cert, then it only applies for new leaves under the new
cert (eg: not retroactively)
4) If you issue a new cert with a new key + subject name, and you do
revoke the old cert, then you need to re-issue all the leaves under
the new intermediate and get customers to reconfigure their servers.



More information about the Public mailing list