Re: Matter of DN and what's possible

On 1/8/12 3:13 PM, Peter Williams wrote:
> Second, the v3 cert already has an extension address locator, for the 
> "endpoint" at which one shoud expect a MIME typed stream to be 
> returned. Tt avoid the rat trap, is uses the notion of access method: 
> http://www.ietf.org/rfc/rfc3280.txt 4.2.2.2  Subject Information Access 
Yes, this excerpt nails the point:

4.2.2.2  Subject Information Access

    The subject information access extension indicates how to access
    information and services for the subject of the certificate in which
    the extension appears.  When the subject is a CA, information and
    services may include certificate validation services and CA policy.


Thus, we have another official place in a cert that can hold a reference 
to the *location* (an Address) of the certs claim mirror (a profile 
document that describes the cert subject). This basically takes us away 
from the emerging DN argument, and absolutely meets my fundamental goal 
of reducing the complexity associated with publishing "claim mirrors" 
while not violating the fundamental Linked Data principles re. Name and 
Address disambiguation.

We are going to end up with two scenarios that publishers can choose from:

1. > 1 level of indirection via de-referencable URIs in SAN

2. negate > 1 indirection heuristics by using Names (which don't have to 
be de-referencable) in SAN with Subject Information Access extension as 
the mechanism for Identifying the location of a Resource (representation 
negotiable) that holds/bears the directed graph that describes the cert. 
Subject using Names in SAN, and leveraging equivalence semantics as part 
of the endeavor, if need be.


What I describe above will be reflected in the x.509 certs we produce, 
ditto our verifiers. On that you have 100% assurance :-)

-- 

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

Received on Sunday, 8 January 2012 22:56:00 UTC