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

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 29 November 2020 20:18 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 B3A303A0E08 for <rats@ietfa.amsl.com>; Sun, 29 Nov 2020 12:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 gKKJJYrqU_cb for <rats@ietfa.amsl.com>; Sun, 29 Nov 2020 12:18:06 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BD43A0B80 for <rats@ietf.org>; Sun, 29 Nov 2020 12:18:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1EDB8389B3; Sun, 29 Nov 2020 15:19:42 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vUtZJCQZ509S; Sun, 29 Nov 2020 15:19:41 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 820F2389B1; Sun, 29 Nov 2020 15:19:41 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4A03270D; Sun, 29 Nov 2020 15:18:03 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Giri Mandyam <mandyam@qti.qualcomm.com>, rats@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Sun, 29 Nov 2020 15:18:03 -0500
Message-ID: <24519.1606681083@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/dtkM1EZJeHJQcW__rHSsmCgu4qs>
Subject: [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: Sun, 29 Nov 2020 20:18:09 -0000

Hi, sorry that I missed the RATS IETF109 meeting: I was engaged as co-chair
of ASDF at the same time.   I watched the video.

I think that the many EAT concerns are now at the point where more
conversation probably will make it worse rather than better.
It's time to move on with the EAT framework: many of the issues discussed
will become much clearer when it is used.
That's why we have "PS" vs "Internet Standard".

I found Giri's presentation interesting: I scanned through the FIDO IoT
Onboarding document, and I have no idea why FIDO needs to re-invent
(Constrained) BRSKI.   But, I'm excited about it!

The more the manufacturers understand the need for device identities, and
for a "home base" (A Registrar), the better our whole industry will be.
When MS tried to do this with the XBOX-1 a decade ago, people cried foul, but
maybe they weren't ready for this in the home yet.  We certainly need it to
be standards based, and free of stupid IPR stuff.  What will CHIP do, I wonder.

The single reference to RFC8366 did not explain why that document did not
adopt a semantically compatible voucher format.

draft-ietf-anima-constrained-voucher explains how to serialize the YANG to
CBOR using draft-ietf-core-yang-cbor and draft-ietf-core-sid.
This is then signed with COSE.
{Or CMS, but that option is going away}

The result is almost *syntactically* identical to an EAT (a map of stuff
signed by COSE)!
But the semantics are a fair bit different.
Vouchers contain many things which I would not call claims, but embody
essentially a single claim concerning ownership.

draft-ietf-core-sid establishes a registry for SID values, which as
essentially map keys for CBOR.  It has been difficult to get the document to
advance, and until it did, we couldn't figure out how we'd be able to do
the IANA allocation process: hard to get an early allocation against a
registry which does not yet exist.

What we did, and what Giri could ask the EAT authors and WG to do is to
allocate some claims in the initial IANA Considerations section.
That is, until such time as the document progresses through the IESG,
the WG and the document authors essentially act as IANA.

Here is what it looks like from draft-ietf-core-sid:

section 7.5.3 (of sid-14):

   Initial entries in this registry are as follows:

   +-------+------+---------------------------+------------------------+
   | Entry | Size | Module name               | Document reference     |
   | Point |      |                           |                        |
   +-------+------+---------------------------+------------------------+
   |  1000 |  100 | ietf-coreconf             | [I-D.ietf-core-comi]   |
   |  1100 |   50 | ietf-yang-types           | [RFC6991]              |
   |  1150 |   50 | ietf-inet-types           | [RFC6991]              |
   |  1200 |   50 | iana-crypt-hash           | [RFC7317]              |
   |  1250 |   50 | ietf-netconf-acm          | [RFC8341]              |
   |  1300 |   50 | ietf-sid-file             | RFCXXXX                |
   |  1500 |  100 | ietf-interfaces           | [RFC8343]              |
   |  1600 |  100 | ietf-ip                   | [RFC8344]              |
   |  1700 |  100 | ietf-system               | [RFC7317]              |
   |  1800 |  400 | iana-if-type              | [RFC7224]              |
   |  2400 |   50 | ietf-voucher              | [RFC8366]              |
   |  2450 |   50 | ietf-constrained-voucher  | [I-D.ietf-anima-constr |
   |       |      |                           | ained-voucher]         |
   |  2500 |   50 | ietf-constrained-voucher- | [I-D.ietf-anima-constr |
   |       |      | request                   | ained-voucher]         |
   +-------+------+---------------------------+------------------------+




--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide