Re: [xri] XRD trusted discovery workflow

[John Bradley <jbradley@mac.com>]

There in lies the difference between Nat and Brian's approach.

Brian wants to leverage existing SSL Certs issued based solely on the  
Authority segment as they are now.

I don't know if a typical SSL Cert is valid for signing doc's in this  
way some may not have digitalSignature in there Key Usage,  but this  
is at least closer to what a CA expects to issue Cert's for.

So http://example.com/alice and http://example.com/foo/alice both need  
to be signed by the URL authority segments SSL cert.

Nat want to use Certs that contain the path as well as the authority.

In this case http://example.com/foo/alice would be signed by a http://example.com/foo/alice 
  cert .

That Cert could be signed by a CA directly or by signing cert issued  
to example.com, or even http://example.com/foo.  All depending on how  
you want to construct the trust chain.

In the latter proposal there are questions around the use of Subject,  
subjectAltName.

Certainly subjectAltName supports URI

When the subjectAltName extension contains a URI, the name MUST be  
stored in the uniformResourceIdentifier (an IA5String). The name MUST  
NOT be a relative URL, and it MUST follow the URL syntax and encoding  
rules specified in [RFC 1738]. The name MUST include both a scheme  
(e.g., "http" or "ftp") and a scheme-specific-part. The scheme- 
specific-part MUST include a fully qualified domain name or IP address  
as the host.
Interestingly my reading is that a xri: schemed URI would not be a  
valid subjectAltName.   Though I don't know there logic for  
restricting it to DNS based URI schemes.

=jbradley


On 12-Dec-08, at 10:18 AM, Peter Davis wrote:

> On Dec 11, 2008, at 6:13 PM, Sakimura Nat wrote:
>
>> That is, if it were http://example.com/alice and http://example.com/bob 
>>  , then it should be example.com that signs this.
>
> I am not sure that I agree completely on this for all cases.  take,  
> for example:
>
> 	https://example.com/foo/alice
>
> It is entirely plausible that the naming authority is /foo (not  
> example.com).  Similarly, for:
> 	
> 	https://foo.example.com/foo/alice
>
> the naming authority _could_ be any of:
> 	
> 	foo.example.com/foo
> 	foo.example.com
> 	example.com
>
> all of which should be considered valid
>
> =peterd
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

smime.p7s