Re: [TLS] Consensus call for certificate URL extension

=?iso-8859-1?Q?Magnus_Nystr=F6m?= wrote:
> 
> I do not know if this extension still has value or not, but as one of the 
> authors of the original RFC 3546, I just wanted to provide some background 
> ...
> 
> This extension came about a long time ago when the WAP Forum (today: Open 
> Mobile Alliance) was looking at introducing support for TLS in their 
> architecture. Given bandwidth-constraints in the mobile networks at the 
> time, it made sense to devise a way for clients to not having to send 
> their certificates (or chains) but rather have the servers pick them up 
> somewhere. Clearly, today's networks are more capable.

Avoiding XML where it isn't necessary will save magnitudes more than
an average SSL client cert (except maybe for CAs that abuse certs
as digital junkyards), and SSL session caching will not only save
bandwidth, but also computing power, especially on thin clients.

The client should not need to send any chain certificates besides
its own End-Entity (EE) cert if the CA which signed the clients EE cert
has been announced by the server in the certificate_authorities
list of the CertificateRequest message.

We should have fixed the wording of the TLS specs 1.0/1.1/1.2 
in this regard...  The certificate_list is originally defined in
7.4.2 in the Server Certificate message--where the server doesn't
know anything about the trust anchors known to the client and
therefore sending the entire chain is appropriate.

The structure is then referenced/reused in 7.4.6. Client Certificate,
but it fails to account for the fact that the client has been sent
a list of acceptable trust anchors by the Server in the CertificateRequest
message and ought therefore be perfectly capable to verify a reduced
chain up to one of the announced trust anchors from the
certificate_authorities list, not only a full chain up to a self-signed root.

-Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls