Re: [TLS] AIA cert fetching seen as harmful

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Mike <mike-list@xxxxxxxxx> writes:

>What I suggested is that the information about which URL's are safe for the
>client certificate URL extension could be embedded in the -root- certificate,
>which you trust.

And then you look up that URL in your trusted DNS... oops.

(This also ignores the fact that you have to reissue your root cert every time
some random server moves around, which I can't see any CA doing.  Root certs
are issued once, given a lifetime of 20-40 years, and then never touched again
for fear of breaking things).

The real problem here is that a server should never, ever initiate outgoing
connections under the control of an external agent, which is what a lot of the
PKIX protocols expect them to do.  Other examples (just off the top of my
head) are the logotypes and qualified certs/biometrics RFCs, which define an
extension containing a URI that you're supposed to go to for further
information.  So a server, when seeing one of these certs, is supposed to go
to whatever arbitrary location and port is specified and poke around there
(I'm not sure what would happen if you entered, for example, an SSH URI
instead of the more obvious HTTP one, but if the implementation is general
enough you could use it for password-guessing attacks on internal SSH
servers).  It's just a really, really bad idea to build a capability for HTTP
bounce scans into a (supposedly) passive protocol mechanism, and in particular
turning a system that's supposed to provide security into a security hole just
doesn't seem a winning long-term strategy to me.

Peter.
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls