On 2019-12-09 11:44, Ben Laurie wrote:
On Wed, 4 Dec 2019 at 22:13, Ryan Sleevi <r...@sleevi.com> wrote:
Yes, I am one of the ones who actively disputes the notion that AIA
considered harmful.
I'm (plesantly) surprised that any CA would be opposed to AIA (i.e.
supportive of "considered harmful", since it's inherently what gives them
the flexibility to make their many design mistakes in their PKI and still
have certificates work. The only way "considered harmful" would work is if
we actively remove the flexibility afforded CAs in this realm, which I'm
highly supportive of, but which definitely encourages more distinctive PKIs
(i.e. more explicitly reducing the use of Web PKI in non-Web cases)
Of course, AIA is also valuable in helping browsers push the web forward,
so I can see why "considered harmful" is useful, especially in that it
helps further the notion that root certificates are a thing of value (and
whose value should increase with age). AIA is one of the key tools to
helping prevent that, which we know is key to ensuring a more flexible, and
agile, ecosystem.
The flaw, of course, in a "considered harmful", is the notion that there's
One Chain or One Right Chain. That's not the world we have, nor have we
ever. The notion that there's One Right Chain for a TLS server to send
presumes there's One Right Set of CA Trust Anchors. And while that's
definitely a world we could pursue, I think we know from the past history
of CA incidents, there's incredible benefit to users to being able to
respond to CA security incidents differently, to remove trust in
deprecated/insecure things differently, and to set policies differently.
And so we can't expect servers to know the Right Chain because there isn't
One Right Chain, and AIA (or intermediate preloading with rapid updates)
can help address that.
It would be a whole lot more efficient and private if the servers did the
chasing.
It would also greatly help if:
1. More clients (especially non-browser client such as libraries used by
IoT devices) supported treating the received "chain" more like a pool
of potential intermediaries and accepted any acceptable combination of
received certs and locally trusted roots. This would allow servers to
send an appropriate collection of intermediaries for different client
needs. Clients that detect different levels of trust (such as the
Qualsys checkers and EV clients) also need to choose the best of the
offered set, as the alternative certs are obviously for use by other
clients. In particular, clients should not panic and block on the
presence of any "bad" certificates in the pool, if a valid chain can
be assembled without that certificate.
This is already in the CMS/PKCS#7 spec and apparently also in the TLS
1.3 spec, but remains seemingly optional when TLS 1.2 or older is
negotiated.
I recently became aware of at least one IoT-focused TLS library that
doesn't support the "pool" interpretation due to lack of a memory-
efficient chain building algorithm.
2. Certain CAs made it a lot easier to get the recommended-to-send list
of certificates ("chain") for server operators to configure. Some
CAs make server operators manually chase down links to each cert in
the list, and some don't send out pre-emptive notification of changes
to paying subscribers.
3. Certain TLS libraries didn't refuse to provide server software
vendors with working stapling code, especially the code to collect
and cache OCSP responses.
P.S. One commonly wilified server brand actually does use AIA to build
the server chain.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
