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

[Breno de Medeiros <breno@google.com>]

Comments inline. Can I get a volunteer to put this in a formal draft
so that these corrections are easier to make?

If not, I will incorporate comments as they come and spam this list
daily with incorporated corrections :)

On Wed, Jan 20, 2010 at 15:23, Scott Cantor <cantor.2@osu.edu> wrote:
> 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.... ;-)

Good point. I think this should be dropped.

>
>> 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...).

Yes, that's what I meant, and your language makes it clearer.

>
>> 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."

Ah, missed that. I guess we can remove the critical flag requirement.

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

Good catch. My initial draft allowed for that, but Eran made a few
edits prior to my submission and I think he 'corrected' this out.


> -- Scott
>
>
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)