Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 02 October 2014 15:45 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAEF1A8731; Thu, 2 Oct 2014 08:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDYWYUbfYQrQ; Thu, 2 Oct 2014 08:45:15 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC75F1A872B; Thu, 2 Oct 2014 08:45:14 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id ge10so2554903lab.24 for <multiple recipients>; Thu, 02 Oct 2014 08:45:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bHuWLYJMpBruKSniKk6XGR6XC/3mhabSrJoRheNjAJw=; b=vSI1/er60Cwt86QIQsCMiybHeg/OUAjQq222otViq68Jrp9hZ79vlX9jLDjaKr79+3 HOurCfzg9isABZB5HPedq5Wr0FLrhH6baYD/KRFcuTQcUfPdNshnljBx1f7q9Vh3AMwG zGuOUeFN73COXkLdFy6P12n22WY8P7O5nTSDbpNp7P5rxjcuvLyTmm3PU4r8TtwJNZI8 pCpxAhnqoDh/Bt3ZWzfNsf2fhT1fhLN+ekuJtv5rxyaNLwkYkHrtwoMHuD/kb8Or3CTf Xh+E1c7V6jZH96YFwrGRGPTC7p8OCppawJnEDtNYKYye+plBHCJsB2oEfPPeGd5lUfSY I/Hg==
MIME-Version: 1.0
X-Received: by 10.152.44.136 with SMTP id e8mr64636850lam.36.1412264712984; Thu, 02 Oct 2014 08:45:12 -0700 (PDT)
Received: by 10.112.95.36 with HTTP; Thu, 2 Oct 2014 08:45:12 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAB3877@TK5EX14MBXC288.redmond.corp.microsoft.com>
References: <20141002030353.19877.20944.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAB3877@TK5EX14MBXC288.redmond.corp.microsoft.com>
Date: Thu, 2 Oct 2014 11:45:12 -0400
Message-ID: <CAHbuEH7GPwdh8uxrA-ENbiHCtWW8z-DFVt_FwYspnNHm_Eq18g@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=089e0160a8b28bde7b05047280e7
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/D0sGxdebLYPh9ZXK-i9fzaZXN5Y
Cc: "draft-ietf-jose-json-web-algorithms@tools.ietf.org" <draft-ietf-jose-json-web-algorithms@tools.ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Oct 2014 15:45:17 -0000

On Thu, Oct 2, 2014 at 11:25 AM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

>  Responding only to the DISCUSS portions for now…
>
>
>
> -----Original Message-----
> From: Pete Resnick [mailto:presnick@qti.qualcomm.com]
> Sent: Wednesday, October 01, 2014 8:04 PM
> To: The IESG
> Cc: jose-chairs@tools.ietf.org;
> draft-ietf-jose-json-web-algorithms@tools.ietf.org
> Subject: Pete Resnick's Discuss on draft-ietf-jose-json-web-algorithms-33:
> (with DISCUSS and COMMENT)
>
>
>
> Pete Resnick has entered the following ballot position for
>
> draft-ietf-jose-json-web-algorithms-33: Discuss
>
>
>
> 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 http://www.ietf.org/iesg/statement/discuss-criteria.html
>
> for more information about IESG DISCUSS and COMMENT positions.
>
>
>
>
>
> The document, along with other ballot positions, can be found here:
>
> http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/
>
>
>
>
>
>
>
> ----------------------------------------------------------------------
>
> DISCUSS:
>
> ----------------------------------------------------------------------
>
>
>
> Moving this first one from a comment to a discuss in light of Richard's
>
> comment:
>
>
>
> 3.1/4.1/5.1/6.1: Why are there implementation requirements in this
> document? I am also curious, as Richard is, whether these are going to be
> used at all, and I'd like to hear the explanation that the WG had for
> including these. Are implementation requirements for JOSE different from
> implementation requirements for any other use of signing or encryption for
> each of these algorithms? Don't we already have a separate general registry
> of algorithms and their implementation statuses? Why are these necessary?
>
>
>
> There are implementation requirements so that implementations will
> actually be interoperable in practice and not just in theory.
>
> We'll need to address this and it may be agreeable to move these to
recommendations, but let's run through this and respond in detail.

Thanks.

