On 22 June 2010 21:45, David Recordon <record...@gmail.com> wrote: > 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.
I don't understand why they are unnecessary no matter how keys are managed: if there's ever a possibility that you might have more than one key for someone, then key IDs are a useful optimisation. Put it another way: what's the purpose of leaving out the key ID? > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
