RE: [xri] Question: Is there a standard way to compose an identifier for the public key of an object?

["Tan, William" <William.Tan@neustar.biz>]

Agreed. In this case, the individual would publish multiple certificates
under the /(+public.key)/ path and each will be listed as a <Service> in
the XRD. This will allow the software to present a list of certs for the
user to select from. The downside is that since XRD does not have a
standard way of describing the certificate fields such as usage and
issuer, it would probably have to fetch all of them in order to
determine suitability.

=wil

> -----Original Message-----
> From: Schleiff, Marty [mailto:marty.schleiff@boeing.com]
> Sent: Tuesday, February 07, 2006 12:31 AM
> To: Tan, William; Drummond Reed; Sakimura, Nat;
xri@lists.oasis-open.org
> Subject: RE: [xri] Question: Is there a standard way to compose an
> identifier for the public key of an object?
> 
> What happens if an individual has more than one certificate
(containing
> a public key) for a particular purpose? The individual could have a
> medium assurance certificate ofr encryption and a higher assurance
> certificate for encryption. Also, various signing certs from various
> issuers for various purposes. Today's certificate-aware client
software
> tends to display all the available certs for the individual, and then
> leave it to the individual to select which one to use. It's not very
> user friendly, but it's still left to the user, because it's also hard
> for software to make such a decision.
> 
> 
> Marty.Schleiff@boeing.com; CISSP
> Associate Technical Fellow - Cyber Identity Specialist
> Computing Security Infrastructure
> (206) 679-5933
> 
> -----Original Message-----
> From: Tan, William [mailto:William.Tan@neustar.biz]
> Sent: Sunday, February 05, 2006 10:53 AM
> To: Drummond Reed; Schleiff, Marty; Sakimura, Nat;
> xri@lists.oasis-open.org
> Subject: RE: [xri] Question: Is there a standard way to compose an
> identifier for the public key of an object?
> 
> Nat's idea is an intriguing one.
> 
> The standard way to retrieve the public key of an identity is probably
> best specified by a xrd_service_type value of "+public.key".
> 
> I can then publish my public key using a Service Type of +public.key
and
> the MediaType's would indicate the data formats in which the public
key
> may be represented. E.g. application/x-x509-ca-cert or
> application/pgp-keys.
> 
> What happens if we want to publish more than one public key? E.g. One
> for S/MIME and another for PGP. One way is to couple Path selection
with
> Service Type selection by publishing =Sakimura/(+public.key)/smime and
> =Sakimura/(+public.key)/pgp. This way, an application can easily list
> all the available public keys for the user to decide.
> 
> wil.
> 
> > <NAT>
> > What I was talking about was a standard way to address the public
key
> of
> > an identity/entity. It is illustrated in Drummond's post that
> > =sakimura/(+public.key) would be one way of doing it.
> > What I was suggesting was that it would be nice to have a standard
way
> 
> > to express such so that an application can fetch the public key of
an
> > entity without other knowledge.
> >
> > For the resolution of it, the service end point may return variouls
> > protocol uris. LDAP is one way, but it could be
> > http/https/ftp/gopher/smtp/tftp etc. The resolution process just
> returns
> > the uri appropreate for the protocol of the client application that
> > points to the public key.
> > </NAT>
> >
> > <DRUMMOND>
> > Agreed, but isn't there one more step in this process, namely
> > specification of the format of the returned data? That's what XDI is
> all
> > about -- standardizing both the request format (XRI syntax), the
> bootstrap
> > dictionary (the XDI service dictionary) and the response format (XDI
> > documents).
> >
> > The "slippery slope" that the XRI TC would be going down once it
moved
> 
> > into the data dictionary space would be specifying both the service
> > type
> for
> > requesting the data identified by the dictionary XRI and the data
> > interchange format in which it would be returned.
> >
> > It seems like that might be closer to the province of the XDI TC,
but
> > then, I might be biased ;-) </DRUMMOND>
> >