RE: [xri] Proposal for an X.509-based XRI Trust Profile

["Scott Cantor" <cantor.2@osu.edu>]

Some minor questions inline.

Breno de Medeiros wrote on 2010-01-20:
> The validation function takes three inputs:
> 
> 3. Root Certificates -the set
> of self-signed certificates that are trusted by the application 'a
> priori'. For instance, a set of commonly known Certificate Authority
> certificates, used to validate other certificates.

Do you actually require trust anchors be self-signed? That's not required by
profiles like PKIX, though OpenSSL remains buggy in this regard for some
reason. I see that the TLS RFC text seems to say otherwise, but it isn't
obvious to me that it's intended normatively, or that it should be. It's not
up to TLS how one does certificate validation, certainly.

The only reason I can think to require this is specifically to accommodate
OpenSSL...is that the motivation? Maybe you have some leverage with certain
co-workers to get the bug fixed.... ;-)

> 2. Certificate Subject Matching
> 
> The client MUST perform the following steps in order (validation fails
> if any of these steps fail):
> 
> i. The XRD Document MUST contain a <ds:KeyInfo> element  per [XRD 1.0]
> section 5.5 and [XML DSig 2] section 4.4.

Do you mean the one inside the Signature block, I assume? It's a little
clearer to say that (e.g. The XRD Document's <ds:Signature> MUST contain a
<ds:KeyInfo> element...).

> iv. If the Authority Name is an absolute URI, its host name is
> extracted per the scheme-specific rules. The Authority Name host must
> match the subject CN in the certificate. Wildcards in the subject CN
> are allowed. If the subject CN does not match, and the certificate
> SubjectAltName extension is marked as critical, then the host MUST
> match against at least one SubjectAltNames present.

Is the criticality part necessary? subjectAltNames are not allowed to be
"unvetted" if they're present.

2459 (which http over tls cites):

"Because the subject alternative name is considered to be definitiviely
bound to the public key, all parts of the subject alternative name MUST be
verified by the CA."

Also, why not allow for URI-based subjectAltNames, and not just DNS?

-- Scott