Re: WebID equivalence

On 3 Jan 2012, at 23:28, Kingsley Idehen wrote:

> On 1/3/12 4:37 PM, Mo McRoberts wrote:
>> On 3 Jan 2012, at 14:36, Kingsley Idehen wrote:
>> 
>>>> CN=www.freesoft.org is not a CN containing a URL, for a start. A CN is effectively arbitrary, will often be used for matching (cf. clients comparing SSL server hostnames).
>>> And emailAddress is not an Address either right?
>> An emailAddress is an email address. Sheesh.
>> 
>>> What do you think www.freesoft.org is then?
>> Broadly: a FQDN
>> 
>> In a commonName RDN value: an arbitrary label, which in a client cert is used for nothing except advertising. In SSL servers, it's used as a match source against what the UA expects it to be (which by convention, for reasons which are now obvious, is the FQDN of the server or a wildcarded derivative). But, to date, it still is largely a comparator — the closest you get to triggered behaviour when a certificate is presented is querying a locally-configured directory service for an entity matching the DN.
>> 
>>>> (You could add a URI as a DN attribute, though, if you know the signing entity will accept it — just pick or define an appropriate attribute OID).
>>>> 
>>>> Whether *parts* of a DN should trigger special processing on the part of a receiver is a different matter. I can't recall what ITU recs have to say on the subject. I do know that a number of free personal certificate issuers mandate that the CN is a fixed string.
>>> We are using a standard representation of an info card and its semantics, to construct a protocol with its own set of semantics i.e., the WebID verification protocol. Nothing that I've stated breaks anything re. X.509 or PKI. Neither does it break WebID. Its only issue is novelty.
>> Of course it doesn't break anything re: X.509 or PKI. And it is a neat trick in novelty stakes, just like my terminal emulator turning URIs which appear in its window into hyperlinks is a neat (if imperfect) trick.
>> 
>> What sprang to mind was whether what -other people- are doing with those RDNs (i.e., anything they like) would break what you were doing when you processed them.
>> 
>> And, if you're overloading semantics of DNs, you're as well just defining a new attribute…
> 
> My system is the WebID protocol, I don't expect it to trip up others who are using the same infrastructure for something a little different :-)

The WebID protocol ( http://webid.info/spec ) does not mention the DN, except as a place to put a human readable name in conformance with RFC 5280

  http://tools.ietf.org/html/rfc5280

 Standard sets of attributes have been defined in the X.500 series of
   specifications [
X.520
].  Implementations of this specification MUST
   be prepared to receive the following standard attribute types in
   issuer and subject (
Section 4.1.2.6
) names:

      * country,
      * organization,
      * organizational unit,
      * distinguished name qualifier,
      * state or province name,
      * common name (e.g., "Susan Housley"), and
      * serial number.

That is pretty clear right?

 In addition, implementations of this specification MUST be prepared
   to receive the domainComponent attribute, as defined in [
RFC4519
].
   The Domain Name System (DNS) provides a hierarchical resource
   labeling system.  This attribute provides a convenient mechanism for
   organizations that wish to use DNs that parallel their DNS names.
   This is not a replacement for the dNSName component of the
   alternative name extensions. 

So even the IETF people are pushing people to move DNS names to the SAN fields.

We should be trying to be stick with the IETF specs and use them as required.

Henry

>> 
>> M.
>> 
> 
> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	
> Founder&  CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> 
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/

Received on Tuesday, 3 January 2012 23:22:24 UTC