IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 12 November 2019 08:22 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 246DE120169 for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 00:22:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 4e_U2Q4S7lAP for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 00:22:54 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9140E120046 for <rats@ietf.org>; Tue, 12 Nov 2019 00:22:54 -0800 (PST)
Received: from [192.168.44.20] (unknown [209.52.88.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPSA id 7146B3897A; Tue, 12 Nov 2019 03:19:48 -0500 (EST)
To: Laurence Lundblade <lgl@island-resort.com>
Cc: rats@ietf.org
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>
From: Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <85c7c287-48e3-83e7-900e-8e50ce43eba3@sandelman.ca>
Date: Tue, 12 Nov 2019 16:22:47 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <0C6940B0-E93F-4274-9D00-DEC4119B8F69@island-resort.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/PpcNZgvDiBAKIwwp_ozJlpGy01I>
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 08:22:57 -0000


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.

v2.23.0 | Report a Bug | By Email