Re: [TLS] Implementation survey: Client Certificate URL extension

[<Pasi.Eronen at nokia.com>]

This vulnerability of Client Certificate URL is already described in
the Security Considerations text in RFC 4366, so it isn't anything
particularly new.

In the context of web browsing over TLS, it isn't really different
than, say, the ability to include IMG URLs pointing to arbitrary hosts
(not just the one the HTML page came from).

I can see that this could be more of a problem in other contexts:
e.g., email clients don't usually fetch image URLs (since that would
reveal that the address works, when the email was read, approximate
network location of the client, etc.) -- but if they fetch URLs during
S/MIME certification path validation, it would have roughly the same
result.

Best regards,
Pasi

> -----Original Message-----
> From: ext Martin Rex [mailto:Martin.Rex at sap.com] 
> Sent: 03 April, 2008 19:10
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: tls at ietf.org
> Subject: Re: [TLS] Implementation survey: Client Certificate 
> URL extension
> 
> If you read the news, you probably noticed the following paper
> today or these days:
> 
> https://www.cynops.de/techzone/http_over_x509.html
> 
> Although this Papers describes a serious design flaw in the
> rfc3280 suggestion to put URLs of intermediate CAs into X.509v3
> cert extensions and have peers use them in order to be able
> to build a certification path, the very same problem will
> apply to every concept that a communication peer can be
> coerced to access one or more arbitrary URLs prior to
> authentication, and the Client Certificate URL extension
> appears to suffer the same vulnerabilities and security
> problems.
> 
> -Martin
> 
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls