Re: [Suit] [suit]: draft-moran-suit-manifest-02
David Brown <david.brown@linaro.org> Fri, 13 July 2018 16:39 UTC
Return-Path: <david.brown@linaro.org>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7672130E9F for <suit@ietfa.amsl.com>; Fri, 13 Jul 2018 09:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org
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 EOj-dOmVPCfR for <suit@ietfa.amsl.com>; Fri, 13 Jul 2018 09:39:45 -0700 (PDT)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 EC2F7130E88 for <suit@ietf.org>; Fri, 13 Jul 2018 09:39:44 -0700 (PDT)
Received: by mail-it0-x235.google.com with SMTP id p17-v6so12360073itc.2 for <suit@ietf.org>; Fri, 13 Jul 2018 09:39:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=c3zaE/STABbRQ7P5rnaVwsjlFdm8U+vbAiTsT/mih50=; b=MVVXqqb8H3SCP4FHfMwiR/wLiHGgX11UlC+TVWF2v15jnWEczS5eWVVhw0thRywaWI dT5ingf3iHR1vfeRAPGqSwGyw0uEkFtuNHugvSS1HuErP3s2w6LbqomUm/JPZt3GYIu7 /LllCZjb6Ba/VhthBU/nCtnu0q/lPSIRN+mSA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=c3zaE/STABbRQ7P5rnaVwsjlFdm8U+vbAiTsT/mih50=; b=rKVIRCgj9Zob1uF6cQJsID3rBqheYSck01oy1iy7D735828L7gzqFdwRi2hNL4My0n mOZcpVMgxExQzAcAU+gu4ENj8ZqaZnmoh8ZulyeXZtFLry9ejD7rghf3kVDLbT2VkS26 B2FeN5Es22Yjyra+i8nlLFASrPaXNoWrQocZnu+DLfhUwLtIRPJnfDMGu7+jp5eZyAHC rGVoij90w/HUX97jkd5DQPM0RoUY/KuBL8l56cFXfkpUpB5LZg5vBqrHMmXC6FT9xHVX wByt2LZ8Fm6gkcYp752lfg2GFTl3SP0LNAJP3vu0ODGB/ahPhLUeobXisOZk0oXDYPnN ZiRw==
X-Gm-Message-State: AOUpUlHWsP6K2h6u/223WR9jYUrdixnM9tvq6VbK4uckGOu1Dd2iGwTC oG6MPnRtVkqAQpAagfCtU51/zQ==
X-Google-Smtp-Source: AAOMgpfvtMbSlCfvlP5GlRwV6OzH7wHjC9qDsclbi22ztaESaOPbRVaPDid65SOUWQqG7U1qNGECGw==
X-Received: by 2002:a02:4442:: with SMTP id o63-v6mr6189139jaa.75.1531499984209; Fri, 13 Jul 2018 09:39:44 -0700 (PDT)
Received: from davidb.org ([2601:283:4300:987c:6245:cbff:fe6d:5400]) by smtp.gmail.com with ESMTPSA id q204-v6sm2251147itb.27.2018.07.13.09.39.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jul 2018 09:39:43 -0700 (PDT)
Date: Fri, 13 Jul 2018 10:39:41 -0600
From: David Brown <david.brown@linaro.org>
To: Brendan Moran <Brendan.Moran@arm.com>
Cc: suit <suit@ietf.org>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Message-ID: <20180713163941.GC27373@davidb.org>
References: <FDAB87B5-A7CB-4BBC-B7CF-763355B099D8@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <FDAB87B5-A7CB-4BBC-B7CF-763355B099D8@arm.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/zHwzQn6kHsE5ob9aUkMRJ4Wnn0E>
Subject: Re: [Suit] [suit]: draft-moran-suit-manifest-02
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2018 16:39:49 -0000
On Tue, Jul 03, 2018 at 09:08:02PM +0000, Brendan Moran wrote: >This draft is a significant departure from previous drafts, so I think it is >important to highlight the changes. The draft requires a lot of text that >hasn’t been written yet, so I will try to put some of that here for discussion. > >[1]https://datatracker.ietf.org/doc/draft-moran-suit-manifest/ In this email, I wanted to enumerate the parts of the current manifest draft that are either unclear to me (possibly just needing more explanation) and/or should be reworked. 1. Signature contents. A few things need to be spelled out about the COSE_Mac and COSE_Sign blocks: - The payload should be a "Manifest". - What is the content type used for this. Presumably, we will register one for a SUIT manifest, when the RFC is finalized, but it does need to be stated. Just stating it is CBOR could also work, but then a processor would have to look into the payload to determine if it is a manifest. - Is the CBOR for the manifest tagged? If so, we should register a tag for our manifest format. 2. DigestInfo We need to define the values for digestAlgorithm, and what is contained in digestParameters. Are these related to the values defined in COSE, or at least do they come from the same number space? 3. Encoding of ProcessingStep, Pre and Post conditions. Using different arrays with the first element of the array is a number indicating the meaning of the remainder of the array is different than how I've seen other data represented in CBOR. I'm presuming that this is so that order can preserved, where as a map would require a specific order for a canonical encoding. I don't know the ramifications of this on processing code. It is certainly legal from CBOR's point of view. Other possibilities would be to have the fields be an array of pairs, similar to how a map would be encoded, but described as an array so that order could be preserved. I don't know if this can be represented in CDDL. It could also be an array of maps. The grouping simply used to allow ordering to be enforced when that is needed. 4. The Directive encoding The CDDL grammar allows the "=>" to be used inside of an array (so this parses), but there are no example or explanation of what this would mean. Do we intend for the Directive to be a map, or are we hoping to have something of an ordered map, similar to what I described above as an array of pairs. 5. Use of numbers. We have numerous fields that make use of small integers. Is the intent that these be fixed, and any additional values only be allowed in the 'extensions' field? 6. Extensions. The extensions are described as maps. Do we envision a case where ordering needs to be preserved in extensions? In addition, do we need to have something similar to the criticality header in COSE where a manifest can say certain extensions are mandatory, and that an actor that doesn't understand that extension should reject the manifest? Thanks, David
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 Rønningstad
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 David Brown
- [Suit] [suit]: draft-moran-suit-manifest-02 Brendan Moran
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 Kvamtrø
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 David Brown
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 David Brown
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 David Brown
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 Kvamtrø
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 David Brown
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 David Brown