Mike,
Thanks for making the effort to produce a draft:
http://tools.ietf.org/html/draft-jones-jose-json-private-key
Four comments:
1.
Your choice to extend the public key format to also hold the private key info
might have some interesting consequences. It suggests you can have a single
file (or single JSON object) that can be used by tools that needs a public key,
and by tools that need a private key. However, I doubt that is very good
practice. It just adds a risk that a private key is inadvertently exposed where
it shouldn't be.
Perhaps the following sort of format would be better:
{
"public":{"alg":"...},
"private":{"d":...}
}
2.
The rule that integers MUST not be shortened if they have leading 0's is silly.
It implies you cannot encode an integer without knowing a larger context (eg
you cannot encode d without specifying n, in the context of an RSA key). This
rule applies to the private exponent, but the opposite rule applies to the
public exponent. Yuck.
Either always forbidding leading zeros, or always allowing them (so receivers
MUST support them), would be much better rules.
I just noticed the "MUST not omit leading 0's" rule applies to the RSA modulus
in JWA (section 5.3.1 "mod" Modulus Parameter). The rule is even sillier in
this case. It effectively says "the modulus MUST be encoded as the size
someone/something though the modulus should be, instead of as the size it
actually is". This seems to have no purpose other than to mislead (eg trick a
component that only looks at the encoded length into thinking the key is
longer/stronger than it actually is).
3.
An RSA private key format needs to support calculations that use the Chinese
Remainder Theorum (CRT), by allowing p, q, d mod p-1, d mod q-1, and qinv to be
specified -- not just d. CRT calculations offer too much of a performance boost
to ignore (2 or 4 times faster, can't remember which off the top of my head).
An RSA modulus can actually have more than 2 prime factors. An RSA private key
format should theoretically support that as well. That is, support an array of
{prime, exponent, coefficient}, instead of hardwiring fields for 2 primes.
See RFC3447 "PKCS #1: RSA Cryptography Specifications, version 2.1".
4.
I am not sure if it has been asked before (by me or someone else), but is there
really any benefit from wrapping the JSON array of key objects in another JSON
object with a single member "keys" [JWK section 5 "JSON Web Key Set (JWK Set)
Format"]? This is adding an extension point with no currently-known use, but
without any backward compatibility since any extension MUST be understood.
--
James Manger
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
