Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT

Laurence Lundblade <lgl@island-resort.com> Fri, 04 December 2020 19:57 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA293A0779 for <rats@ietfa.amsl.com>; Fri, 4 Dec 2020 11:57:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 xs5-g4YX5KL2 for <rats@ietfa.amsl.com>; Fri, 4 Dec 2020 11:57:04 -0800 (PST)
Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A493A07EA for <rats@ietf.org>; Fri, 4 Dec 2020 11:57:04 -0800 (PST)
Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id lHCRkQFA8tTlulHCRkltc3; Fri, 04 Dec 2020 12:57:03 -0700
X-CMAE-Analysis: v=2.4 cv=VKEYI/DX c=1 sm=1 tr=0 ts=5fca948f a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=l70xHGcnAAAA:8 a=K6EGIJCdAAAA:8 a=48vgC7mUAAAA:8 a=cwqS3dj9ZH9cp9PlTLUA:9 a=QEXdDO2ut3YA:10 a=DW-bgVKlNrYr8FS5:21 a=_W_S_7VecoQA:10 a=JtN_ecm89k2WOvw5-HMO:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <AD1F4237-A5AC-4DF5-B48A-D0C5CD1DF9A1@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C9313942-A3E9-4F86-9097-7B1815F13DBC"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Fri, 4 Dec 2020 11:57:02 -0800
In-Reply-To: <24158.1606778219@localhost>
Cc: "rats@ietf.org" <rats@ietf.org>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "Nancy Cam-Winget (ncamwing)" <ncamwing=40cisco.com@dmarc.ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "Smith, Ned" <ned.smith@intel.com>
References: <24519.1606681083@localhost> <BL0PR11MB312296BEFD428C6D9CE9A5DEA1F50@BL0PR11MB3122.namprd11.prod.outlook.com> <AM0PR08MB371606D3753BED36E71A5754FAF50@AM0PR08MB3716.eurprd08.prod.outlook.com> <BL0PR11MB3122D35683FD909A3C80E4DEA1F50@BL0PR11MB3122.namprd11.prod.outlook.com> <3849.1606759884@localhost> <B9175A1C-C024-463F-B438-36C7DDEBD1A8@island-resort.com> <24158.1606778219@localhost>
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfAwsmrl/xfDacOPAehKzxP8tXVybtEcY1ClxAFBj53AmN/1D9TDcXtOoxjZvWfYd0rxk0sWZVo0IGJbrY0R7pNJNdSS+FDM4wFFwA+ss7/57zTfGwONq VHFxihr81LHmE85aLYUEXqS68n4xY1Grz+MNFyjwc1m1PoasbdjmyoJthXBWtoAgdiqiNk1ePE5A+QG4VzHaZ43DmCOXqLRCOBHHEOke6LgeqvF1i+qBtP1a LnrXvG35wKy+MSjVXcB0t4WiDN8OEMxGG0RdeHd9sMhUxzZ+/kj+bbUk847rLXYFPLmmiOlpTxc4PdSFMgqCutneOA0jM3urZeczPHqGCr9ptWth8Ot5tdKb geva75Qf
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/FwCqNrYjbiTd0nGZ0Wg9RQ2uU8o>
Subject: Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2020 19:57:06 -0000

So I read RFC 7120 which is super clear and exactly what is needed. It lines up with my third proposal. We will ask IANA to pre-register claims in the Standards Action space of the CWT registry and also in the JWT registry. Or rather per the 7120, the WG chairs determine consensus here, then will ask the AD(s) and then ask IANA.

Is there consensus on pre-registration of these?

Name      Description         CWT     JWT                     Type
nonce     Nonce               10      <already registered>    byte string
ueid      Universal Entity ID 11      ueid                    byte string
oemid     OEM ID              13      oemid                   byte string
seclevel  Security Level      14      seclevel                integer
secboot   Secure boot         15      secboot                 integer
dbgstat   Debug status        16      dbgstat                 integer
location  Location            17      location                map
submods   Submodules Section  20      submods                 map

These have all been in the EAT document for a long time and are described well in draft-ietf-rats-eat-06. They are fairly well understood and have either no open issues or only small open issues in GitHub against them. They include the most essential claims (nonce, ueid, oemid & submods) to implement an EAT.

I have chosen not to ask for the others because I don’t think they are as essential or as well understood yet and thus don’t meet the criteria in RFC 7120.

CWT numbers aren’t contiguous so as to line up with examples that have been in the EAT draft for a while. I’ve shortened the JWT claims keys to less than 8 per RFC 7519. 

If approved and registered, we’ll quickly publish a new EAT draft.

LL





> On Nov 30, 2020, at 3:16 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Laurence Lundblade <lgl@island-resort.com> wrote:
>> The trouble is that I think many claims should be in the Standards
>> Action range (-255 to 255).  For example, nonce, ueid, submods section,
>> location, CoSWID and probably a few others should be in the standard
>> space. If I were IANA I would hesitate to register these in the
>> Standards Action range until the EAT document is further along.
> 
> The WG can ask for Early Allocation.
> It should do it immediately, so that the Expert will provided feedback immediately.
> 
>> It also seems poor practice to unilaterally pre-assign Standards Action
>> range claims in an EAT draft and then use them in a bunch of
>> implementations. Those numbers could be assigned to some one else
>> before EAT is an RFC.
> 
> You can do that if a registry you are just creating.
> But, yes, you can't do that if you are using CWT.
> 
>> Register them in the Specification Required space (255 to 65535) once
>> and for all. That will result in 3-byte map labels rather than 1-byte
>> map labels, but there’s no transition.
> 
>> Finally, a third proposal:
> 
>> Maybe we can convince IANA to pre-register a small clear set in the
>> standard space? Perhaps just nonce and UEID.
> 
> Please go read RFC7120.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats