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: Trust (was: Re: [xri] Re: The elements formerly known as TargetAuthority and TargetSubject)

Comments inline:

From: "Scott Cantor" <cantor.2@osu.edu>
Sent: Monday, July 06, 2009 10:57 PM
To: "Sakimura Nat" <n-sakimura@nri.co.jp>
Cc: "'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 

> Nat Sakimura wrote on 2009-07-06:
>> Right. When I was writing "exact match", I was murmuring
>> "whatever is 'exact match'?". Anyways, none the less,
>> the point is that we probably have a profile and places
>> to reference for this case.
> Not so much, in my experience. Most standards always leave trust out of
> scope, and there are reasons for that, but with very few exceptions nobody
> tends to pick up that slack, and we're left with sloppy half-solutions 
> based
> on perceptions of how PKIX works and a bunch of broken PKI libraries that
> don't even correctly implement what they attempt to.
>> In case of the "1. Root ID Trust"/"Case B) : Third Party X.509
> Certificate"
>> there probably is no place to reference to, and this is
>> even bigger a problem... That's what I wanted to especially express.
>> Do you have any suggestions?
> I would need to understand the motivating use case(s) better to say 
> whether
> the work that I'm involved in has applicability or not.

It is a rather basic use case.

Suppose I host my own XRD on my host: sakimura.org, including my OpenID,
sakimura.org/nat. I am not providing OpenID Authentication Service however.
So, I am delegating to exampleop.com. So, it would look like:

   <ds:Signature ...>

This XRD has to be able to establish its authenticity through its signature.
Otherwise, linking to another XRD as above may not be authoritative either.

> But I would say that any place you can devolve the processing rules to
> public key comparisons, you're better off doing that, or at least 
> codifying
> it as a profile option. That is the only well-defined (and not insanely
> complex) processing model that exists when it comes to anything involving
> certificates.

I agree. I have discussed that back in iiw2008b as well.
We could have put the public key in the <Subject>.
As long as the user secret key is not compromised, this looks good.
The problem is the key rotation. You might want to change the
key-pair for one reason or another. This would imply changing the
cannonical ID (<Subject>), and has adverse effect in terms of
OpenID etc. that you would have to transition the ID on RPs as well.

> That can be done pretty easily be restricting the "required to support"
> KeyInfo content to types that can directly provide a public key (i.e.
> KeyValue and X509Certificate).
> -- Scott

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