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
