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

Mike Jones <> Tue, 30 September 2014 18:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DF6591A8714; Tue, 30 Sep 2014 11:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UkpD4eYaYUH8; Tue, 30 Sep 2014 11:11:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30E651A870E; Tue, 30 Sep 2014 11:10:51 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 18:10:48 +0000
Received: from (2a01:111:f400:7c10::133) by (2a01:111:e400:2428::27) with Microsoft SMTP Server (TLS) id 15.0.1039.15 via Frontend Transport; Tue, 30 Sep 2014 18:10:48 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 30 Sep 2014 18:10:47 +0000
Received: from ([]) by ([]) with mapi id 14.03.0195.002; Tue, 30 Sep 2014 18:10:37 +0000
From: Mike Jones <>
To: Russ Housley <>, "" <>
Thread-Topic: Gen-ART review of draft-ietf-jose-json-web-signature-33
Thread-Index: AQHP2mhILPxPTyEuvU2oGKNSsFOQjZwZ+E6w
Date: Tue, 30 Sep 2014 18:10:37 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BAA578ETK5EX14MBXC288r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(377424004)(377454003)(13464003)(189002)(43784003)(199003)(106116001)(104016003)(95666004)(85306004)(561944003)(64706001)(19617315012)(107046002)(4396001)(81156004)(84676001)(84326002)(26826002)(85852003)(97736003)(120916001)(10300001)(76482002)(19625215002)(20776003)(106466001)(71186001)(66066001)(21056001)(86362001)(33656002)(77096002)(15975445006)(69596002)(19580405001)(44976005)(6806004)(68736004)(15202345003)(19580395003)(16236675004)(230783001)(86612001)(92566001)(92726001)(54356999)(50986999)(55846006)(76176999)(80022003)(31966008)(46102003)(2656002)(87936001)(99396003)(19300405004)(512954002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1203;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1203;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0350D7A55D
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: IETF Gen-ART <>, IETF <>, "" <>
Subject: Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-33
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, 30 Sep 2014 18:11:18 -0000

Thanks again for your comments, Russ.  I'm adding the working group to the thread so they're aware of them.  Responses are inline below...

-----Original Message-----
From: ietf [] On Behalf Of Russ Housley
Sent: Saturday, September 27, 2014 8:32 AM
Subject: Gen-ART review of draft-ietf-jose-json-web-signature-33

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-33

Reviewer: Russ Housley

Review Date: 2014-08-24

IETF LC End Date: 2014-09-03

IESG Telechat date: 2014-10-02

Summary:  Ready.  Some issues could be resolved to improve the document.

Thank you for addressing my comments on -31.

Major Concerns:

- None.

Minor Concerns:

- Section 10.5 should state that validation of a MAC means provides

  corroboration that the message was generated by one of the parties

  that knows the symmetric MAC key.  This could potentially be many



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

  if an X.509 certificate is used?

No, it's not expected that these values would match.  For instance, if a JWK contains both bare public key representation of a key and an X.509 representation of the same key, then the "kid" would be expected to match the "kid" in the JWK, which is likely unrelated to the subject key identifier value in the X.509 certificate.  (There's nothing preventing particular applications from using the subject key identifier as the "kid" value, but it's not a requirement, or even necessarily recommended.)

Also note that that certificate thumbprints can be used as identifiers for X.509 certifications, rather than Key ID values - something that's already supported in the spec.

- 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.

Russ is certainly right that for certs that chain back to a known root of trust, integrity protection isn't necessary.  It's also the case that this is not true of all certificates that might be used - especially self-signed certificates intended only to carry a key value.  One possibility is to say that TLS MUST be used unless the certificate chains back to a known trust root accepted by the application.  Of course, just requiring TLS is simpler. Do people in the working group want to re-open this issue or are people content with the current requirements?

                                                            -- Mike