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] Trust


Nat Sakimura wrote on 2009-07-16:
> As I have expressed in the telecon, I did not mean that the signer must be
> the Subject himself, but I meant that it is the designated signatory.

Right, we can ignore all that. Suffice to say, my point is that one can
imagine the possibility that signing an XRD containing other keys, much like
signing SAML HoK assertions or metadata documents, is essentially a
substitute for X.509 certificates that removes the dependency on DN and
other pieces of X.500.

Reasonable people can differ on the value of that, but some people at least
view the use of XML and the opportunity to create much more constrained
validation profiles as an improvement over ASN.1 and PKIX.

> Yeah. It is rather unfortunate. I still think that a community can set up
a
> CA with restricted use of SubjectAltName to solve the problem, but it is
not
> something that should be in a spec., but community rule.

Of course they can, but when the community is large, it falls apart.
 
> Do you think a third party signature service will help ease the problem?

It creates alternative ways to scale the system and it allows you to isolate
the pieces of the system that have to ultimately use something like PKIX to
bootstrap trust. As I said on the last call, you can essentially think of it
as a vehicle for getting out of PKIX as early as humanly possible to improve
the runtime predictability of the system. The reason being that PKIX
implementations are so brittle that the result of any particular runtime
decision borders on indeterminate.

-- Scott




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