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

[Kathleen Moriarty <[e-mail]>]

On Thu, Sep 25, 2014 at 12:28 PM, Mike Jones <[e-mail]>
wrote:

>  My sincere apologies.  Upon review, it appears that I missed a whole
> block of resolutions agreed to in this thread.  Those that I believe I
> missed were:
>
> ·        changing “data associated with a key” to “data cryptographically
> secured by a key”?  (And of course, deleting the extraneous “than”.)
>
> ·        add that this implies a that there is secure way to deliver the
> needed decryption key for the JWE
>
> ·        In addition to the common parameters, each JWK will have members
> that are key type-specific.
>
> ·        Rather than saying “SHOULD be used”, we could change it to just
> say “is used”.
>
> ·        The "alg" member is used to specify the algorithm with which the
> key is to be used.
>
> ·        The "use" parameter is employed to indicate whether a public key
> is for encrypting data or verifying the signature on data.
>
> ·        This specification will be used both in open environments … and
> closed environments …
>
> ·        change “can be” to “is”
>
> ·        Clarification about improving interoperability
>
> ·        Similarly, if the “alg” member is present, it SHOULD correspond
> to the algorithm specified in the certificate.
>
> ·        we could add language saying that certificate thumbprints are
> also known as certificate fingerprints
>
> ·        We could be more explicit and talk about performing
> authenticated encryption
>
>
>
> Also, there was an issue about the RFC 1421 reference that we did not
> reach a resolution on.  In looking at 1421, it’s no longer clear to me that
> this is the best reference for the “x5u” certificate format definition.
> I’ll have to investigate that further.
>
>
>
> Finally, on the basis of Stephen’s comment on two weeks being potentially
> two short for the registration review period and people taking multi-week
> vacations, I propose that we change it to three weeks.
>
>
>
> Kathleen, do you want me to publish updated drafts today addressing these
> missed resolutions?  My thinking is that it would probably be better to go
> into the telechat with these issues having been addressed.
>
>
>
If you can get this done today, then yes.  Barry has started his reviews
and is making quick progress.

*reduced the distribution list

Thanks,
Kathleen

>                                                              -- Mike
>
>
>
> *From:* Kathleen Moriarty [mailto:[e-mail]]
> *Sent:* Thursday, September 25, 2014 7:25 AM
> *To:* Mike Jones
> *Cc:* Stephen Kent; [e-mail]; [e-mail];
> Moriarty, Kathleen; [e-mail]
> *Subject:* Re: [jose] SECDIR review of draft-ietf-jose-json-web-key-31
>
>
>
> Hi Mike,
>
>
>
> It appears that the explanation for thumprints/fingerprints was not
> included in the current version and was agreed to.  This came up several
> times in reviews and I think it would be helpful for the reader.  Let me
> know if I missed something or if this was an oversight and it will be
> addressed in the next revision.
>
>
>
> Also, there is some suggested text from Steve on "alg" members.  Where
> does that stand?  I think I am missing the resolution.
>
>
>
> These issues are in the email thread right next to each other.
>
>
>
> Thanks!
>
>
>
> On Tue, Sep 23, 2014 at 7:40 PM, Mike Jones <[e-mail]>
> wrote:
>
> Thanks again for your review, Stephen.  The resolutions discussed below
> have been incorporated in draft -32.
>
>
>
> See the thread “JWK member names, was: [jose] SECDIR review of
> draft-ietf-jose-json-web-key-31” for the status of that particular issue.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Stephen Kent [mailto:[e-mail]]
> *Sent:* Thursday, September 11, 2014 8:13 AM
> *To:* Mike Jones; [e-mail]; [e-mail]; Moriarty,
> Kathleen
> *Cc:* [e-mail]
> *Subject:* Re: SECDIR review of draft-ietf-jose-json-web-key-31
>
>
>
> Mike,
>
> Thanks for the reply to my comments.
>
> I've retained your replies and responded to them, below.
>
>
> 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.
> 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
>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>



-- 

Best regards,
Kathleen