[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Re: The elements formerly known as TargetAuthority and TargetSubject
-------------------------------------------------- From: "Scott Cantor" <cantor.2@osu.edu> Sent: Friday, July 03, 2009 5:17 AM To: "Sakimura Nat" <n-sakimura@nri.co.jp>; "'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-02: >> 1. Root XRD Trust >> >> The starting XRD, in this case, XRD1 MUST be signed in such a way that >> >> Case B) : Third Party X.509 Certificate >> In this case, XRD/ds:KeyInfo/X509Data/ must somehow related to >> XRD/Subject. <<<< This needs to be defined! > > I totally agree, but would also caution that it seems to me you're all > biting off an awful big job here. This amounts to defining a PKI with > Naming > Constraints, something that has pretty much failed elsewhere, so is that > really in scope to do here? Should it be left to subsequent profiling? Yeah. This is a big issue. Perhaps just let it be profiled in a community would be a good compromise for the time being. > >> 2. Delegation >> >> For delegation, besides XRD2's integrity is ok as in 1. above, > > I'm having trouble understanding one piece of this...what is the > original/delegating XRD signed with? The same key that signs XRD2? It has > to > be signed with something (or authenticated some other way) or this isn't > useful. If I can attack the original document, I can just point it my XRD. > >> Case A) If XRD1/Link has Subject, >> XRD1/Link/Subject MUST match XRD2/Subject >> >> Case B) Else >> XRD1/Link/ds:KeyInfo == XRD2/ds:KeyInfo >> >> <<<< OR shall we just say that >> pub key in the XRD1/Link/ds:KeyInfo >> == pub key in the XRD2/ds:KeyInfo ? > > I think it's the same as my earlier concern...that's an awfully big piece > of > work to take on. > This is easier than the previous one. We just want an exact match. > My only other comment on Drummond's text was that I would suggest against > trying to profile ds:KeyName into some XRD-specific meaning. If you want > to > identify an <xrd:Subject> as a way of identifying a key, just put that > element directly into <ds:KeyInfo> (it's extensible). > > -- Scott > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]