RE: [xri] subject sets (also sort of: Agenda for August 6, 2009call)

[Eran Hammer-Lahav <eran@hueniverse.com>]

This is consistent with how we scoped XRD and LRDD.

EHL

> -----Original Message-----
> From: John Bradley [mailto:jbradley@mac.com]
> Sent: Friday, August 07, 2009 11:15 AM
> To: Scott Cantor
> Cc: 'Will Norris'; 'XRI TC'
> Subject: Re: [xri] subject sets (also sort of: Agenda for August 6,
> 2009 call)
> 
> If I have a URI  http://foo.com/test  that retrieves a XRD with the
> subject https://bar.com/john
> 
> There is no XRD requirement that anything in the XRD match
> http://foo.com/test
> .
> 
> There may be a requirement in LRDD or XRI resolution or something like
> that but not in XRD.
> 
> All XRD can do is say something about the subject and via one of the
> trust models how to verify the subject.
> 
> ie if you got it as the result of a link from a parent XRD did the
> parent specify signing keys?
> Do you have pre-configured signing keys?
> Is there some acceptable relationship between the subject and the CN
> or subjectaltname in the cert?
> 
> XRD should not impose a verification requirement on the resolving
> protocol using XRD.
> 
> There is also the case LRDD may want where there is no explicit
> subject in the XRD,  in that case LRDD could define the XRD to be
> about the URI that was used as the input or the normalized input, or
> the input after redirects are followed or something else completely,
> that would be up to LRDD.
> 
> So I think my take on it is the XRD is about its subject unless there
> is no subject in which case it is about whatever the resolving
> protocol decides it is about.
> 
> John B.
> On 7-Aug-09, at 10:12 AM, Scott Cantor wrote:
> 
> > Will Norris wrote on 2009-08-06:
> >> John Bradley, Nat Sakimura, and myself were present on the call.  So
> >> perhaps this will be a lesson in what happens when folks don't show
> >> up
> >> on the call :)
> >
> > It's a pretty late call for me, so I tend to forget if I don't see an
> > agenda. But I did just flat out forget.
> >
> >> First, in the PKI trust model, a consuming applications trusts the
> >> signature of an XRD if:
> >>  - the signature is valid for the document (of course)
> >>  - the certificate was issued by a trusted certificate authority
> >>  - the subject of the certificate matches the authority of the XRD
> >> Subject URI
> >
> > That third item is still very underspecified, IMHO. Are you talking
> > about a
> > hostname match? What if the URI in the subject isn't http/https and
> > has no
> > hostname?
> >
> > And why do I have to sign with a certificate containing the same
> > "authority"? What if I want a third party to sign it?
> >
> > This is not something I understood to be an assumption of XRD. The
> > subject
> > of a certificate is only *that*. It's about the entity possessing
> > the key.
> > That should be orthogonal to the XRD Subject.
> >
> > What I'm trying to say is that "PKI trust model" means nothing more
> > or less
> > than "I have a model for establishing a relationship between the XRD
> > signer
> > and the XRD subject, and a way to establish the validity of the
> > signer's
> > key". I don't think it's right to bake more into it than that.
> >
> >> I know that it is (or should be) a requirement that the XRD Subject
> >> have the same authority as the resource URI used to discover the
> XRD,
> >> since anytime you pass between authorities you need some kind of
> >> Signature (this was the whole argument for using XRD for host-meta
> in
> >> the first place).
> >
> > Same question about "authorities". What is that term referring to in
> > general?
> >
> >> None of the three of us on the call could remember whether it was
> >> required that the resource URI used to discover the XRD be
> referenced
> >> in the XRD itself.  John was under the impression that this is not
> >> required.  I honestly couldn't remember.  So that's something we
> >> definitely need to establish.  Is that something we had intended all
> >> along?  Does it make sense to require this?  What's the risk if it's
> >> not part of XRD Trust?
> >
> > I don't see how you avoid this requirement. If a bunch of XRDs are
> > signed by
> > some common authority, how would you know which one is really about
> > your
> > resource?
> >
> > -- Scott
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> 
> 
> ---------------------------------------------------------------------
> 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