Re: [Rats] New RATS Architecture document

[Laurence Lundblade <[e-mail]>]

Below...

> On Oct 7, 2019, at 3:06 PM, Henk Birkholz <[e-mail]> wrote:
> 
> On 07.10.19 23:02, Giridhar Mandyam wrote:
> ...
>> -Giri Mandyam
>> a) I have asked the editors twice on the mailing lists for a justification as to why this is a standards track draft and not an informative one.  I have not received an answer, so I assume that there is no reason.  Note that comparable documents such as the TEEP architecture document and SUIT architecture document are informative.
> 
> In order to enable interoperability, a very tight scope of normative prerequisites is imposed on the architectural constituents of RATS by the architecture I-D in the Normative Prerequisite section (that uses BCP14 requirement notation).
> 
> Additionally, the architecture I-D of the "other" WG that is concerned with security posture of ToE - the SACM WG - is an example for also not being an informative I-D.
> 
> As far as I can see the normative prerequisites do not conflict with EAT, but support the architectural parts of EAT (which move into the RAT architecture I-D in any case).

The core question is whether the architecture doc really needs to be normative or not. Would EAT or Yang Model or such suffer if it was not? Does the definition of “entity” or “attester” or “verifier” need to be normative? 

I don’t have a strong opinion, but lean towards informational. CWT and JWT don’t have an architecture document, not even an informational one.

I do have a strong opinion that IETF should not set security requirements on internal of the implementation on a device. This was one of my core objections to use of the term “root of trust”. Henk, it seems like you are suggesting IETF try to set requirements when you say “security posture of ToE”. I think imposing implementation requirements belongs in certification programs run by organizations with the needed legal and financial structure. I don’t think IETF has this structure.

I thus oppose normative status if it based on MUSTs about the implementation like MUST have a protection boundary or MUST defend against side channels.

(That said, I’m fine with us defining claims that describe such security characteristics of the implementation).

LL