Re: How to request a WebID?

What l learned by trial is that not all browsers use the hints in the ca message of ssl. Others use it, quite literally. Both behaviours are conforming, as the message contains hints (only) by design. Your implementation may cue off the hints, or it may ignore them. Opera ignores. Ie uses. I dont know what safari does. I don't know what 10 browsers in iPhone-like phone browsers do.

In my https client, I uses a STD dialog of windows, also used by ie I suspect. The dialog allows several selectors, each of which constrain which of the certs in a users personal trust store are shown. (I don't know if this works on a windows phone, though.) Two options are natural (they are the kind of knowhow a security professional would be expected to show, on a certification test): using cert policy oid (as selector), using application policy oid (as selector).

There is another angle: whether any and all (selected) certs should be shown that match, or only those that have the netscape (or better the iso) client usage oid. But this begs yet another question: must that extension be marked critical? If it's not, an implementation is entitled to ignore it's hint. Thus unit test for client tend to be platform specific, unless one is careful.

In general, these activities are called profiling the x509 standard. One well worked out profile is pkix, that is largely ignored by the web at large where ssl client certs are concerned. The web folk tend to fire up OpenSSL, read a page or 2 from the 100 page pkix spec, and be happy when things "work" for 80% of a small group of friends (who typically share platform preferences). I call this the pgp-mode of x509, and could not be more delighted that it's the web practice (since it shows that x509 can be very pgp-ppy with self-signed certs and adhoc profiling, in addition to implementing national identity card like programs suitable for detecting fraud, signing loan documents, or tracking criminals etc).




On Apr 6, 2011, at 1:39 AM, Henry Story <henry.story@bblfish.net> wrote:

> 
> On 5 Apr 2011, at 17:46, Peter Williams wrote:
> 
>> What name will you choose?
> 
> That is of course something we need to agree upon, and all be very serious about doing exactly correctly.
> I think we then need:
>  - language for the spec
>  - a good test suite to verify the implementations
> 
> Currently I am using
> 
> static final String issuer = "O=FOAF\\+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority"; 
> 
> Perhaps we could now get a W3C ID.
> 
>> Will it mean any thing to 1 billion users in china? Will Russians object to the use of roman characters? Why cannot Thai folk see Thai style writing?
> 
> That has never been a problem. 
> They seem happy to use the web, where the main verbs are GET, PUT, POST and delete. 
> 
>> 
>> 2 modern, professional choices:
>> 
>> Have all certs bear a common cert policy oid, with accompanying uri.
> 
> "Modern", "Professional" is empty marketing jargon that belongs on chewing gum packets
> http://blogs.sun.com/bblfish/entry/professionnel
> 
> What we are trying to deal with here is how to get the browsers to only show specific certificates to their user. The only implemented mechanism we know of until know is the one available in the SSL Certificate Request Message, certificate_authorities field. This allows a certificate request to list a number of certificate authorities, of which one could be the WebID cert.
> 
> We could also put a small paper together to suggest futher TLS improvements for WebID which would solve these problems. Though that will probably take 5 years to succeed: 1-2 years for WebID to be deployed enough for the skeptics to take it seriously enough to start an IETF group. 1-2 years for that group to produce the spec. 2 years for the browsers to implement. 3 years for enough browsers to have shipped for it to be useful. (some of these can go on in parallel)
> 
>> Have all certs bear an application policy oid , like 50 windows apps using https exploit to segment the https world into 50 variants of https - with different discovery/validation/revocation practices per appid.
>> 
>> Both suggestions require v3 certs, which hurts use of v1 certs.
> 
> Do any of those work in current browsers to restrict the choice of certificates?
> 
>> 
>> In the v1 world, one played tricks. If the issuer name had rdn with oid of x.y.z do not display it (by definition) bur use it as a discriminatory. This was acceptable as the resolver indicated which rdns in the name were distinguished, and which were merely non security enforcing hints.
>> 
>> Make sure it works when non browser https clients are using webids (such as servers accessing sparql endpoints).
>> 
>> 
>> On Apr 5, 2011, at 6:31 AM, Henry Story <henry.story@bblfish.net> wrote:
>> 
>>> 
>>> On 5 Apr 2011, at 15:01, Nathan wrote:
>>> 
>>>> Hi All,
>>>> 
>>>> A possible issue, how does a server specifically tell a client that it's trying to auth with WebID?
>>> 
>>> This is ISSUE-15: Native browser-based WebID-only certificate display
>>> 
>>> (the name could do with improvement)
>>> 
>>>> 
>>>> Let's suppose for a moment that somebody else comes up with (or already uses) an authentication protocol which also uses client side certs as identifiers, let's call is SSL-ID.
>>>> 
>>>> In my browser I have 2 certificates, my WebID one, and my SSL-ID one, so:
>>>> 
>>>> 1) how does a server inform the client that it's requesting a WebID or an SSL-ID?
>>>> 2) how do I (as a user) know which to select, when all that's presented is a "please select your 
>>>> certificate"?
>>> 
>>> If all WebId enabled certificates that were self signed used the same DN then one could
>>> use the build in certificate selection mechanism of TLS
>>> 
>>> This was brought up here initially by Bruno Harbulot:
>>> http://lists.foaf-project.org/pipermail/foaf-protocols/2009-April/000450.html
>>> 
>>> It would require us to come up with such a DN, and for all WebID generated certificates to place those
>>> in the Certificates.
>>> 
>>> There is an issue of how this would be compatible with CA issued certs with WebIDs too. There we should perhaps recommend a TLS protocol improvement.
>>> 
>>>> 
>>>> We may need to address this, or include technologies which cater for this (I can't think of any off the top of my head, but then I haven't looked or paid attention to this use case yet - may follow up later if I find some).
>>>> 
>>>> Best,
>>>> 
>>>> Nathan
>>>> 
> 
> 
>

Received on Wednesday, 6 April 2011 15:18:33 UTC