[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Trust (was: Re: [xri] Re: The elements formerly known as TargetAuthority and TargetSubject)
Comments inline: -------------------------------------------------- From: "Scott Cantor" <cantor.2@osu.edu> Sent: Monday, July 06, 2009 10:57 PM To: "Sakimura Nat" <n-sakimura@nri.co.jp> Cc: "'Drummond Reed'" <drummond.reed@cordance.net>; "'Breno de Medeiros'" <breno@google.com>; "'XRI TC'" <xri@lists.oasis-open.org> Subject: RE: [xri] Re: The elements formerly known as TargetAuthority and TargetSubject > Nat Sakimura wrote on 2009-07-06: >> Right. When I was writing "exact match", I was murmuring >> "whatever is 'exact match'?". Anyways, none the less, >> the point is that we probably have a profile and places >> to reference for this case. > > Not so much, in my experience. Most standards always leave trust out of > scope, and there are reasons for that, but with very few exceptions nobody > tends to pick up that slack, and we're left with sloppy half-solutions > based > on perceptions of how PKIX works and a bunch of broken PKI libraries that > don't even correctly implement what they attempt to. > >> In case of the "1. Root ID Trust"/"Case B) : Third Party X.509 > Certificate" >> there probably is no place to reference to, and this is >> even bigger a problem... That's what I wanted to especially express. >> >> Do you have any suggestions? > > I would need to understand the motivating use case(s) better to say > whether > the work that I'm involved in has applicability or not. It is a rather basic use case. Suppose I host my own XRD on my host: sakimura.org, including my OpenID, sakimura.org/nat. I am not providing OpenID Authentication Service however. So, I am delegating to exampleop.com. So, it would look like: <xrd> <Subject>http://sakimura.org/nat#1324</subject> <Alias>http://sakimura.org/nat</Alias> <link> <rel>http://spec.example.net/auth/1.0</re> <URI>http://exampleop.com/authn</URI> <Subject>http://exampleop.com/</Subject> <link> <ds:Signature ...> ... </ds:Signature> <ds:KeyInfo> <ds:X509Data> ... </ds:X509Data> <ds:KeyInfo> </xrd> This XRD has to be able to establish its authenticity through its signature. Otherwise, linking to another XRD as above may not be authoritative either. > > But I would say that any place you can devolve the processing rules to > public key comparisons, you're better off doing that, or at least > codifying > it as a profile option. That is the only well-defined (and not insanely > complex) processing model that exists when it comes to anything involving > certificates. I agree. I have discussed that back in iiw2008b as well. We could have put the public key in the <Subject>. As long as the user secret key is not compromised, this looks good. The problem is the key rotation. You might want to change the key-pair for one reason or another. This would imply changing the cannonical ID (<Subject>), and has adverse effect in terms of OpenID etc. that you would have to transition the ID on RPs as well. > > That can be done pretty easily be restricting the "required to support" > KeyInfo content to types that can directly provide a public key (i.e. > KeyValue and X509Certificate). > > -- Scott > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]