Re: [Ace] Eric Rescorla's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 14 March 2018 23:54 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5188126FDC; Wed, 14 Mar 2018 16:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 c0r1U0b_UrOD; Wed, 14 Mar 2018 16:54:31 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77890124D68; Wed, 14 Mar 2018 16:54:31 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id a26so5447028qtj.6; Wed, 14 Mar 2018 16:54:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=46EuwjY3zZ+F38gHrbTQUyANnmdjaXT/2Ze2rgNm8cc=; b=EbG7rb1lJpg6Rzd8d1CtebAS40+/5uf/FupAXKu82/G/fEGL84exae87aCUFzoe2Br opKhy10jTTpf5C6J4pujXXy+QgchFGUoOhw24vh3hmWyyz4yed6FT6TVUh8aRUXJsTFq TK86ezNTjC55unyB2n56vAgcBVbNh0xvgVtXq0DyZaYQtGDqxWErqjTsy3j+2yo+bs+H cmGyNiVgnYYKF6CXh9va2zGRre+6dnv0C1PkfeDT5KURB1U42AlzfvUscueyS9w6UyM1 zwY9UKl/6DC+M0IiT0sPcqkwuyylkGkMHv98oDZzC+NjFK+/0UdtBZj04QHmM/Dx2B5A XFAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=46EuwjY3zZ+F38gHrbTQUyANnmdjaXT/2Ze2rgNm8cc=; b=UgeTXMJXWMnZyo9LJDQReknHjCRCMXxl93mtlP5WGTai9TZejq7fF19KwJxa6ckrJp Snz9Ybr968ivPE1PSqjT8VvhqEDxe8/GN/3BZG9EtijjsnU5wiSIGnsvAEx3uRniZWUe GM4WdWbAJAgNJkupIqswOs5hI8nCV/PmhocBafRJO4wNA1VwaGq52d8CT6zsftCgDIck +cdnz3ljGn2r6ASYd8RjTZAlCJ6UUKARzyczXGvYGeiQdcg0HUzkprlw9Bun/CxG4IO7 SgPFeMWBc5m+UB4dUrohwsmMdVbJ6DXQ7EAXdFNINu81hOnGsnGtvPJkk5InMmTjAs8K nn6A==
X-Gm-Message-State: AElRT7HRJgPQjn2+jIqreQqsRdxixVsfwCrvj2fGXK9gVCe55bzEHE/l glto+grvcxMlePPTpyh4A37V90ZQ
X-Google-Smtp-Source: AG47ELvvOiR1ZGOn9+fhuxC2AQ6ifdObEZD6KUMpXPMJ1T6vEcTWKStoz8N8C5IATNVcL3VEQWBzyQ==
X-Received: by 10.200.81.81 with SMTP id h17mr6486117qtn.55.1521071670578; Wed, 14 Mar 2018 16:54:30 -0700 (PDT)
Received: from [192.168.1.219] (209-6-112-84.s338.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.112.84]) by smtp.gmail.com with ESMTPSA id q42sm2672967qtc.19.2018.03.14.16.54.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Mar 2018 16:54:29 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-25B852DB-6892-4528-9257-66D5637BF06B"
Mime-Version: 1.0 (1.0)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: iPhone Mail (15D100)
In-Reply-To: <CABcZeBOn7HTWo7a2UMptWc1kwWRjR6D8HF8ghGyNWh91n4osxQ@mail.gmail.com>
Date: Wed, 14 Mar 2018 19:54:29 -0400
Cc: Mike Jones <Michael.Jones@microsoft.com>, The IESG <iesg@ietf.org>, "draft-ietf-ace-cbor-web-token@ietf.org" <draft-ietf-ace-cbor-web-token@ietf.org>, "ace-chairs@ietf.org" <ace-chairs@ietf.org>, "kaduk@mit.edu" <kaduk@mit.edu>, "ace@ietf.org" <ace@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <534E0DF9-A98C-4443-BE1F-BC3F272C4852@gmail.com>
References: <152045520055.17654.5520380651718604431.idtracker@ietfa.amsl.com> <SN6PR2101MB0943032402E93129E4179974F5D10@SN6PR2101MB0943.namprd21.prod.outlook.com> <CABcZeBM=gWZKEQD-aKdS9NN-ep2RGqzKRx6=2BTvW-A=O_RaGg@mail.gmail.com> <SN6PR2101MB0943ADC8E52FA4D445FC7D76F5D10@SN6PR2101MB0943.namprd21.prod.outlook.com> <CABcZeBOn7HTWo7a2UMptWc1kwWRjR6D8HF8ghGyNWh91n4osxQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/QcdtQvzDZlUexYo6wA2iHdk9KMU>
Subject: Re: [Ace] Eric Rescorla's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2018 23:54:34 -0000

