Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-31

"Jim Schaad" <> Tue, 26 August 2014 04:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 547291A071D for <>; Mon, 25 Aug 2014 21:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aI5r4l61qrjj for <>; Mon, 25 Aug 2014 21:15:11 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C30591A0717 for <>; Mon, 25 Aug 2014 21:15:10 -0700 (PDT)
Received: from Philemon (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 94B0438F04; Mon, 25 Aug 2014 21:15:08 -0700 (PDT)
From: Jim Schaad <>
To: 'Mike Jones' <>, 'Russ Housley' <>
References: <> <>
In-Reply-To: <>
Date: Mon, 25 Aug 2014 21:12:37 -0700
Message-ID: <035801cfc0e4$002fe8d0$008fba70$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0359_01CFC0A9.53D49340"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQK5aY5f/hfsX4HiE2ddG+a8wQQE6wIbBecjmf4cKOA=
Subject: Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-31
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Aug 2014 04:15:19 -0000



From: jose [] On Behalf Of Mike Jones
Sent: Monday, August 25, 2014 6:22 PM
To: Russ Housley
Subject: Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-31


Thanks for the useful review, Russ.  Proposed resolutions to your comments
follow inline.  Please let me know if you agree.  Also, working group
members, please follow this discussion, as these comments will likely result
in changes to the current drafts.


-----Original Message-----
From: ietf [] On Behalf Of Russ Housley
Sent: Sunday, August 24, 2014 12:23 PM
Subject: Gen-ART review of draft-ietf-jose-json-web-signature-31


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at <


Please resolve these comments along with any other Last Call comments you
may receive.


Document: draft-ietf-jose-json-web-signature-31

Reviewer: Russ Housley

Review Date: 2014-08-24

IETF LC End Date: 2014-09-03

IESG Telechat date: unknown


Summary:  Not quite ready.  Some issues to resolve.


Major Concerns:  


- At first reading, I thought that Sections 2 and 3 were defining the

  same terms.  On the second or third reading, I figured it out.

  I think it would be more clear in Section 3 to state that a JWS is

  constructed from a sequence of the things that are already defined

  in Section 2.


I understand that there is some repetition between the Terminology section
and the JWS Overview section.  I will plan to eliminate this duplication in
the manner you suggested - by simply using, rather restating the definitions
of, the terms, and saying that they are defined above.  (Jim Schaad - note
that this will condense some of the text that you'd requested be added to
Section 3 to explicitly spell out the parts of a JWS, and will result in a
parallel change to JWE.  Is that OK with you?)


Given that I would expect the text to be in section 2, this is not an issue
for me.


- In Section 5.2, it says that in some cases, all must successfully

  validate, but in other cases, only a specific signature, MAC, or

  plaintext value needs to be successfully validated. How does the

  recipient know which case applies?


The recipient knows what application it is part of, and so knows the
application decisions described in 5.2, paragraph 2 about whether all or
some signatures must validate.


I do agree that the text in step 9 (signature validation) could be read as
being in conflict with paragraph 2.   I'll plan to modify this to say that
the step records whether the signature validated, rather than saying that it
must validate.  Then I'll add a step 11 saying to reject the input if no
signature validated and a step 12 saying to return a result indicating which
signatures were successfully validated, so that the application can
determine whether to accept the input and which signatures to trust.  Will
that work for you?


It's more complicated a description, but a more general description of the
things that can happen in the multiple signatures case, in which some
signatures validate and some don't and you may need to tell the application
which ones were good and which were bad.  (It's much simpler in the single
signature case, in which you can make a simple accept/reject decision.)


- In Section 8, why not say that TLS 1.2 or later MUST be supported?


This text is modelled after,
but updated to remove the reference to TLS 1.0.  I don't believe the working
group felt that it had sufficient data on TLS 1.2 deployment to understand
whether it could now safely mandate 1.2 or whether this would effectively
mean that many deployments would be non-conformant.  Is there data saying
that greater than N% of devices in common use now support TLS 1.2 - where N%
is preferably over 90%?  It would be good have such data about commonly used
platforms such OS X, iOS, Android, Linux, and Windows to help inform this


- Section 10 says, "The entire list of security considerations is

  beyond the scope of this document..."  This reads like a red flag to

  me.  While it is not possible to discuss every possible implementation

  consideration that impacts security, the document should cover the

  topics discussed in RFC 3552.  At a minimum, I think the following

  need to be discussed:

    -- the consequences of compromise of the signer's private key

    -- the consequences of compromise of the MAC key

    -- the consequences of poor random numbers, which are needed for

       more than just key entropy with some algorithms like ECDSA

    -- awareness that cryptographic algorithms become weaker with time


I agree that the phrase "The entire list of security considerations is
beyond the scope of this document..." adds no or negative value.  I'll
remove it.


I'll also plan to explicitly make sure that we address the topics in your
list above and go through RFC 3552 looking for others that we need to cover.


Minor Concerns:


- Section 1, 1st paragraph says: "The JWS cryptographic mechanisms

  provide integrity protection for an arbitrary sequence of octets."

  This is true, but this is not the whole story.  A sentence or two

  should be added about when a signature mechanism is appropriate

  and when a MAC mechanism is appropriate.  Alternatively, a pointer

  to Section 10.4 could be included.


I will plan to add the pointer to Section 10.4.


- In Section 4.1.4, should the value match the subject key identifier

  if an X.509 certificate is used?


That was not an intended usage of this field, although nothing precludes
particular applications from specifying its use in that manner.  Its
intended usage is to match JWK "kid" values, as described.  I don't plan to
make a change to the document in response to this comment unless you believe
that one is truly necessary.


- In Section 4.1.5, why is TLS required to fetch digitally signed

  X.509 certificates?


This question was explicitly discussed by the working group at IETF 87.  The
discussion is recorded in the minutes
<>  as follows:

If there is an x5u pointing to a certification issued by a major CA, is TLS
required for the HTTP query used to retrieve this certificate?  TLS
shouldn't be needed since the certificate is a signed object.  Therefore,
the "MUST" use TLS for cert retrieval should be changed to "SHOULD".  This
is an application decision.  Mike Jones doesn't want removal of TLS in the
case where there's no external means to verify the retrieved key.  Matt
Miller: agrees with the jku case, but argues that for x5u, there is a class
of applications where it isn't known if the retrieved object is
self-protecting (like a certificate) until after it is retrieved.  Even if
the object appears to be self-protecting, if the retriever doesn't have a
trusted root for that object, it might not be able to verify the protection
anyhow.  So it use of TLS might still be preferable instead of having to
potentially retrieve an object twice, once over HTTP and then over HTTPS.
Joe Hildebrand wanted to know what the upside of this proposal is.  Richard
says it saves on TLS handshakes; Hildebrand envisions a world where TLS is
ubiquitous.  Paul Hoffman said that a similar issue in DANE ended up being
dropped after a couple of months of discussion.  Richard agreed to drop the
TLS MUST to SHOULD proposal.


- Section 10.2 talks about chosen plaintext attacks.  However, there

  are much worse things than chosen plaintext attacks that will result

  if a third party can get a signer to sign a content of its choosing.


What's there now is about attackers getting to choose part of the plaintext.
I think you're talking about attacks in which the attacker gets to choose
the whole plaintext, which is clearly far worse.  At that point, the
signature of the signer obviously becomes pretty worthless.  Is that your
point here?  If so, I could take a stab at writing something about this, or
you could suggest some text if you'd like.


Other Comments:


- I suggest a rewording for a part of Section 2:




   JOSE Header

      JSON object containing the parameters describing the cryptographic

      operations and parameters employed.  The members of the JOSE

      Header are Header Parameters.




   JOSE Header

      JSON object containing the parameters describing the cryptographic

      operations and parameters employed.  The JOSE Header is composed

      of a set of Header Parameters.




- I think that Section 3.1 would be more clear by saying:


   In the JWS Compact Serialization, a JWS object is represented as:


      BASE64URL(UTF8(JWS Protected Header)) || "." ||

      BASE64URL(JWS Payload)  || "." ||

      BASE64URL(JWS Signature)




- I think that Section 3.1 would be more clear by saying:


   In the JWS JSON Serialization, a JWS object is represented as:


      BASE64URL(UTF8(JWS Protected Header)) || "." ||

      JWS Unprotected Header || "." ||

      BASE64URL(JWS Payload) || "." ||

      BASE64URL(JWS Signature)


This isn't accurate.  Assuming you're talking about 3.2, the representation
isn't the concatenation above - it's a JSON object containing some or all of
the values above.  Nonetheless, I can try to revise the text to be more
direct here as well.


   Then, the text needs to say that whitespace may appear anywhere.




- Some additional whitespace would make Section 7.2 easier to read.




- The IANA Considerations section requires the establishment of a new

  mail list:  <>
The process for setting up the

  list is described at the bottom of this web page:



This text was taken from RFC 6749 and the list is modelled after the list described therein.  It's not clear to me
whether you want a change to the draft (if so please specify) or whether you
were just being helpful (which is appreciated).



                                                                -- Mike