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



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