Re: WebID equivalence

Some specific notes:


>> 1. Subject: C=MY, ST=STATE, L=CITY, O=ONE INC, OU=IT, CN=www.example.com

A server certificate, where the FQDN carried in the CN is used as part of a *matching* process.

>> 2. Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
>>               OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org

(For the avoidance of doubt, note that CN and emailAddress are two separate attributes, it's just that the syntax for printing them is sometimes a little confusing).

emailAddress is an e-mail address, that’s a given. *Typically* it’s there in client certs because the issuer only has the fact that the certificate requestor was able to click a 'verify e-mail address' link as the sole piece of verified (and so differentiating) information.

Putting a domain name in the CN in a client certificate serves no practical purpose beyond advertising to people and making certificate-selection dialogs even more confusing than they are anyway. It’s still just an arbitrary label which happens to contain a domain name. More often than not where domain names DO appear in client cert CNs, they're not a domain name belonging to the subject.

>> 3. Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
>>               OU=FreeSoft, CN=MyOrganization Literal Label/emailAddress=baccala@freesoft.org .

Same as above.

And yes, you can quite cheerfully attempt to do WebFinger lookups on an emailAddress attribute in a DN, or do them on an acct: URI in a subjectAlternativeName, or do them on an rfc822Address in a subjectAlternativeName. There's no question about that; it doesn't appear in the spec, and unless some WebFinger-providing service starts offering the ability to link through to some FOAF which can contain a cert:RSAPublicKey, I can't see that there's a hugely compelling case for it to, either.

What's (still) not clear is why you'd bother exposing your e-mail address to the world in your certificate when you can have a URI to your WebID profile anyway. It’s definitely not clear why you’d want to bother exposing implementation details (i.e., your WebID profile can be dereferenced using a URI of some sort carried within the cert) to selection UIs and the like by putting them in the CN. 

Kingsley, you’ve said that you perceive a “bias towards HTTP”, and that’s probably *implicitly* true to an extent: while you could do a lookup against a public LDAP server instead (it's what PGP does, after all), do you not think that most people will end up publishing their profile document via HTTP? And thus, any additional indirection — which isn’t by any means prohibited by the spec — amounts additional complication which really just has novelty value right now… or is there some really compelling justification?

M.

-- 
Mo McRoberts - Technical Lead - The Space,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Project Office: Room 7083, BBC Television Centre, London W12 7RJ



http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Wednesday, 4 January 2012 11:42:27 UTC