Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06

⌘ Matt Miller <> Tue, 09 December 2014 18:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EB1171A01C6; Tue, 9 Dec 2014 10:35:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.211
X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lAxPjnzSwKZ9; Tue, 9 Dec 2014 10:35:23 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3195A1A00D1; Tue, 9 Dec 2014 10:35:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7319; q=dns/txt; s=iport; t=1418150123; x=1419359723; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=B90914AsAiu92RSIn8moXMe14oE/sxnQTGX1XC91Q0A=; b=gB7+ZshA13lhsCPPCbeXXFXGcrSgJn2TuM4lmXVV1QI2a8papvqiDZSW lpK0Em3HUpQ3nCxKxV7k28+ycpt/ynlcqC2ah6AIMjaS4jkpydap4vD1C qMsIQCdmRHxCdTljmADXBhItDWNIkDYMYXN1qajOpy2YEbSH7dlnj4JTV s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="378839676"
Received: from ([]) by with ESMTP; 09 Dec 2014 18:35:22 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id sB9IZMGE005458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 18:35:22 GMT
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Tue, 9 Dec 2014 12:35:21 -0600
Message-ID: <>
Date: Tue, 9 Dec 2014 11:35:29 -0700
From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Yaron Sheffer <>, IETF Security Directorate <>, The IESG <>, <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Subject: Re: [secdir] SecDir review of draft-ietf-jose-cookbook-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Dec 2014 18:35:26 -0000

Hash: SHA512

Hello Yaron,

I believe < >
addresses most of your comments; the exceptions being those points
still under discussion (see Jim Schaad's latest reply).  Please let me
know if I missed anything I thought I fixed.

Thank you,

- -- 
- - m&m

Matt Miller < >
Cisco Systems, Inc.

On 12/4/14, 2:07 PM, Yaron Sheffer wrote:
> Hi Matt,
> Please see my comments below. I have removed much of the original
> text, and only left points that need further discussion.
> Thanks, Yaron
> On 12/03/2014 12:02 AM, ⌘ Matt Miller wrote: [...]
>>> • Unless I missed it, the document does not mention a machine 
>>> readable repository of these examples, which I am sure the
>>> author has created while writing the draft. Making such a
>>> repository publicly available would result in a much more
>>> useful resource than the current document, which essentially
>>> requires testers to scrape the document when creating their
>>> test cases.
>> You did not miss it; I don't have a such a repository right now,
>> but I can put one together.  Would something on be
>> acceptable, or is there a better suggestion?
> GitHub would be a great place.
>>> • (Not a comment to the current document:) I wonder why there
>>> is nothing explicit to distinguish a public key from a private
>>> key, and they are only distinguished by the presence or absence
>>> of several parameters, something that will not be natural to
>>> most developers. PEM is doing it very well: "-----BEGIN RSA
>>> PRIVATE KEY-----".
>>> • 3.4: the text is contradictory re: zero-padding of the value
>>> "d". Is it using the minimum number of octets, or exactly 256
>>> octets (for a 2048-bit key)?
>> The intent is that "d" is not zero-padded, and I overqualified in
>> my text.  Would the following be acceptable?
>> For a 2048-bit key, the field "n" is 256 octets in length when 
>> decoded and the field "d" is not longer than 256 octets in length
>> when decoded.
> Yes.
> [snip]
>>> • 5.1.1: since this is a "cookbook", we should be using the
>>> public key, not the private key. A private key would only be
>>> used in rare cases. Similarly 5.2.1.
>> The private keys are included for both reproduction (which only
>> needs the public key) and verification (which necessitates the
>> private key).
>> If I can put an online repository together, I can change the
>> examples to just include the public keys; otherwise would the
>> following in 5.1 (and 5.2) be sufficient?
>> Note that only the RSA public key is necessary to perform the 
>> encryption.  However, the example includes the RSA private key
>> to allow readers to validate the example's output.
> I'm fine with this new text.
>>> • 5.3.1: the "plaintext content" is a list of keys, which is 
>>> either confusing to the reader, or an actual error in the 
>>> document.
>> It is not in error.  The most common usecase for password-based 
>> encryption was the import and export of key sets, and the
>> Working Group desired a thorough example.
>> Would it help if the following is added to 5.3?
>> A common use of password-based encryption is the import/export
>> of keys.  Therefore this example uses a JWK Set for the
>> plaintext content instead of the plaintext from figure 72.
> Yes, this would help.
>>> • 5.3.5: In the General Serialization version, I don't
>>> understand why only the encrypted key is per-recipient. I would
>>> expect the PBES2 parameters too (e.g., the salt)  to be
>>> per-recipient. Presumably each of them is using a different
>>> password, and there's no reason to use a common salt. Similarly
>>> in 5.4.5.
>> For compatibility across serializations (compact, general JSON, 
>> flattened JSON), all of the parameters need to be in the JWE
>> Protected Header.  In the general serialization, that means only
>> the "encrypted_key" field is present for the (presumably) sole
>> recipient.
>> Would it be acceptable if the following were added to 5.3?
>> Note that if password-based encryption is used for multiple 
>> recipients, it is expected that each recipient use different 
>> values for the PBES2 parameters "p2s" and "p2c".
> So I still don't understand: don't we need an example that
> demonstrates how the JSON structure (or multiple structures) is
> generated so that "each recipient use(s) different values"?
> In general I don't understand this "compatibility" thing.
> Obviously there are some cases that cannot be expressed in all
> serialization types. Otherwise why would we need three of them?
>>> • 5.7: same as above, it makes sense for the per-recipient key
>>> to have an ID, rather than the content encryption key
>>> (typically an ephemeral key). And then that ID should be in the
>>> per-recipient data in 5.7.5. And similarly for 5.8. The later
>>> Sec. 5.13 shows a syntax for multiple recipients that's
>>> inconsistent with the single-recipient case, which would make
>>> sense if we got rid of the array.
>> For compatibility across serializations (compact, general JSON, 
>> flattened JSON), all of the parameters need to be in the JWE
>> Protected Header.  Also, the mixing of "recipients" and
>> "encrypted_key"/"header" in the top-level object is not permitted
>> for the general serialization.
> Still confused. Sorry.
>>> • 5.11: this example seems strange to me - why would anybody
>>> NOT want to integrity-protect the key ID and algorithm? I would
>>> prefer a more realistic example, or failing that, a
>>> recommendation to developers to avoid this practice. Similarly
>>> 5.12, which is an even worse idea.
>> Integrity protection was thoroughly discussed in the JOSE WG.
>> While there are some limited attacks possible when some
>> parameters are unprotected, the WG felt there were enough use
>> cases where these attacks are mitigated through other means that
>> integrity protection of the part of all of the header is not
>> always required.
> So (personal opinion here) I think the WG took a security risk
> that should not have been taken in 2014, for a minor performance
> gain. We have seen too many protocols fail because of
> integrity-protection shortcuts. Who would have thought you need to
> integrity-protect the padding field! The fact that CMS took this
> route back in 1999 is sort of irrelevant, as we've all learned a
> lot since then.

Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools -