The only additional value might be during "key rotation". If key_id is
removed, then both (or n) have to be checked. Probably not a huge issue.
Thanks,
George
On 6/22/10 4:45 PM, David Recordon 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.
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
