W3C home > Mailing lists > Public > public-xg-webid@w3.org > February 2011

Re: WebID-ISSUE-19: x509v3 Independence and TLS Extensions [WebID Spec]

From: Henry Story <henry.story@bblfish.net>
Date: Tue, 1 Feb 2011 18:37:34 +0100
Message-Id: <B41BD35E-9137-4481-B2D4-9D80870B98E6@bblfish.net>
To: WebID Incubator Group WG <public-xg-webid@w3.org>

On 1 Feb 2011, at 11:18, WebID Incubator Group Issue Tracker wrote:

> aised by: Nathan Rixham
> On product: WebID Spec
> 
> 
> WebID Protocol is currently tightly bound to the use of X.509v3 certificates, re-purposing the subjectAltName extension in order to carry an "Identification Agents" "WebID URI".
> 
> However, RFC 4346 "Transport Layer Security (TLS) Extensions" [1] (obsoleting RFC 3546) defines several general extension methods including "Extended Client Hello" [2].
> 
> The Client Hello of TLS can be extended in order to pass the identifying agents "WebID URI" in a certificate independent manner, by creating a well defined extension.
> 
> This approach is already used by such specifications as Secure Remote Password (SRP) [3,4,5] which defines the "SRP Extension" [6] in order to pass user names via Client Hello.

very interesting. 

> 
> The definition and use of a TLS extension would remove the need for "custom" X.509v3 certificates which require the presence of a "WebID URI" in the subjectAlternativeName certificate extension, allowing any X.509v3 certificate

Yes. Though it is not as if the SAN has been difficult to implement by anyone or difficult to use. In fact the good thing is that the SAN appears in all browsers certificate viewers. I doubt that any of these extensions has such wide support.

> (should the use of certificates be deemed as needed), or the use of PGP Certificates as defined by TLSPGP[7],

Very interesting. It looks and feels a bit like content negotiation at the TLS layer. Being able to send a PGP key in the cert could allow for multiple Signers (or Issuer Alternative Names). One could do something with that I am sure, but the use case would need developing carefully. The disadvantage is that in the immediate time frame it has very little browser support I imagine. But it does open some possibilities for longer term ideas... 

...though in that case, why not work on an (binary) XML certificate instead, and get rid
of ASN.1 completely. PGP or X509 certs are both of them based on ASN.1 a most old and
treacherous standard. There is really nothing special and magical about PGP or X509. They are just signed documents.

Just to give you an idea on how much support this has, in the book "SSL and TLS: Theory and Practice" a book recommended to us by Peter Williams, Rolf Oppliger the author, after a nice chapter on PGP write "Because it is not relevant to SSL/TLS, we don't delve deeper into this topic"

> and additionally resolve ISSUE-1 "Multiple URI entries in the SAN extension".

Not sure how it solves the Multiple URI entries in the SAN extension, which to me is in any case not a problem. It's more something that needs to be explained. On the semantic Web we live very well with the reality that one thing can have multiple names ( URIs ). It's not an issue. 

In any case my guess is that few (if any) browsers currently implement this, so that  need to specify the X.509 version and how to deal with multiple SANs. Dealing with Multiple SANs is going to be a lot easier to specify and work with, than getting browser vendors to add extensions to their TLS layers.

Thanks for pointing out some new possibilities with TLS. 

> 
> [1] http://tools.ietf.org/html/rfc4366
> [2] http://tools.ietf.org/html/rfc4366#section-2.1
> [3] http://en.wikipedia.org/wiki/Secure_remote_password_protocol
> [4] http://srp.stanford.edu/
> [5] http://tools.ietf.org/html/rfc2945
> [6] http://tools.ietf.org/html/rfc5054#section-2.8.1
> [7] http://tools.ietf.org/html/rfc5081

Social Web Architect
http://bblfish.net/
Received on Tuesday, 1 February 2011 17:38:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:22 UTC