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?


The nesting is getting deep, but my responses to <MARTY> are marked
<DRUMMOND> below. (I also marked <NAT> for his messages.)

=Drummond 

-----Original Message-----
From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp]
Sent: Thursday, February 02, 2006 4:49 PM
To: Schleiff, Marty; xri@lists.oasis-open.org
Cc: Drummond Reed
Subject: RE: [xri] Question: Is there a standard way to compose an
identifier for the public key of an object?

<NAT>
OK. As Drummond pointed out, we were talking about two distinct things.
The example: ($t*pk*<BASE64-encoded-public-key>)
makes perfect sense to me, though I have a tendency to think that XRI is
just an identifier and is not data in most cases.  
(The above example, the identifiier itself is a data. 
XRI related data representation is what XDI talks about, I think.)
</NAT>

<DRUMMOND>
I agree with your general sentiment, but when it comes right down to it,
all identifiers are a form of data insofar as they are values of
attributes of their parent contexts. XDI itself illustrates this in that
every XRI used to identify a Resource or a Link is the value of an XRI
element.
</DRUMMOND>

<MARTY>
<BASE64-encoded-public-key> is just an identifier; it identifiers
the holder of the corresponding private key. It happens to have some
other interesting characteristics that an application can recognize
because of the metadata $t*pk. Public key is quite interesting as an
identifier, because it is cryptographically bound to the appropriate
individual - we don't have to do any identifier mapping!
</MARTY>

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

<MARTY>
I recognize that service points could be LDAP or any other
protocol; however, I'm a proponent of LDAP, so I tend to use it in my
examples. I haven't followed the resolution discussions very closely, so
maybe there are capabilities I don't know about -- but the expectation
that "The resolution process just returns the uri appropriate for the
protocol of the client application..." seems too difficult for me. How
would the resolution process know which protocol(s) the client can use?
If the client somehow asks for an LDAP service point, what should
resolution do if the XRD only has http service point? I think the
processing of the XRD should be left to the client.
</MARTY>

<DRUMMOND>
Marty has a good point, and one that may fit with Nat's original point. The
XRI TC could indeed define an LDAP local resolution service. The CD 01
Resolution spec mentioned exactly that possibility.
</DRUMMOND>

### END INLINE RESPONSES ###

> -----Original Message-----
> From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] 
> Sent: Wednesday, February 01, 2006 2:36 PM
> To: 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?
> 
> Ahhh - we misunderstood each other. Each metadata cross 
> reference has 3 parts, and your example has only two. (even 
> $d and $v have 3 parts, but the second part has a default if 
> it's left off). The metadata for public key would look 
> something like ($t*pk*<BASE64-encoded-public-key>). The 3 
> part is the actual public key, which is whiy it could be long.
> 
> I'm a directory person, so I don't think =sakimura/($t*pk) 
> should return anything; it's not a command, it's just an 
> identifier. Or, maybe XRI resolution could return a service 
> point for the directory service that holds this entry. I 
> think you would use LDAP, or some other protocol/query 
> language to lookup the public key, e.g., 
> 
> 	ldapsearch -h <directory-server> -p <port> -b 
> <search-base> -s <scope> "xri=\=sakimura"
> 
> 		or
> 
> 	
> ldap://<directory-server>:<port>/<search-base>??<scope>?"xri=\
> =sakimura"
> 
> 	(with appropriately escaped quotes, equals, and backSlashes)
> 
> Note the these examples are out of my head, so they're not 
> completely accurate. The LDAP URL is defined in RFC 2255.
> 
> Marty.Schleiff@boeing.com; CISSP
> Associate Technical Fellow - Cyber Identity Specialist 
> Computing Security Infrastructure
> (206) 679-5933
> 
> -----Original Message-----
> From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp]
> Sent: Tuesday, January 31, 2006 5:26 PM
> To: Schleiff, Marty; 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?
> 
> Hi Marty, 
> 
> Thanks for the response. 
> 
> > Also, we could define a new $t type specifically for public keys.
> > However, this could generate pretty long XRIs. 
> 
> I am not sure if it should be in the metadata spec or 
> community spec (in which case, GRS spec should have something 
> like that), but defining new $t type is definitely one way of 
> doing it. 
> 
> However, I did not get why this could generate long XRIs. 
> 
> Requesting 
> 
> =sakimura/($t*pk)
> 
> should return a pointer to the public key of  =sakimura, and 
> XRI itself does not look very long. 
> 
> Nat 
> 
> > -----Original Message-----
> > From: Schleiff, Marty [mailto:marty.schleiff@boeing.com]
> > Sent: Wednesday, February 01, 2006 1:14 AM
> > To: 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?
> > 
> > Hi Nat,
> > 
> > In the Metadata Types spec we're defining something similar to what 
> > you describe. It's a metadata tag for HIT (a Host Identity 
> tag in the 
> > Host Identity Payload protocol - see 
> > http://www.irtf.org/charter?gtype=rg&group=hip).
> > 
> > For example: ($t*hit*<hit-value>)
> > 
> > <hit-value> is a hash of a public key.
> > 
> > Also, we could define a new $t type specifically for public keys.
> > However, this could generate pretty long XRIs. 
> > 
> > 
> > Marty.Schleiff@boeing.com; CISSP
> > Associate Technical Fellow - Cyber Identity Specialist Computing 
> > Security Infrastructure
> > (206) 679-5933
> > 
> > -----Original Message-----
> > From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp]
> > Sent: Tuesday, January 31, 2006 2:26 AM
> > To: xri@lists.oasis-open.org
> > Subject: [xri] Question: Is there a standard way to compose an 
> > identifier for the public key of an object?
> > 
> > Hi all,
> > 
> > I have a question. 
> > 
> > Is there a standard way to compose an identifier for the 
> public key of
> 
> > an object?
> > 
> > For example, it would be very nice if I can be assured that 
> I will get
> 
> > a public key for =bob by just doing
> > =bob*(+public_key) or something. Then, without any prior knowledge 
> > about =bob, I can fetch his public key for bunch of processing.
> > 
> > Cheers,
> > 
> > Nat





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