Thank you.

Sent from my mobile device

> On Mar 14, 2018, at 6:31 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> Thanks. I have no objection to this draft proceeding as-si
> 
>> On Wed, Mar 14, 2018 at 2:55 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> Thanks, Ekr.  One more reply to your last comment the bottom of the message…
>> 
>>  
>> 
>> From: Eric Rescorla <ekr@rtfm.com> 
>> Sent: Wednesday, March 14, 2018 2:38 PM
>> To: Mike Jones <Michael.Jones@microsoft.com>
>> Cc: The IESG <iesg@ietf.org>; Kathleen.Moriarty.ietf@gmail.com; draft-ietf-ace-cbor-web-token@ietf.org; ace-chairs@ietf.org; kaduk@mit.edu; ace@ietf.org
>> Subject: Re: Eric Rescorla's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> On Wed, Mar 14, 2018 at 2:34 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> 
>> Hi Ekr.  Thanks for the review comments.  Responses are inline below, prefixed by "Mike>"...
>> 
>> 
>> -----Original Message-----
>> From: Eric Rescorla <ekr@rtfm.com>
>> Sent: Wednesday, March 7, 2018 12:40 PM
>> To: The IESG <iesg@ietf.org>
>> Cc: draft-ietf-ace-cbor-web-token@ietf.org; ace-chairs@ietf.org; kaduk@mit.edu; ace@ietf.org
>> Subject: Eric Rescorla's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)
>> 
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-ace-cbor-web-token-13: 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 https://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:
>> https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>>    The claim values defined in this specification MUST NOT be prefixed
>>    with any CBOR tag.  For instance, while CBOR tag 1 (epoch-based date/
>>    time) could logically be prefixed to values of the "exp", "nbf", and
>>    "iat" claims, this is unnecessary, since the representation of the
>>    claim values is already specified by the claim definitions.  Tagging
>>    claim values would only take up extra space without adding
>>    information.  However, this does not prohibit future claim
>>    definitions from requiring the use of CBOR tags for those specific
>>    claims.
>> 
>> Why do you need a MUST NOT here? This seems like not really an interop requirement
>> 
>> Mike> This requirement was added to simplify both producers and consumers of these tokens, after a working group discussion.  Not having to have code to validate, parse and then throw away tags prefixing claims of known types both makes representations smaller and requires less code.  Since the tags add no value for these claims, it seemed better to require that they be omitted.
>> 
>>  
>> 
>> Thanks. Seems reasonable.
>> 
>>  
>> 
>> ]
>> 
>>   4.  Verify that the resulting COSE Header includes only parameters
>>        and values whose syntax and semantics are both understood and
>>        supported or that are specified as being ignored when not
>>        understood.
>> 
>> I'm surprised to find that this is not a generic 8152 processing rule.
>> Can you explain why this is necessary here?
>> 
>> Mike> This intentionally parallels the same rule in JWT (https://tools.ietf.org/html/rfc7519#section-7.2, step 5).  It's saying that you have to validate that the parameters describing the parameters describing the cryptographic operations performed.
>> 
>>  
>> 
>> Sure. I don't think this is unreasonable, but why isn't a general rule for COSE messages rather than just CWT?
>> 
>>  
>> 
>> Mike> I’m sure that COSE has similar/overlapping requirements (that, or I didn’t adequately review it at the time before it became an RFC ;-) ).  As the Brits, say, this rule is “belt and suspenders” on top of that – and also reflects that CWT copies the syntax and semantics from JWT [RFC 7519] wherever applicable.
>> 
>>  
>> 
>> See you next week.
>> 
>>  
>> 
>>                                                        -- Mike
>> 
>>  
>> 
>> -Ekr
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> 
>>                                 -- Mike
>> 
>>  
>> 
>