ietf
[Top] [All Lists]

RE: Secdir review of draft-ietf-jose-json-web-signature-31

2014-09-23 18:56:56
Thanks for the additional information, Tero.  That's useful.

Speaking as an individual, rather than as an editor, I'd still suggest that 
someone with expertise in this area write up a quick individual submission 
draft defining this additional thumbprint format and if people appear to be 
using it, ask for it to become a JOSE working group item.  The registry makes 
adding new parameters like this easy.

Feel free to copy as much text from my individual submission draft as makes 
sense for yours.

                                Best wishes,
                                -- Mike

-----Original Message-----
From: Tero Kivinen [mailto:kivinen(_at_)iki(_dot_)fi] 
Sent: Tuesday, September 23, 2014 2:18 AM
To: Mike Jones
Cc: iesg(_at_)ietf(_dot_)org; secdir(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)org; 
draft-ietf-jose-json-web-signature(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org; 
jose(_at_)ietf(_dot_)org
Subject: RE: Secdir review of draft-ietf-jose-json-web-signature-31

Mike Jones writes:
For your point "4) Thumbprint formats" if you or someone else wants 
to define an additional thumbprint format for use in IoT contexts 
(or any other contexts), I encourage you to write an Internet Draft 
that does so, registering the new header parameter defined in the 
JSON Web Signature and Encryption Header Parameters registry.

That can of course be done, but I would have hoped the initial 
version of the specification would also be usable in the IoT 
context, where the use of raw public keys will most likely arise.

If what you want is a thumbprint over a raw key, see the individual 
submission draft 
https://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-01,
which defines a method for doing this.  The -01 version incorporates 
working group feedback from Toronto.  In Toronto, I'd asked whether 
the working group wanted to adopt it as a working group draft and a 
decision hasn't been made on that yet.  If this would be useful for 
IoT applications, that would be good to know.

That looks ok for the jwk use, but for the hash over the SPKI parts of the 
X.509 is better because that is already used in other places. I.e.
if you want to create fingerprint that can be used to match the key used in 
other protocols, they are not using that format defined in your draft, thus you 
need to regenerate the JWK format from their internal public/private key 
formats and generate new hash.

For example DANE x 1 x format (i.e. 3 1 1 for SHA-256, or 3 1 2 for
SHA-512) defined RFC6698 section 2.1.3 are calculated over the exact same 
binary object which is transmitted in the raw keys used in the TLS (RFC7250 
section 3), which is again same binary object used in the in the IKEv2 
(draft-kivinen-ipsecme-oob-pubkey).

In the IoT context it will most likely be quite common to define the 
configuration of who can connect to you by using list of hashes of raw public 
keys. I.e. the device has list of hashes, and when connection comes (either 
over TLS or IKEv2 or whatever), then that raw public key sent inside the 
connection protocol is hashed and it is matched against that list of hashes. If 
match is found, the connection is allowed, if not the connection is dropped. 
Now json might be one way of this configuration could be transmitted to the IoT 
device, thus ability to be able to represent hashes in the format that makes it 
possible to match the binary blobs used on the wire, would be useful.

One of the reasons the SPKI is used, that it can also be extracted from the 
self-signed certificate, i.e. early implementations might use self-signed 
certificates in the TLS (for example) before the RFC7250 implementations come 
out.

The draft-jones-jose-jwk-thumbprint format is in such format that it is quite 
hard to match that against the binary blob we get from the wire, as to do so 
would require to format the public key received to JWK and then calculating the 
fingerprint of that newly created object.
Parsing SPKI format (and parsing JSON also if we use that for
configurations) is required in the implementations anyways, but in normal case 
the IoT devices do not need code for generating JSON objects.

So I do not think the format you are specifying there is suitable for IoT uses, 
but I assume it will still be useful in the JWK in general.
--
kivinen(_at_)iki(_dot_)fi