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

Mike Jones <> Fri, 19 September 2014 18:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 474AF1A7035; Fri, 19 Sep 2014 11:50:55 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qMq1dCSeennv; Fri, 19 Sep 2014 11:50:51 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::715]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 232421A7033; Fri, 19 Sep 2014 11:50:51 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1019.16; Fri, 19 Sep 2014 18:50:28 +0000
Received: from (2a01:111:f400:7c10::134) by (2a01:111:e400:2c5d::40) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Fri, 19 Sep 2014 18:50:27 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Fri, 19 Sep 2014 18:50:26 +0000
Received: from ([]) by ([]) with mapi id 14.03.0195.002; Fri, 19 Sep 2014 18:49:43 +0000
From: Mike Jones <>
To: Richard Barnes <>, Tero Kivinen <>
Thread-Topic: Secdir review of draft-ietf-jose-json-web-signature-31
Thread-Index: AQHPyDgrWdMUgOdf8EqNa4N9Ytbe4ZvzQwoggArT4gCABW9RgIABPl2AgABFmwCAAFrAgIADfttQ
Date: Fri, 19 Sep 2014 18:49:42 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BA59EB7TK5EX14MBXC286r_"
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)(51704005)(41574002)(52544003)(24454002)(189002)(377454003)(199003)(80022003)(19580395003)(81542003)(2656002)(71186001)(76482002)(87936001)(106466001)(85852003)(55846006)(90102001)(31966008)(68736004)(84326002)(92566001)(97736003)(64706001)(26826002)(77982003)(84676001)(19300405004)(54356999)(19580405001)(93886004)(83072002)(107046002)(15202345003)(21056001)(76176999)(512874002)(66066001)(104016003)(46102003)(86362001)(95666004)(81342003)(16236675004)(20776003)(85306004)(77096002)(106116001)(19625215002)(4396001)(92726001)(69596002)(99396002)(230783001)(33656002)(79102003)(85806002)(15975445006)(83322001)(74502003)(44976005)(50986999)(81156004)(74662003)(6806004)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1215;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0339F89554
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: "" <>, "" <>, "" <>, "" <>, "" <>
Subject: Re: [jose] Secdir 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: Fri, 19 Sep 2014 18:50:55 -0000

I would appreciate it if you would write a draft of the proposed security considerations text, Richard.  Perhaps title the section “Unsecured Algorithm Values”.

                                                            -- Mike

From: Richard Barnes []
Sent: Wednesday, September 17, 2014 6:24 AM
To: Tero Kivinen
Cc: Mike Jones;;;;;
Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31

On Wednesday, September 17, 2014, Tero Kivinen <<>> wrote:
Richard Barnes writes:
>     Perhaps, but is there benefits for leaving the alg without protection?
> Simplicity (if you omit protected headers altogether), and
> compatibility with other signed things.  In the sense that you could
> transform one of them into a JWS without re-signing.  This would
> apply, for example, to an X.509 certificate -- just parse the outer
> SEQUENCE, and re-assemble into a JWS with the tbsCertificate as
> payload.  Same security properties that X.509 already has.

Ok, having this kind of information somewhere in the draft would help
to understand the reason. Also having text explaining that is
possible, and that the security properties of this option (i.e. no
problem with PKCS#1, etc... the text you had in the other email).

> It's also completely unnecessary for PKCS#1 signatures, which are
> the dominant use case today.

I agree.

> In general, I'm opposed to protocols baking in more
> application-specific logic than they need to.  The point of JOSE is
> to describe the cryptographic operation that was performed, and
> carry the relevant bits around.  Its job is not to fix all the
> weaknesses that every algorithm has.

Yes, but this property might have security issues, so they should be
covered by the security considerations section.

I'm perfectly happy to have it documented in the Security Considerations.

Mike: Should I generate some text, or do you want to take a stab?