[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] XRD trusted discovery workflow
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]