OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]