Re: [jose] SECDIR review of draft-ietf-jose-json-web-key-31

[Stephen Kent <[e-mail]>]

Mike,

Thanks for the reply to my comments.

I've retained your replies and responded to them, below.
>
> **<mailto:[e-mail]>
> I agree that "employing countermeasures to" is more accurate than 
> "preventing".  I also agree that the "avoiding mistakes" language is 
> not actionable -- I propose to just remove it.
>
Great.
>
> Actually, it was spoken by then-Security AD Sean Turner. ;-)
>
gee, I thought Sean was wise, but I didn't realize he was a Jedi ;-).
>
> How about changing "data associated with a key" to "data 
> cryptographically secured by a key"?  (And of course, deleting the 
> extraneous "than".)
>
OK.
>
> The wording above is needlessly awkward. Nonetheless, this says that 
> key sets containing symmetric or private keys should be encrypted by 
> embedding them in another JSON crypto format (JWE). It would be nice 
> to add that this implies a that there is secure way to deliver the 
> needed decryption key for the JWE, else this recommendation just adds 
> a layer of indirection, and does not solve the problem.
>
> Fair enough.  I propose that we add something along those lines.
>
OK, I look forward to seeing the revised wording here.
>
> Section 9.3 discusses a countermeasure against a specific attack on 
> RSA key use. This seems unduly narrow, since this spec is intended for 
> use with RSA, DH, DSS, and ECDH keys. Why devote a long paragraph to 
> this one issue, while saying nothing about equally serious concerns 
> that arise for other algorithms?
>
> This particular attack is described both because the countermeasure 
> requires specific key representation actions and because a working 
> group member asked it to be included. For what it's worth, I expect 
> that additional security considerations will be added when resolving 
> Russ Housley's gen-art review of the JWS specification.
>
If comparable alg-specific countermeasures are added based on Russ's 
comments then
this may be OK, but in isolation this RSA-specific attack seem out of place.
>
> These non-goals were agreed to by the working group from the very 
> beginning, while the working group was still being chartered.  The 
> group wanted to build something simple and easily deployable to 
> represent keys in JSON -- not reinvent all the work that the PKIX 
> working group did on certificates and certificate chains, etc.  Do any 
> working group members want to suggest specific wording to try to 
> capture this sentiment?
>
OK.
>
> The example that comprises Section 3 should include an explanation of 
> the parameters, else it's not a great example.
>
> The parameters and values of them are explained in the paragraph 
> preceding the example text.  It says:
>
>     The following example JWK
>     declares that the key is an Elliptic Curve [DSS  <https://tools.ietf.org/html/draft-ietf-jose-json-web-key-31#ref-DSS>] key, it is used with
>     the P-256 Elliptic Curve, and its x and y coordinates are the
>     base64url encoded values shown.  A key identifier is also provided
>     for the key.
>
> Each statement above corresponds to a parameter in the example, and in 
> the same order.
>
OK. I missed that.
>
> I suppose that one option is to be more verbose above and add 
> parenthetical remarks after each statement above saying which 
> parameter does this.  So for instance, the parenthetical phrase 
> "("kty" parameter)" could be added before the first comma.  Do others 
> in the working group think that would make the example easier to read, 
> harder to read, or do any of you have an alternative suggestion?
>
I defer to the WG on this presentation issue.
>
> In addition to the common parameters, each JWK will have members that
>
>   are algorithm-specific.
>
> They're not algorithm-specific -- they're key type-specific.  Another 
> way of eliminating the repeated use of the word "parameters" is to 
> replace the second sentence with "These members represent the key 
> value".  Would that work for you (and the working group)?
>
Yes, I meant key-type specific. But if one were to use that term instead 
of "algorithm specific"
I still think my wording is better.
>
> This topic has been heavily discussed by the working group, and while 
> the specs used to just say that objects with duplicate member names 
> MUST be rejected, working group members, including Tim Bray (the 
> editor of the JSON spec), prevailed on us to weaken this so that 
> parsers that implement the ECMAscript behavior of returning only the 
> last member name may be legally used.  (The argument was made that 
> there was more security downside in effectively requiring people to 
> write and debug their own strict parsers than in using laxer, but 
> well-supported and debugged parsers.)
>
I find that argument unpersuasive, but I defer to the cognizant Ad on this.
>
> However, we also intentionally require that producers use only one 
> instance of each member name, so that legally produced objects will 
> never exercise the ambiguities that are present in real JSON parsers.  
> That seemed to be the most practical solution to the working group.
>
Based on year of experience in PKIX that is not a great solution. If the 
consumer of a data
structure fails to strictly enforce the requirement imposed on the 
producer of the data structure,
the result is that non-conforming producers do not receive "appropriate" 
feedback.
>
>
> The term "Collision-Resistant Name" is already present in the 
> Terminology section.  However, previous reviewers had requested that 
> definitions not be repeated in multiple specs, so it's incorporated by 
> reference, rather than repeating the definition here.  The notion is 
> that of an implementation wants to use a collision-resistant name such 
> as "http://names.example.com/the-name", it can do so without having to 
> create a public specification and register the name with IANA.
>
I found the definition by reading one of the other specs, but I didn't 
see a clear explanation of
why this is a reasonable alternative to using an IANA registry. The text 
above does still does
not provide a rationale.
>
> I agree that the "SHOULD" language is awkward.  Rather than saying 
> "SHOULD be used", we could change it to just say "is used".
OK.
>
> Would the language "The "alg" member can be used to specify the 
> cryptographic operation that the key is intended to be used for" work 
> better for you?  Or would people like to just see the parenthetical 
> remark deleted?
>
How about:

    The "alg" member is used to specify the algorithm with which the key
    is to be used.

> Section 4.5 defines the key_ops parameter. It's not clear how this 
> parameters and "use" relate. There is also an odd sentence at the end 
> of the first paragraph:
>
>    The "key_ops" parameter is intended for use cases in which public,
>
>    private, or symmetric keys may be present.
>
> This seems to encompass all of the types of keys that JWK carries, so 
> the sentence seems to add no useful qualification for when this 
> parameter is intended to be used.
>
> This is in contrast to the related statement in the "use" definition:
>
>    The "use" parameter is intended for use cases in which
>
>    it is useful to distinguish between public signing keys and public
>
>    encryption keys.
>
Too subtle for me, and the language above seems a bit wimpy. Why not say:

    The "use" parameter is employed to indicate whether a public key is
    for encrypting
    data or verifying the signature on data.

> If you want to see this parameter name changed, you'll need to file a 
> bug against the WebCrypto spec and get it changed there.  Then I'm 
> sure that JOSE will gladly follow.
>
My request is directed to the IESG, suggesting that they take this action.
>
>
> This specification will be used both in open environments, in which 
> multiple organizations will need to have a common understanding of any 
> extensions used, and closed environments, which the producing and 
> consuming organization will always be the same and private values 
> could be safely used.  IANA registration is definitely the right thing 
> to do for open environments.  It's probably unnecessary for 
> deployments in closed environments.
Then say this.
>
> Same answer as for Section 4.
>
ibid.
>
> "Can" is being used as a non-2119 synonym for "MAY" here.  That being 
> said, we could just change "can be" to "is", since it's explicitly 
> said that its use is optional at the end of the paragraph.
please revise accordingly.
>
> It's the inclusion of other metadata about the key that might improve 
> interoperability that's being referred to -- not the inclusion of the 
> cert reference.  For instance, including "use" or "alg" parameters 
> might be useful to applications that can't process the certificate.
that's not what the text said, hence my confusion.
>
> As for the cert vs. cert chain question, in the general case, a chain 
> may be required to establish trust.  However, a chain of length one (a 
> single certificate) will also be sufficient in some use cases.  We're 
> not inventing anything new here. The data format is specified in RFC 1421.
>
could you point specifically to where 1421 uses two names to identify 
equivalent data structures
for transport of certs/cert chains? I trued a quick search of the text 
and didn't locate the
text to which you appear to refer.
>
> I had thought there were uses of RSA keys where the same key is used 
> both for signing and encryption (even though this is a deprecated 
> practice).
>
Yes, that practice is frowned upon, and we prefer that certs use an OID 
that makes it clear
how a key is to be used. How about the following text:

    Similarly, if the "alg" member is present, it MUST be consistent with

the algorithm specified in the certificate.


> But we could change this to "Similarly, if the "alg" member is 
> present, it SHOULD correspond to the algorithm specified in the 
> certificate."  Or is that overly strong for some certificates and uses 
> of them?
>
I prefer this text.
>
> Also, the name seems misleading since the chain MAY contain additional 
> certs, and hence may not be a chain at all!
>
> I'm not sure if I'm following you here.  Are you suggesting the 
> possibility of having multiple certificates not chaining to one 
> another in the representation?  This isn't allowed by the 
> specification, as written.  Are you suggesting that it needs to be 
> allowed?
>

> Thumbprint is the term used in the Windows libraries, such as 
> http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate2.thumbprint(v=vs.110).aspx 
> <http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate2.thumbprint%28v=vs.110%29.aspx>. 
> Whereas OpenSSL uses fingerprint 
> http://www.openssl.org/docs/apps/x509.html. I know that there would be 
> an uproar if we tried to make a breaking change to the "x5t" name at 
> this point, because it's in widespread production use.  However, we 
> could add language saying that certificate thumbprints are also known 
> as certificate fingerprints, so people familiar with either term will 
> know what this is.
>
Yes, do add that explanatory text.
>
> The term "base64url" is incorporated by reference in the terminology 
> section (Section 2).
>
> Actually, Appendix C in JWS is not normative.  It's just example 
> code.  The normative definition of the encoding is in Section 5 of RFC 
> 4648.
>
Then 4648 should be cited.
>
> It used to be a "SHOULD" but the working group felt that the "MUST ... 
> unless" wording was a more accurate statement of the requirement.
>
I defer to the cognizant AD here, but the notion of SHOULD is really 
MUST ... unless ...
>
> Section 8 (IANA Considerations) establishes a two-week review period 
> for creating new (IANA) registry items. This seems too short; some 
> people take multi-week vacations. I note that the same text appears in 
> the JWS and JWE documents.
>
> This text was taken from RFC 6749.
>
I didn't review that RFC. My comment still stands.
>
> Aren't appendices normally informative?
>
normally, but not always.
>
> We could be more explicit and talk about performing authenticated 
> encryption.
>
please do.

Steve