- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Sun, 08 Jan 2012 17:55:37 -0500
- To: public-xg-webid@w3.org
- Message-ID: <4F0A1EE9.70409@openlinksw.com>
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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Sunday, 8 January 2012 22:56:00 UTC