[Rats] draft-thaler-rats-architecture (was Re: Use case -> architecture document)

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 16 October 2019 12:03 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DAA10120921 for <rats@ietfa.amsl.com>; Wed, 16 Oct 2019 05:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.436
X-Spam-Level: *
X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JGnAQQU6nI1u for <rats@ietfa.amsl.com>; Wed, 16 Oct 2019 05:03:34 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F98D12091B for <rats@ietf.org>; Wed, 16 Oct 2019 05:03:33 -0700 (PDT)
Received: from dooku.sandelman.ca (dhcp-25-21.mtg.ripe.net []) by relay.sandelman.ca (Postfix) with ESMTPS id 04BAC1F455 for <rats@ietf.org>; Wed, 16 Oct 2019 12:03:32 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 9F681FEE; Wed, 16 Oct 2019 14:04:24 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "rats\@ietf.org" <rats@ietf.org>
In-reply-to: <MWHPR21MB078499E5D4A2A5E697924EC7A3900@MWHPR21MB0784.namprd21.prod.outlook.com>
References: <CAHbuEH7f0jjquR=iZDgof4DkgpZKgxEP86NcQ0A1NQ=SP+_FHA@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F13E9560C0@dggemm511-mbx.china.huawei.com> <CAHbuEH7WkqeyUW3sL5bdw5N25B6O7ZEF0Qkx03fE5c42Sd4M5w@mail.gmail.com> <b91baad2-2fc3-a5e4-6898-e2cddcda300d@sit.fraunhofer.de> <20191009145006.r2pjsoo6jxirah64@anna.jacobs.jacobs-university.de> <CAHbuEH6u-6GsJjK8s0eFQPLeSuGjPMgonhyQkmaeA6Q+rp42kA@mail.gmail.com> <9379d880-2b7e-6657-c547-b37bb7a9e466@sit.fraunhofer.de> <CAHbuEH7XfWgPT+=T-Za9Cw-5GRQj0_+WT3L+Kd4aPp6VvU9jAQ@mail.gmail.com> <MWHPR21MB078499E5D4A2A5E697924EC7A3900@MWHPR21MB0784.namprd21.prod.outlook.com>
Comments: In-reply-to Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org> message dated "Mon, 14 Oct 2019 23:01:04 -0000."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 16 Oct 2019 14:04:24 +0200
Message-ID: <18312.1571227464@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/iWIjSj3eMxHQ2pJpyccuXBfLah4>
Subject: [Rats] draft-thaler-rats-architecture (was 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 12:03:43 -0000

Thank you for the very well written draft.  This document ably demonstrates
why keeping you on the IAB always made sense.

While I can see that you include use cases into the document, it was not
"some small additions" to the use case document.  I'm not complaining!
It's a new document and it should be evaluated like that.

I found the selected use cases to be at times difficult to distinguish.
I think that the existence of the 2+ architectual models should be introduced
earlier, and that it is worth including an explanation in each use case as to
how they make use of the passport/background-check model.

{As a non-RATS thought: it occurs to me that many of the meat-space things
that use background checks would be better off with a passport model.
However  the cost of creating unforgeable passports has historically been too
high.  The cost to create a counterfeit medical or law diploma has been
assumed to be  higher than it really is.  Or another analogy is that
passports are certificates and background checks are OCSP...}

This document does not clearly lead me to knowing what the form the
technology should be.  I might be led to believe that there is an
architectual requirement to do everything in PKIX certificate extensions,
while I think that we are really heading towards CWT/JWT.

While the two architecture workflows you include overlap with
draft-birkholz-rats-architecture-02's figure 1, I think we need to work on
our diagrams a bit.

I'm not fond of the word "Attestee", as correct as it might be in some cases.
Neither document uses it, which makes me happy.
It's too easily confused with Attester (by people with poor eyesight,
auto-correctors, and non-English speakers).

I still find the terms Attester and Verifier confusing.

I think that when the Verifier signs/creates the Attestation Results, that
this is an act of Attestation, and this the Verifier is the Attester.

draft-birkholz-rats-architecture uses this term Computing Environment, which
I don't think works well, but I don't have a better suggestion.

I know that there is a TCG meeting in Toronto this week (probably occuring as
I type from Rotterdam).  Perhaps some appropriate beverages will lead to
rough consensus.

]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [