Re: [jose] Barry Leiba's No Objection on draft-ietf-jose-json-web-encryption-32: (with COMMENT)

Barry Leiba <> Tue, 30 September 2014 16:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0C7A91A1A54; Tue, 30 Sep 2014 09:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tf5Tm_ZJjVy3; Tue, 30 Sep 2014 09:44:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95F5B1A1B13; Tue, 30 Sep 2014 09:44:20 -0700 (PDT)
Received: by with SMTP id w7so3621128lbi.23 for <multiple recipients>; Tue, 30 Sep 2014 09:44:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yd0cD/SEb2SnF4Pal/2DIuDMTCB8erIECfeGW62dTAk=; b=f3XofDENtpZ0DMN9haWGOjDmI670I2qHxuSLx1Wa4MazPd0jLz4pQkUeac+8Sn0nFt x9mYEmtgo5UPt0QAUost8Y+XJ2JOHwUJtoifrvLacLJwWdUYltMMZxLmwOp9LTCwuLc0 SxXrJvar+BCYWl3BCR+fydG6Pcdu9jO78PiMrBKBX/I6A9w964ZfPcnTXAdIMUn7+g2D KpLolxmyjD+O7lkBTpdiztTmShCyslYU8fR4Vjix9nNx3Qcd6jrl9oQu7Mm9a8VOR/qp XlFaR3k5jqAG0+n/40EpRd6v/3KnSRPFOTdkLq/beI89b/U3O2SgabiRk6ZqBbjMrDTH 4Ggw==
MIME-Version: 1.0
X-Received: by with SMTP id x5mr50126653lad.42.1412095458755; Tue, 30 Sep 2014 09:44:18 -0700 (PDT)
Received: by with HTTP; Tue, 30 Sep 2014 09:44:18 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 30 Sep 2014 17:44:18 +0100
X-Google-Sender-Auth: FowxSMuNSU8JFwQbPBgVLr5HjKI
Message-ID: <>
From: Barry Leiba <>
To: Mike Jones <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "" <>, "" <>, The IESG <>, "" <>
Subject: Re: [jose] Barry Leiba's No Objection on draft-ietf-jose-json-web-encryption-32: (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: Tue, 30 Sep 2014 16:44:40 -0000

>>    Finally, note that it is an application decision which algorithms are
>>    acceptable in a given context.  Even if a JWE can be successfully
>>    decrypted, unless the algorithms used in the JWE are acceptable to
>>    the application, it SHOULD reject the JWE.
>> It's a small point, but what does it mean for an algorithm to be
>> "acceptable", if not to define this very point?  That is, if I accept (don't
>> reject) a decryption with algorithm X, doesn't that *mean* that algorithm
>> X is acceptable to me?
> Would you prefer that the first "are acceptable" be changed to "MAY be
> used"?  I believe that would remove any potential ambiguity.

I did say it was a small point...  Yes, with lowercase "may"
(definitely not 2119 "MAY"), I think that'd be slightly better, so

> The intent is b.  I propose that the words "This member MUST be present,
> even if the array elements contain only the empty JSON object "{}"" be
> changed to "This member MUST be present with exactly one array element per
> recipient, even if some or all of the array element values are the empty
> JSON object {}".  Would that be clearer?

I think that would have helped me.  Again, another small point.

> There's a reason that the introductory paragraph contains the caveat:
>    All these methods will yield the same result for all
>    legal input values; they may yield different results for malformed
>    inputs.
> I believe that this caveat covers the case of malformed (or at least
> confused) input that you're describing.  Therefore, I believe that no
> specific edit is needed to the specification in response to this comment.

Yes, that's fine; thanks for the answer.