[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?
Guys - again, great discussion.
But it seems that this discussion is out of scope for this TC, at least
right now. Its certainly way beyond the deliverables we have proposed
and I assume nobody is arguing that if we don't describe this
functinoality that resolution won't work.
Can we focus our energy on getting resolution done before we start
adding more features? If the TC wants to move on towards defining
applications of resolution (such as retrieving keys), then lets take
that up when we have air, and if TC participants want to extend the
charter in this manner. It seems to me that getting into applications
like this should involve a lot more analysis before diving right into
solutions.
I don't mean to quash discussion on this topic - perhaps a subset of you
who are particuarily interested in this could take it offline for a
while and bring it back to the TC when there is time. Better yet, if
folks want to try out different approaches to this key discovery and
report back how it works (later), that would be even more useful!
Thanks.
-(Taskmaster) Gabe
> -----Original Message-----
> From: Tan, William [mailto:William.Tan@neustar.biz]
> Sent: Tuesday, February 07, 2006 7:07 AM
> To: Schleiff, Marty; 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?
>
> 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>
> > >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]