IETF Logo Mail Archive

Re: [Fud] Comment on draft-moran-fud-manifest-00

Russ Housley <housley@vigilsec.com> Mon, 14 August 2017 13:13 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: fud@ietfa.amsl.com
Delivered-To: fud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1592C1321D2 for <fud@ietfa.amsl.com>; Mon, 14 Aug 2017 06:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 7mZN3uhnHIxL for <fud@ietfa.amsl.com>; Mon, 14 Aug 2017 06:13:42 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B821321D5 for <fud@ietf.org>; Mon, 14 Aug 2017 06:13:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1C1E1300526 for <fud@ietf.org>; Mon, 14 Aug 2017 09:13:42 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EniVQHX0UxYU for <fud@ietf.org>; Mon, 14 Aug 2017 09:13:41 -0400 (EDT)
Received: from [10.5.245.234] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id BED5530023A; Mon, 14 Aug 2017 09:13:40 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <C64FB690-1EB9-46A0-989F-DAC57E1CA819@riot-os.org>
Date: Mon, 14 Aug 2017 09:13:39 -0400
Cc: fud@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <ABCC1817-9D18-4AEC-B6DC-29AEA4E528A1@vigilsec.com>
References: <C64FB690-1EB9-46A0-989F-DAC57E1CA819@riot-os.org>
To: Thomas Eichinger <thomas@riot-os.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/fud/9wMYgdHHOHcP2_Lg9GCiRb4SV0c>
Subject: Re: [Fud] Comment on draft-moran-fud-manifest-00
X-BeenThere: fud@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <fud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fud>, <mailto:fud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/fud/>
List-Post: <mailto:fud@ietf.org>
List-Help: <mailto:fud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fud>, <mailto:fud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Aug 2017 13:13:44 -0000

Yes, it makes sense to include that.

I was wondering why you put all of the key management into the spec, instead of defining a manifest content type that is carried inside EnvelopedData.  That would cover every form of key management that you care about.  This is the approach that was used in RFC 6486, although they only care about encapsulation in SignedData.

Russ



> On Aug 10, 2017, at 6:37 PM, Thomas Eichinger <thomas@riot-os.org> wrote:
> 
> Hi,
> 
> reading draft-moran-fud-manifest-00 I am wondering what people think about
> adding a component to the manifest classifying the described update as a
> security and/or feature update (others are imaginable) in a machine-readable
> manner.
> 
> The use case I see is that users then can define rules to deploy security
> only updates in an automated timely fashion while being able to review
> others before. Similar to Directive.applyImmediately but not forced by the
> Author of the update.
> 
> Any opinions on that?
> 
> Best,
> Thomas

v2.23.0 | Report a Bug | By Email