- 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