Re: [Rats] Use case -> architecture document

Laurence Lundblade <lgl@island-resort.com> Wed, 16 October 2019 03:19 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 7253512084C for <rats@ietfa.amsl.com>; Tue, 15 Oct 2019 20:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 i2CtzenaN6cR for <rats@ietfa.amsl.com>; Tue, 15 Oct 2019 20:19:46 -0700 (PDT)
Received: from p3plsmtpa11-02.prod.phx3.secureserver.net (p3plsmtpa11-02.prod.phx3.secureserver.net [68.178.252.103]) (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 A9E10120848 for <rats@ietf.org>; Tue, 15 Oct 2019 20:19:46 -0700 (PDT)
Received: from [192.168.1.76] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id KZqii9At09tmPKZqjiubW0; Tue, 15 Oct 2019 20:19:46 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <512A0FF5-48C8-40E5-B6FB-B4EB91EE7F22@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D17ED98C-F5D6-48AF-98A9-BF0ED78ABEBE"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 15 Oct 2019 20:19:43 -0700
In-Reply-To: <1571161950747.36630@mit.edu>
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, =?utf-8?B?IlNjaMO2bnfDpGxkZXIsIErDvHJnZW4i?= <J.Schoenwaelder@jacobs-university.de>, Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>, "rats@ietf.org" <rats@ietf.org>
To: Thomas Hardjono <hardjono@mit.edu>
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> <20191015154500.ruv2ie36hsxfb3qq@anna.jacobs.jacobs-university.de> <a9b6c097-c8c4-1c88-374d-7d07ea34e626@sit.fraunhofer.de> <1571161950747.36630@mit.edu>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfH7oH2RveuX2+h56BneVei63+iS8us3D5Cu2Z2K7bwpuPLjTb8Er3H+8iVtibioqT3eGiLj1zk1PPKiTUeC+c63+crXZLs/cEr3/7tQEY9hVHkrpxnGI FEI8mtlHXiWA8UbdqsvTFcEkq/1fdM39IKLohN6/oyoDk9WpsflhI3srcZaLkFAhtJjU/fClXuUajcPU8fTT8L/XtFU11XV4iLNBojWfCr0x47lGkKFVKR/O clBIzcizpx6uT0+fBqMXY0KG5BfQYJZ91l46gJDGPRRoSJmSOd5Ye1c22eMZAEhxY9zcKR9FBAGmOknzqunaUNq7Dq9eEyFYimBGO54V4YkszejgyJv0qnIt LdkDReqM
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/6m3Rf94cPOoYi1ouCa9k89SqsS0>
Subject: Re: [Rats] 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 03:19:49 -0000

I don’t see Dave’s draft as just network endpoint assessment. Other use cases are mentioned and they fit into the system described. I also don’t see it as particularly subordinate to Henk’s architecture. 


I don’t think it’s been made official, but a number of us are considering profiles to be subordinates of the EAT document. They would specify:
Crypto algorithms and key sizes
End-end scheme for finding the verification key
Claims that are mandatory
Claims that are disallowed

I think this type of profile is very necessary. 

(I’m not familiar with how OAuth used profiles, but have assumed it was similar to what I just described)

LL



> On Oct 15, 2019, at 10:52 AM, Thomas Hardjono <hardjono@mit.edu> wrote:
> 
> 
> I would prefer for RATS WG to continue with the current architecture draft (draft-birkholz-rats-architecture-02) and develop it further for many reasons (including that so much work and time has been put into this architecture draft).
> 
> Dave's new draft (draft-thaler-rats-architecture-00) well written, and identifies a very good problem scenario being solved.
> 
> One way to solve this dilemma of drafts is to use the term "profiles" for more specific/narrower problems being solved.
> 
> So if draft-birkholz could be the top level architecture document, then draft-thaler could be a profile that addresses a given problem scenario (e.g. network endpoint assessment).
> 
> This profiling approach is also used with great success in other WGs (e.g. OAuth WG with OAuth and UMA profile), and also in other standard organizations (e.g. SAML-WebSSO is a profile of SAML-core).
> 
> This would also allow other profile drafts in RATS to be developed beyond network endpoint assessment.
> 
> 
> -- thomas --
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>