Hey Dick, in answering my questions you made my point. If keys are managed out of band – as is done in OAuth 1.0 and what was done in the OAuth 2.0 Core spec until signatures were extracted – then having a key id is not needed. I certainly understand what they're used for, but don't find them relevant as part of the OAuth conversation today.
And yes, Applied Cryptography is worth reading. :) --David On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > David > key_ids are used when you need to identify which key to use of all the keys > you might have. If you are doing discovery of document that is bound to the > identifier of the signer, this is useful. Since OAuth 1.0 did not have > discovery and required an out of band key management process, key_ids have > little value. > To answer your question, key_ids dont' make sense if the keys are being > managed how you describe them. I would suggest that key_ids are not included > if public keys are managed independent from how Dirk had described them be > discovered. > I don't think key_ids make sense for shared secrets as they inherently have > an out of band process for sharing them. > If you would like to learn more about cryptography, I have found Bruce > Schneier's book Applied Cryptography to be pretty educational. Here is a > link to the Kindle version: > http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-ebook/dp/B000SEHPK6/ref=kinw_dp_ke?ie=UTF8&m=AG56TWVU5XWC2&qid=1277236054&sr=8-1 > -- Dick > > On Tue, Jun 22, 2010 at 12:20 PM, David Recordon <record...@gmail.com> > wrote: >> >> All of the OAuth 1.0 implementations which I'm aware of either have >> the server provide a shared secret to the client or the client upload >> their public key to the server. >> >> In the case of the server providing a shared secret to the client, >> what would the value of key_id be? >> >> In the case of a client uploading their public key to the server, what >> would the value of key_id be? >> >> Thanks, >> --David >> >> >> On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt <dick.ha...@gmail.com> wrote: >> > I could imagine an architecture striving to be efficient, scalable, >> > distributed and secure where there are hundreds of servers each with a >> > unique private key baked into each server. All the public keys would be >> > in >> > one file. >> > Having a key id would help debugging as well as the signer is clearly >> > indicating which key should be used. If the signing fails, it could be >> > the >> > key, could be signature calculation, could be ... >> > >> > The downside of having a key_id seems heavily outweighed by the >> > advantages >> > to me. >> > On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin >> > <tony...@microsoft.com> >> > wrote: >> >> >> >> > If a server needs to verify, it can literally iterate over all of the >> >> > keys associated with the client until it finds the right one. >> >> >> >> Depends on how the server stored the keys, this can be a very expensive >> >> operation w/o a key_id to match/index on >> >> >> >> -----Original Message----- >> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> >> Of >> >> Brian Eaton >> >> Sent: Tuesday, June 22, 2010 9:43 AM >> >> To: Dick Hardt; hannes.tschofe...@gmx.net >> >> Cc: OAuth WG >> >> Subject: Re: [OAUTH-WG] proposal for signatures >> >> >> >> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt <dick.ha...@gmail.com> >> >> wrote: >> >> >> Thanks for writing this. A few questions... >> >> >> >> >> >> Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` >> >> >> instead at least for OAuth? >> >> > >> >> > it is the ID of the key, not the client -- used to rollover keys >> >> >> >> I don't think key id is necessary, but adding Hannes since he called me >> >> crazy for saying that at IIW. =) >> >> >> >> The average client is going to have very few keys. Probably just 1. >> >> 3 at the outside. >> >> >> >> If a server needs to verify, it can literally iterate over all of the >> >> keys >> >> associated with the client until it finds the right one. >> >> >> >> There is some precedent for this approach: >> >> http://support.microsoft.com/kb/906305/en-us. >> >> >> >> Cheers, >> >> Brian >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
