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] Re: The elements formerly known as TargetAuthority and TargetSubject

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

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

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]