>
>
> 4.6.2: AlgorithmID. UTF-8 has me worried here. It has me more worried in
> 4.8, but we'll talk about that later. Here, aren't all "enc" and "alg"
>
> values US-ASCII anyway? Saying US-ASCII here would solve the problem, so
> unless you think you're going to have the MötleyCrüe algorithm, perhaps we
> can avoid any concerns for this case. (My concern is that you can have
> "interesting" UTF-8 strings with ZERO-WIDTH JOINERs and other nonsense that
> you probably don't mean to address.
>
>
>
> Even if people used pathological Unicode characters, the exact-match
> string comparison rules would handle this OK.  In practice, what I think we
> should do is provide guidance in the IANA registry instructions that only
> reasonable, displayable Unicode character sequences be registered.  I’m
> reluctant to tell people using non-US character sets that they can’t use
> printable glyphs from their own languages.  Do people have a suggestion
> what language this guidance should contain?
>
>
>
> 4.8:
>
>
>
>    The PBES2 password input is an
>
>    octet sequence; if the password to be used is represented as a text
>
>    string rather than an octet sequence, the UTF-8 encoding of the text
>
>    string MUST be used as the octet sequence.
>
>
>
> This one worries me a lot. It's one thing to say that the password is an
> octet sequence and the application above is responsible for collecting it
> from the user and passing it in the correct form. But to say down here in
> the guts that it MUST be UTF-8 brings up all sorts of ugly questions
> regarding normalization. I don't think you want to touch this with a
> 10-foot-pole. I certainly thing you want to stay away from that MUST.
>
>
>
> To achieve interoperation, some encoding has to be specified, and UTF-8
> seems like the best choice.  Restricting human-visible passwords to ASCII
> isn’t reasonable for most cultures.
>
>
>
> 4.8.1.1: Same as 4.6.2.
>
>
>
> Same answer.
>
>
>
> ----------------------------------------------------------------------
>
> COMMENT:
>
> ----------------------------------------------------------------------
>
>
>
> For the life of me, I can't figure out why this document set uses the
> terminology "JSON Web Foo". Seems like buzzword nonsense. I would have much
> preferred "JOSE Foo" for each one.
>
>
>
> 3.2:
>
>
>
>    A key of the same size as the hash output (for instance, 256 bits for
>
>    "HS256") or larger MUST be used with this algorithm.
>
>
>
> Is this specific to JOSE, or is this a general requirement for use of
> SHA-2? If the latter, a reference would be better than a MUST in here.
>
>
>
> [There are many things in the document that look like algorithm
> requirements and not JOSE requirements. I've noted a few more below, but
> these should be looked for generally. If something is part of the
> definition of the algorithm and documented elsewhere, no need to have
> requirements language, let alone a description of how to run the algorithm,
> in this document; that should be an external reference.]
>
>
>
> In the 5th paragraph (the one right after the table), strike everything
> after the first sentence. Decoding and encoding are things that are JWS
> specific and should not be in this document.
>
>
>
> 3.3/3.5/4/2/4.3:
>
>
>
>    A key of size 2048 bits or larger MUST be used with this algorithm.
>
>
>
> Is this specific to JOSE, or is this a general requirement for use of RSA?
>
>
>
> 3.6: This section seems to be for the JWS document, not this one. If you
> want to define the "None" algorithm, go ahead and do that, but describing
> its use in JWS doesn't belong here.
>
>
>
> 4.6:
>
>
>
>    A new ephemeral public key value MUST be generated for each key
>
>    agreement operation.
>
>
>
> Again, specific to JOSE, or requirement of ECDH-ES?
>
>
>
>    In Direct Key Agreement mode, the output of the Concat KDF MUST be a
>
>    key of the same length as that used by the "enc" algorithm.
>
>
>
> and
>
>
>
>    In Key Agreement with Key Wrapping mode, the output of the Concat KDF
>
>    MUST be a key of the length needed for the specified key wrapping
>
>    algorithm.
>
>
>
> s/MUST/will?
>
>
>
> 4.6.1.2/4.6.1.3: These are not very well defined, and it's not clear why
> they need to be base64ed. What are they?
>
>
>
> 5.2.2.1:
>
>
>
>        Here we denote the number of octets in the MAC_KEY as
>
>        MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN;
>
>
>
> Oh, dear. That's a pretty convoluted way of saying (I think) "MAC_KEY_LEN
> is the number of octets in MAC_KEY and ENC_KEY_LEN is the number of octets
> in ENC_KEY." If you mean something different, you best explain.
>
>
>
>        the values of these parameters are specified by the Authenticated
>
>        Encryption algorithms in Sections 5.2.3 through 5.2.5.
>
>        The number of octets in the input key K MUST be the sum of
>
>        MAC_KEY_LEN and ENC_KEY_LEN.
>
>
>
> "MUST"? Do you mean "is"?
>
>
>
>        When generating the secondary keys
>
>        from K, MAC_KEY and ENC_KEY MUST NOT overlap.
>
>
>
> Isn't that completely redundant? If length of K is the sum of MAC_KEY_LEN
> and ENC_KEY_LEN, then MAC_KEY and ENC_KEY *can't* overlap.
>
>
>
> 6.2: s/MUST be/is
>
>
>
>
>



-- 

Best regards,
Kathleen