RE: [xri] Re: The elements formerly known as TargetAuthority and TargetSubject

["Scott Cantor" <cantor.2@osu.edu>]

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?

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

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