Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Laurence Lundblade <lgl@island-resort.com> Tue, 12 November 2019 17:56 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 BCF03120991 for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 09:56:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 TjduuDA9pHuN for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 09:56:44 -0800 (PST)
Received: from p3plsmtpa07-09.prod.phx3.secureserver.net (p3plsmtpa07-09.prod.phx3.secureserver.net [173.201.192.238]) (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 001FD12098C for <rats@ietf.org>; Tue, 12 Nov 2019 09:56:43 -0800 (PST)
Received: from [10.141.0.10] ([45.56.150.139]) by :SMTPAUTH: with ESMTPA id UaPCi9zPPM55NUaPCiZsqh; Tue, 12 Nov 2019 10:56:42 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <85c7c287-48e3-83e7-900e-8e50ce43eba3@sandelman.ca>
Date: Tue, 12 Nov 2019 09:56:41 -0800
Cc: rats@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <147FEACA-56F0-43A0-8F25-639D0613E4BD@island-resort.com>
References: <8B173958-FC2A-4D1D-A81C-F324AB632CD7@cisco.com> <147F9159-6055-4E55-ABDC-43DFE3498BF1@island-resort.com> <ce5f8206-74dc-36bb-0093-a93045d5c67f@sit.fraunhofer.de> <0A7E3A4F-8534-4E98-BCB7-1454E07699F4@island-resort.com> <C3AE2645-49C8-4313-BCED-02FEB576B614@cisco.com> <1C8A1884-A37D-45E3-8C11-2FC5A083B245@island-resort.com> <ba12a686-1b34-21a3-388c-bbe01c01a408@sandelman.ca> <4A83CDF5-D29F-4279-8B03-E9D23299EB53@island-resort.com> <0C6940B0-E93F-4274-9D00-DEC4119B8F69@island-resort.com> <85c7c287-48e3-83e7-900e-8e50ce43eba3@sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfMyC75vJfXcEXrpEFE/HsAkNqXCWZlsYqzgYywGYLVdy8PgtQFOAZg+bQLxTBf5q5nMi+5/8q+ZxBFW0J+sbVqoQS7rhFXYMxwiLVuy6HwGy6Lyn7TAT MFdM2U9DQw91VqPF+FcD6FMFv8NwI+4b+NevbttBhK7YPLZn8mjDkDQYcI/3Ejm5S8TAWgbag/YJsst7Jgxwuwk8PoEzqsEqKiQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/Re-mnxD_S-Gq6EdiL6cegK4CE2w>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft
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: Tue, 12 Nov 2019 17:56:46 -0000


> On Nov 12, 2019, at 12:22 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> On 2019-11-12 3:52 a.m., Laurence Lundblade wrote:
>> One more note on this. It seems wrong-headed to try express claims in
>> YANG. To do that we’d need to invent a YANG signing standard (YOSE?).
>> Seems like YANG should be thought of as RPC / conveyance / transport
>> here, not as a way to format a signed attestation token.
> 
> YANG is an information model (think ASN.1). 
> It is for humans and for code generators, protocol inspectors, etc, it
> is never bits on the wire.
> It needs to be expressed somehow (XML, JSON, CBOR), which is akin to
> BER/DER.
> XML, JSON and CBOR all have signature standards (maybe more than one).
> A specific claim could well have a complex set of information that it
> conveys and that could be expressed in YANG, but I find it difficult to
> imagine such a thing.
> 

Got that one totally wrong. I even knew everything you describe about YANG.

I still think it is better if we just stick to EAT / CWT / JWT claims described with CDDL as the way we define claims in RATS, except for a few TPM-specific claims. 

LL