IETF Logo Mail Archive

Re: [Rats] Question about WG Procedure -- Re: 答复: Use case -> architecture document

Laurence Lundblade <lgl@island-resort.com> Wed, 16 October 2019 15:49 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 4066C120806 for <rats@ietfa.amsl.com>; Wed, 16 Oct 2019 08:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 mnEe3tke8YxE for <rats@ietfa.amsl.com>; Wed, 16 Oct 2019 08:49:55 -0700 (PDT)
Received: from p3plsmtpa06-06.prod.phx3.secureserver.net (p3plsmtpa06-06.prod.phx3.secureserver.net [173.201.192.107]) (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 4A294120164 for <rats@ietf.org>; Wed, 16 Oct 2019 08:49:55 -0700 (PDT)
Received: from [192.168.1.76] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id KlYei8H5OmAkgKlYfitT0k; Wed, 16 Oct 2019 08:49:54 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <1DCF08C6-A75C-4725-9CED-321D288CB4D3@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D75042EC-05BC-4F1A-9FFA-C8AB3E7D9EB4"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 16 Oct 2019 08:49:52 -0700
In-Reply-To: <08D3CA59-6797-47D8-86CE-3A3B1E5EEE7A@intel.com>
Cc: Thomas Hardjono <hardjono@mit.edu>, "rats@ietf.org" <rats@ietf.org>
To: "Smith, Ned" <ned.smith@intel.com>
References: <CAHbuEH7f0jjquR=iZDgof4DkgpZKgxEP86NcQ0A1NQ=SP+_FHA@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F13E9560C0@dggemm511-mbx.china.huawei.com> <1571169312645.46550@mit.edu> <08D3CA59-6797-47D8-86CE-3A3B1E5EEE7A@intel.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfKWHYsjQKR3dEzx4qp+gzFn6WmCFBP5KiUHGNsE/JOifiKVQUY77J1EfI6Gpk/fatYJ8Bnoy9KFfKc7U7DfHa2wE/cTpofbJLvdqNv0lqxvG/nzhjQzu Aj9fcy0/8jDwMYX+FqMm4uEv+uGgFqMRdMXzssJU6A8b5SYlxL98qCmg4ZpgOrzNwxukkbSYfMtd+FPJ6/0aBVCFuu3/011rxH5xqPfxo9o5hNLtK6QbWqb/
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/bIY85dU1tB54xdUUeps12n0Fui4>
Subject: Re: [Rats] Question about WG Procedure -- Re: 答复: Use case -> architecture document
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: Wed, 16 Oct 2019 15:49:57 -0000

> On Oct 16, 2019, at 8:13 AM, Smith, Ned <ned.smith@intel.com> wrote:
> ...
> The original milestones suggested that the timing could lag that of other drafts (that seem to address more immediate needs.) Maybe that is no longer the case because of a need to agree on terminology, attestation workflows or connection endpoint semantics?
...

EAT is not being held up by lack of a completed architecture document. The same might be true of the yang draft.

i think it is still true that architecture can lag the other documents.

Lots of use cases already know what to do about end-end flows and architecture. FIDO and Android attestation already have their flows. They could use EAT without any IETF architecture document.


Seems like the architecture effort is attempting a unified field theory of attestation across all use cases. I think this is of value, but hard to do.

LL

v2.23.0 | Report a Bug | By Email