Re: [sacm] CoSWID review
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Mon, 18 November 2019 12:36 UTC
Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940551200F6 for <sacm@ietfa.amsl.com>; Mon, 18 Nov 2019 04:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 YiTcERHjrZoo for <sacm@ietfa.amsl.com>; Mon, 18 Nov 2019 04:36:33 -0800 (PST)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 8D5D11200EB for <sacm@ietf.org>; Mon, 18 Nov 2019 04:36:33 -0800 (PST)
Received: by mail-oi1-x229.google.com with SMTP id n14so15095511oie.13 for <sacm@ietf.org>; Mon, 18 Nov 2019 04:36:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gAcMV+mb3guToUvhPPyco/K42eOBv3/2DFUcPlzFatI=; b=XCwO4AOFsaSKTpUr37qLIalMUJMfsEp2/fyixAtdyDyOBc4r0UXl+5BrHwmndOCFzQ VuoE+xxerJrU0Zsick4KLn/LDObJ0+EU5PWkAOaUV3j6Vun1mJtdYso1dx3Wmk4hpcd7 Qaf6RhBTNDGthfb6U4wu81K8peb3InjvEEV4FFCn66kqbgI/Fq4gr1wKvTu65NdJvEif eLl0kHT9V3EjuzxQEZX63HD8DcJyplJyip9abzyLGup257/eZK2BzTaiyty7uGfxOG80 VTmMzDuWMdscuaIOLzABCmM0WeSL9G7bES16HB3N/jyHVOxMYNtswOVSZBFl7m1X0duZ FG4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gAcMV+mb3guToUvhPPyco/K42eOBv3/2DFUcPlzFatI=; b=EFfvo5G3OnGwIltDYfOBVTjh25bFxTiQ3bqmttf3WQF8rErQ43H/M0OYbteR1OVSnF Cs8WUluqtdpFjhbcFAQFiHFpL24iLrU7qGNmzWF3pSgM3JLt888ocpgRfkkaElFAh2Vs Sjquu9moP1ycJlP9VR0o6AXO9xtwzHg3I8IxpVttxhWJGduFIO8htpX1lPVXKmiWRgXG s1qvU0vv8LBrw5Yw+x8J9javHF6kziSVjwEWqW/I8CxSOJwxGymmXwHAe5xNa/nWRbNk zdOf4Iepua86hjPu6J2N0t2gsjCH57738nxWSVka07ZqhIhohqg+BUctLIeD+ZE3HeLG i1jg==
X-Gm-Message-State: APjAAAWeXdxdsar0xDWxHdmoo87bugVvZShFiiZO3XAdn+o3/FM1Fpeo f7rGiMoUQD7ZaCqfHruVaec/SzFPowCQtRLbqTs=
X-Google-Smtp-Source: APXvYqwZyFoE0OZqjI6e06gqGXJzN3wfEUZ/w/tWAZt86jqSCQPLmjy38sJa4ZNNuly2PRIN9ysyqS+qYkGdyOeIoc4=
X-Received: by 2002:a05:6808:ab1:: with SMTP id r17mr9501825oij.111.1574080592884; Mon, 18 Nov 2019 04:36:32 -0800 (PST)
MIME-Version: 1.0
References: <CAHbuEH7OH_89+e4_BmXJN4LgxzTTQ9MtKF_03XK--a8K4AO11w@mail.gmail.com> <lejxf9f4owwm819gnwiwhlo0.1573973274271@email.android.com> <CAHcK3jMef-SK+AH4RC+EQs1LQ6wZCDAPGLCxqUyE+MFn=n-H+g@mail.gmail.com> <CAHbuEH75-jbPTqprpzjOdhRTVjtBcKy4+M6gW=zEog140ZEw5Q@mail.gmail.com>
In-Reply-To: <CAHbuEH75-jbPTqprpzjOdhRTVjtBcKy4+M6gW=zEog140ZEw5Q@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Mon, 18 Nov 2019 07:35:56 -0500
Message-ID: <CAHbuEH6SjQRriP-2Sr4k12_hRk88VR3vpTsSW7phqEdKCJoRqg@mail.gmail.com>
To: Dave Waltermire <davewaltermire@gmail.com>
Cc: "<sacm@ietf.org>" <sacm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000963a1705979e3280"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/9PgjxTIst358gOvVk9IYzTB5Zms>
Subject: Re: [sacm] CoSWID review
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2019 12:36:37 -0000
On Sun, Nov 17, 2019 at 6:45 AM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Dave, > > > > On Sun, Nov 17, 2019 at 3:02 AM Dave Waltermire <davewaltermire@gmail.com> > wrote: > >> Kathleen, >> >> Thank you for the review. I have addressed your comments in the latest >> draft. Some comments on your comments are inline below. >> >> From: sacm <sacm-bounces@ietf.org> on behalf of Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> >>> >> Date: Fri, October 25, 2019 11:57 PM +0800 >>> To: "<sacm@ietf.org>" <sacm@ietf.org> >>> Subject: [sacm] CoSWID review >>> >>> Hello! >>> >>> Thank you for your extensive work on this document! If it gains wide >>> adoption, it could be quite helpful to industry and software security >>> management. I support publication of this document and have some comments >>> and concerns to be addressed. I did not go through all sections thoroughly >>> yet, so I may come back with additional comments. >>> >>> Section 4, >>> Consider another comma in the first sentence of this text after >>> component: >>> >>> Software Patching. When a new patch is applied to the software >>> component a new patch tag is provided, supplying details about >>> the patch and its dependencies. >>> >> >> I reworded this as follows: >> >> A new patch tag is provided, when a patch is applied to the software >> component, supplying details about the patch and its dependencies. >> >> I think the comma placement is better this way. >> > > Thanks. > >> >> Section 2.4: >> >>> I see rel(ation) only appears in this section. I had to poke a bit and >>> see that (I think) you just mean for rel to expand to relation and rel is >>> used elsewhere. Would it be more clear to just define that? If this is >>> how it is in SWID, ignore the comment. I'm just thinking about other >>> reviewers/readers. It's defined in 2.7 just as rel. It's helpful to know >>> that's short for relation, but if that's all you mean, how about rel >>> (relation) so it doesn't look like more than it is? >>> >> >> I changed the reference to just "rel". I agree this is more consistent to >> how other data elements are referenced. >> > Great, thanks! > >> >> >>> Section 2.6: >>> A Thumbprint is specified in this section, should this be referenced for >>> clarity on hashes with COSE for object identification: >>> https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ >>> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cose-hash-algs%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Cb8c696edcc7243c06a4308d759641092%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637076158616321536&sdata=zAho%2FhohQF50Lv7Ux3ftxOWnFeRiT8S3XfamkLf5vEY%3D&reserved=0> >>> Would it be better to tie to the COSE set of supported algorithms (they >>> likely match, but I didn't verify)? >>> >> >> The IANA COSE Algorithms registry contains other types of algorithms >> beyond hash algorithms. To use this registry, we would need to list the >> hash-specific algorithms, which is less ideal. Its a shame this registry >> isn't broken out by algorithm type, which would make this decision easy. >> With the IANA "Named Information Hash Algorithm Registry", we get only hash >> algorithms, which is what we are looking for. Can you live with use of the >> IANA "Named Information Hash Algorithm Registry"? >> > > COSE is open as is their main draft. This is a problem that can likely be > solved this week... Talk to Jim. Let me and the list know what's possible. > >> >> >>> Section 5: >>> It might be helpful to list what is being requested at the start of the >>> IANA section >>> X registries are established with this request with initial entries for >>> X registries. Values for Z existing registries are requested. >>> >> >> Done. >> > Thanks. > >> >> >>> 5.1: >>> s/This document uses integer/This registry uses integer/ >>> >> >> Fixed. >> >> >>> Section 5.2.5: >>> >>> s/This document defines a new a new a/This document establishes a/ >>> >> >> Fixed a bunch of cases that matched this pattern. Thanks for catching >> this. >> > Just trying to head off issues at the later review stages :-) . And they > were all super minor and may have gone through unnoticed. > > >> >> >>> Security Considerations: >>> >>> I'm wondering why CWT [RFC8392] was not used or recommended for signing. >>> Is it that the other method fits better within SWIMA? >>> >> >> COSE was chosen for CoSWID, since it is parallel to the use of >> XMLDSig.for SWID tags. We could consider CWTs, but this would require a >> bunch of additional work, and we are fairly close to shipping this draft to >> the IESG. Maybe a better option might be to write a second draft discussing >> the use of CWTs with CoSWID? This would allow this draft to move forward, >> while CWT use is defined. Would you be interested in working on this draft? >> > > Yes, I am interested, with coauthors. Are you offering? > >> >> If CWTs are to be proliferated the way JWTs have been, I suspect it will >>> be easier for CoSWID to gain traction. I think it would be good to list >>> use of a CWT as an option, then registering the claims that one might use >>> for let's say having the CWT be an EAT and be a remote attestation. I >>> think adoption may be better if these are tied together and made simple for >>> regular readers who will likely start to come across CWTs as opposed to >>> just signing with one or more signers. I think what you have us good, but >>> having both as options would be better. >>> >> >> Both options would also create the need for some signature verifiers to >> support both options. This is something that should be discussed at greater >> length, as it could also create potential interoperability issues. I am not >> against both options, but we should talk to potential implementors about >> what they want. This is maybe more reason to do this work in a separate >> draft to allow for some time to work out these details.. >> > > OK, great point on interoperability. My hunch is that since CWTs are in > EATs, there is code and there is an established pattern of use that this > would be more likely to be supported (more widely). It may be good to pull > this all out as not to create confusion as if it is int he base draft, this > will be seen as necessary as opposed to a choice and as you note, will > create confusion. > >> >> >>> The claims about the signature may vary from the data in the CoSWID, so >>> this could be potentially useful. >>> >> > Right and minimal claims are possible too. > > Thanks, > Kathleen > >> >> True. >> >> >>> Thank you! >>> -- >>> >>> Best regards, >>> Kathleen >>> >> > > -- > > Best regards, > Kathleen > -- Best regards, Kathleen
- [sacm] CoSWID review Kathleen Moriarty
- Re: [sacm] CoSWID review Kathleen Moriarty
- Re: [sacm] CoSWID review Waltermire, David A. (Fed)
- [sacm] Fw: CoSWID review Waltermire, David A. (Fed)
- Re: [sacm] CoSWID review Waltermire, David A. (Fed)
- Re: [sacm] [COSE] CoSWID review Jim Schaad
- Re: [sacm] [COSE] CoSWID review Waltermire, David A. (Fed)
- Re: [sacm] [COSE] CoSWID review Jim Schaad
- Re: [sacm] [COSE] CoSWID review Michael Richardson
- Re: [sacm] [COSE] CoSWID review Jim Schaad
- Re: [sacm] CoSWID review Waltermire, David A. (Fed)