I understand Stephen’s issue.
However this is intended to be a simple way to generate a keyid value based on
a JWK.
I think the document as is accomplishes that.
If we want to generate a keyid based on the SubjectPublicKeyInfo format
from x.509 people should be able to do that based on the existing specs.
We did drop the jkt member from the spec a while ago based on feedback.
Based on some of the discussion on creating a thumbprint from a SPKI there may
be a need for better documenting
how to do that. A number of the proposals discussed for doing it without full
processing only worked for some key-types.,
however that should be a separate spec.
I think this one is ready to go.
Regards
John B.
On May 28, 2015, at 2:04 PM, Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
Hi,
I have one comment on this that I did raise with the WG (the
thread starts at [1] but the subject lines diverged so it's
not so easy to follow). At the end of that I think I was
correctly judged to be in the rough within the WG. I'm
raising it again now as a last-call comment (and wearing
no hat) as the issue is really about doing the same thing
in multiple protocols/WGs, so this could be a case where
IETF consensus maybe ought win over WG consensus, depending
on whether folks working on other protocols care or not.
(And I'm not sure if they do.)
Note that if the draft as-is turns into an RFC it will not
be the end of the world, so I'd only expect that a change
would be done if there're a load of people who agree that
changing is beneficial for some actual use-case they have
or may have in future. (In other words, I really don't
expect this change to happen and I do not want it to
happen on purely theoretical grounds, but I wanted to
check just in case;-)
So my issue is:...
We have a bunch of other protocols (DANE, CoAP and more)
in which we use a hash of a public key. In most of those with
which I'm familiar we use the SubjectPublicKeyInfo format
from x.509 as the input bytes to the hash function. Doing
so ensures that a hash generated in one protocol/application
could in principle be meaningful in others, even if that's
not a very common thing to want. Note that using that structure
does not imply anything about using x.509 or asn.1 really as
pretty much all crypto APIs (or maybe all) provide you with
a way to extract public keys in exactly that form regardless
of whether you care about x.509 or anything related to
that kind of PKI. (So please let's not have the "I hate
asn.1/x.509/whatever" argument again:-)
This draft defines it's own peculiar input bytes to the
hash function and even notes that there's no really good
reason for that difference:-) [2]
I think this would be better if it supported the use of
hash input bytes that are the same as are used elsewhere.
But, as I said before, the world won't end if this becomes
an RFC and we have to do another one later on with that
fairly trivial difference.
Cheers,
S.
[1] https://www.ietf.org/mail-archive/web/jose/current/msg04954.html
[2] https://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-05#section-5
On 28/05/15 17:40, The IESG wrote:
The IESG has received a request from the Javascript Object Signing and
Encryption WG (jose) to consider the following document:
- 'JSON Web Key (JWK) Thumbprint'
<draft-ietf-jose-jwk-thumbprint-05.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2015-06-11. Exceptionally,
comments may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This specification defines a method for computing a hash value over a
JSON Web Key (JWK). It defines which fields in a JWK are used in the
hash computation, the method of creating a canonical form for those
fields, and how to convert the resulting Unicode string into a byte
sequence to be hashed. The resulting hash value can be used for
identifying or selecting the key represented by the JWK that is the
subject of the thumbprint.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-jose-jwk-thumbprint/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-jose-jwk-thumbprint/ballot/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
jose mailing list
jose(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature