Re: [jose] Ted Lemon's No Objection on draft-ietf-jose-json-web-encryption-33: (with COMMENT)

Mike Jones <> Mon, 06 October 2014 07:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D30EB1A1B5D; Mon, 6 Oct 2014 00:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_57=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c0uLoGx-7giO; Mon, 6 Oct 2014 00:54:47 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::1:704]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB77C1A1B68; Mon, 6 Oct 2014 00:54:46 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 07:54:23 +0000
Received: from (2a01:111:f400:7c0c::114) by (2a01:111:e400:2428::38) with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Mon, 6 Oct 2014 07:54:23 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 6 Oct 2014 07:54:22 +0000
Received: from ([]) by ([]) with mapi id 14.03.0210.003; Mon, 6 Oct 2014 07:54:15 +0000
From: Mike Jones <>
To: Ted Lemon <>, The IESG <>
Thread-Topic: Ted Lemon's No Objection on draft-ietf-jose-json-web-encryption-33: (with COMMENT)
Thread-Index: AQHP3jIKZGmimdVlak+7Y1LRGycrOJwiS6vA
Date: Mon, 06 Oct 2014 07:54:14 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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)(6009001)(438002)(52044002)(51704005)(13464003)(189002)(377454003)(199003)(55846006)(68736004)(69596002)(230783001)(104016003)(86362001)(23676002)(80022003)(19580395003)(21056001)(33656002)(44976005)(4396001)(92726001)(19580405001)(92566001)(15975445006)(26826002)(95666004)(6806004)(97736003)(50466002)(106466001)(81156004)(66066001)(120916001)(85806002)(47776003)(46102003)(10300001)(20776003)(76482002)(31966008)(99396003)(106116001)(87936001)(107046002)(85852003)(86612001)(54356999)(76176999)(64706001)(15202345003)(85306004)(77096002)(50986999)(84676001)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1206;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1206;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 03569407CC
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: "" <>, "" <>, "" <>
Subject: Re: [jose] Ted Lemon's No Objection on draft-ietf-jose-json-web-encryption-33: (with COMMENT)
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: Mon, 06 Oct 2014 07:54:49 -0000

Thanks for your review, Ted.  I'm adding the working group to the thread so they're aware of your comment.

> -----Original Message-----
> From: Ted Lemon []
> Sent: Thursday, October 02, 2014 4:14 AM
> To: The IESG
> Cc:; draft-ietf-jose-json-web-
> Subject: Ted Lemon's No Objection on draft-ietf-jose-json-web-encryption-33:
> (with COMMENT)
> Ted Lemon has entered the following ballot position for
> draft-ietf-jose-json-web-encryption-33: No Objection
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> This question is almost certainly due to my thick-headedness with respect to
> authentication algorithms, but:
>    16.  Let the Additional Authenticated Data encryption parameter be
>         ASCII(Encoded Protected Header).  However if a JWE AAD value is
>         present (which can only be the case when using the JWE JSON
>         Serialization), instead let the Additional Authenticated Data
>         encryption parameter be ASCII(Encoded Protected Header || '.' ||
>         BASE64URL(JWE AAD)).
>    17.  Decrypt the JWE Ciphertext using the CEK, the JWE Initialization
>         Vector, the Additional Authenticated Data value, and the JWE
>         Authentication Tag (which is the Authentication Tag input to the
>         calculation) using the specified content encryption algorithm,
>         returning the decrypted plaintext and validating the JWE
>         Authentication Tag in the manner specified for the algorithm,
>         rejecting the input without emitting any decrypted output if the
>         JWE Authentication Tag is incorrect.
> How does it make sense for the AAD encryption parameter to consist of
> ASCII and BASE64 text?  How would a decryption algorithm use this?   I
> know nothing about AAD parameters in encryption algorithms, so I realize this is
> probably a very naive question.

When doing authenticated encryption, an Additional Authenticated Data parameter can be included that will be integrity-protected as part of the authenticated encryption operation.  This means that if it is tampered with, the decryption will fail.

JWE uses this authenticated encryption feature to integrity-protect some header fields.  It also makes this feature available to applications using the JWE JSON Serialization.

Answering your specific question, all of these three values are strings consisting of ASCII characters, so their concatenation is also a string consisting of ASCII characters:
    ASCII(Encoded Protected Header)

The "ASCII(...)" around the string denotes that the string is to be represented in a sequence of ASCII octets (rather than, for instance, a series of UTF-32 octets, which would be four times as long).

					Best wishes,
					-- Mike