Subject: Re: [Rats] New RATS Architecture document

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 7 Oct 2019 21:02:58 +0000

I have read through the latest version of the document.  At this time I do not think this document is ready to be the RAts architecture specirfication, and would object to its adoption as a Working Group draft.  I do believe the group needs an architecture document, however.  So if the editors can address my primary concern - a) below -  I would be happy to withdraw my objection.

-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.

b)  "... this document provides normative guidance how to use, create or adopt network protocols that facilitate RATS".  So in the context of EAT, does this mean that guidance provided in this document supersedes the EAT, CWT, and JWT specifications?

b)  "... trustworthiness claims are accompanied by a proof of veracity.  Typically, this proof is a cryptographic expression such as a digital signature or a message digest".  This is a misleading statement, as it could be interpreted to cover self-signing (see [3] for example), and I don't believe self-signing conveys any indication of trustworthiness.

c) As per h) of my previous review [4], I still cannot figure out how the concept of delegated attestation (e.g. Sec. 5.4 of [5]) would fit into this architecture.  For an informational document, it may not be strictly necessary to specify an architecture that can support delegated attestation since an informational document would likely not be expected to cover all scenarios.  Since this is being proposed as a normative specification however, we should ensure that it does not disallow what could be common remote attestation deployments.

For instance, as per the diagram in Figure 1, all evidence must be conveyed directly to the verifier and the verifier in turn produces "attestation results" to the RP.  But "attestation results" are the "output from the appraisal of Evidence, Known-Good-Values and Endorsements".  I take this to mean that attestation results cannot be evidence themselves.  However, the delegated attestation model in [5] allows for the appraiser (approximately equivalent to the RP as per the RATS architecture doc) to compose "separate layered or orthogonal attestations, involving different proxies, in order to make a judgment".

As per Sec. 4.4 RATS Principals, the multiplicity property may allow for multiple verifiers to take on the role of attestation proxies.  But multiplicity explicitly calls out that the instances of the principals take on the "same RATS roles".  If there are multiple proxies, then it seems that they would be assessing different subsets of evidence and therefore would be occupying different roles.  

d) RATS roles:  composition:  "RATS Principals possessing different RATS Roles can be combined in to a singleton ...".  I can understand some aspects of this property, e.g. combining the RP and Verifier.  But why would an attester and/or asserter be combined with a verifier and RP?  Do you know of an example? 

f) {Sorry to jump back}  Sec. 3.1.  "A Computing Environment with the capability of remote attestation ... is separate from other Attested Computing Environments (about which attestation evidence is created ...".  I could not tell if this definition allowed for solutions such as Android SafetyNet [6], where the rich execution environment (REE) is producing evidence about itself.  Is the intention of the RATS Architecture spec that such self-attestations not be considered valid for remote attestation?

g) Sec. 3.2.  "The RATS architecture anticipates recursive trustworthiness properties and the need for termination".   What is being terminated in this context?

h) Sec. 3.2.  nit.  "For example, design reviews, manufacturing process audits and physical security." This is not a complete sentence.

i)  Sec. 3.3.  "RATS architecture defines attestation Roles ..., the messages they exchange, ...".  Don't specifications such as EAT already define messaging in part?  If so, what would the RATS architecture be defining in addition?  

[1] https://datatracker.ietf.org/doc/draft-ietf-teep-architecture/. 
[2] https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/. 
[3]  https://www.w3.org/TR/webauthn/#self-attestation. 
[4] https://mailarchive.ietf.org/arch/msg/rats/9iIrnD9YixKCuwOGKtvGZIzd_bU. 
[5] J. Guttman et al.  “”Attestation:  Evidence and Trust”.  MITRE Technical Report MTR080072.  March 2008.  https://www.mitre.org/sites/default/files/pdf/07_0186.pdf. 
[6] https://www.w3.org/TR/webauthn/#android-safetynet-attestation. 

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Giridhar Mandyam
Sent: Tuesday, September 10, 2019 9:29 AM
To: [email-masked]
Subject: Re: [Rats] New RATS Architecture document

-------------------------------------------------------------------------
CAUTION: This email originated from outside of the organization.
-------------------------------------------------------------------------

Henk and other editors of the architecture doc,

I appreciate the effort put into this latest revision, and I will review it with a fresh eye. 

I do have one overarching question:  why is this document listed as 'Standards Track' (as opposed to 'Informational')?  I had expressed my concerns about this in an earlier review of the doc:  https://mailarchive.ietf.org/arch/msg/rats/9iIrnD9YixKCuwOGKtvGZIzd_bU. 

Since the editors' team is composed of experienced IETF'ers, I assume that there are solid reasons for doing so.  If you all have stated them before, I hope you do not mind me requesting that you lay out your reasons again because I seemed to have missed it.

-Giri

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Henk Birkholz
Sent: Tuesday, September 10, 2019 6:13 AM
To: [email-masked]
Subject: [Rats] New RATS Architecture document

-------------------------------------------------------------------------
CAUTION: This email originated from outside of the organization.
-------------------------------------------------------------------------

Hi all,

we created a fully revised architecture document that maps and represents the state of the current discussion and the material presented at the last IETF meeting.

The current Editor's version can be found here:

> https://ietf-rats.github.io/draft-birkholz-rats-architecture/draft-bir
> kholz-rats-architecture.html

We will submit a new version the day after the RATS virtual interim.

TL;DR
Below you can find a list of essential changes & a list of action items still to be addressed.

This version of the RATS Architecture document:

* does not define or uses the terms "root(s) of trust" (RoT) or "Trust Anchor" (TA) at the moment. (Note: It is a fact that the Asserter Role _is_ a TA for the Verifier Role and that an Attester Role _could_ rely on RoTs. But - this content will not go into the main body of this document),

* does define RATS Roles, Messages, and Principals formerly known as "Actors" (borrowing heavily from ABLP),

* provides an even more "base" interaction model diagram for the RATS Roles than presented in the last IETF meeting slide deck:

> https://datatracker.ietf.org/meeting/105/materials/slides-105-rats-ses
> sb-rats-architecture-interaction-model-challange-response-yang-module-
> information-module-00.pdf

* introduces a framework for "level of confidence" in the trustworthiness of an Attester and the endorsement of the protection characteristics of its "Attesting Computing Context", allowing for other entities to use this framework and fill it with, e.g., openly defined levels of confidence metrics,

* is not based on the primitive of "trust" but the concept of "trustworthiness" as illustrated by the RATS charter,

* simplifies the definitions of Attester and Verifier that seemed to have caused some unfortunate confusion following the proposal of Giri and starting with commonly-accepted definitions and then justify why they may need to be modified,

* differentiates between the Attesting Computing Environment and the Attested Computing Environment better, which both are components of an Attester,

* uses the "Claim" concept as a building block to compose Evidence, Known-Good-Values and Endorsements. Conversely, the "Assertion" concept is dropped in this proposal (as initially suggested by Laurence, IIRC?). 
(Note: this was done to simplify the discussion about the information model. Please also note: Due to the {J|C}WT definition of "Claim", a key/value pair is implied, which is already a data model decision and not mandated by an information model), and

* analogously, now uses the term Known-Good-Values instead of Attestation Assertions.

For future versions the authors intent:

* to elaborate on the use of RATS Principals, including more exemplary 
diagrams of RATS Role composition and interaction between RATS 
Principals based on the use case document (and by that address a unified 
mapping to TEEP, RIV, and models that use EAT),

* to shift some of the focus on technical-trust as proposed by Thomas. 
(the Endorsements provided by an Asserter are a first step into that 
direction),

* still not to define the roots of trust terms nor invent new words for 
them :) But - start to reference them on a minimal level and define a 
base set of primitives they can provide in order to describe what they 
actually are and can do in the context of RATS as proposed by Ira, Simon 
and Thomas,

* to introduce and define a concise scope for layered attestation, 
addressing, e.g., the staging of Computing Environments and the 
(un-)availability of an Attesting Computing Environment at certain 
points of time, or, another example given, addressing the 
differentiation of an attested boot sequence of an Attester and an 
Attester running TEEs or rich systems for years,

* to address the change of Roles of a Principal over time as proposed by 
Ian,

* to move the remaining architectural sections in the EAT draft into the 
RATS Architecture draft, and

* to shift some of the focus on the out-of-band trust establishment in 
order to illustrate a coherent RATS ecosystem (e.g. the provisioning of 
key material is not include in the "base diagram" anymore for now - this 
will be more elaborated on in future section of the architecture).

Viele Grüße,

Henk

_______________________________________________
RATS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rats
_______________________________________________
RATS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rats

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 8 Oct 2019 00:06:04 +0200

Hi Giri,
hi list,

please find comments and replies in-line.

> I have read through the latest version of the document.  At this time I do not think this document is ready to be the RAts architecture specirfication, and would object to its adoption as a Working…

Does that mean the document is not ready for adoption because it is 
intended to be standards track or does this mean in order to be 
standards track there are things missing or wrong?

> 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 the…

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).

> b)  "... this document provides normative guidance how to use, create or adopt network protocols that facilitate RATS".  So in the context of EAT, does this mean that guidance provided in this docu…

It complements EAT with corresponding definitions. I do not see how it 
would be possible to supersede CWT or JWT with respect to remote 
attestation procedures. That seems to a totally different context or am 
I missing something very obvious here?

> b)  "... trustworthiness claims are accompanied by a proof of veracity.  Typically, this proof is a cryptographic expression such as a digital signature or a message digest".  This is a misleading…

While in a given scope, putting trust in self-signing can absolutely 
warranted, I think, I also think that was not the intended background 
for that text passage. Will be fixed by elaborating on that.

Self-signing (while not being a signing fool due to, e.g., missing key 
semantics), should be further discussed though. Again, this text was not 
phrased with self-signing in mind, I think.

> 
> c) As per h) of my previous review [4], I still cannotAndroid Key Attestation figure out how the concept of delegated attestation (e.g. Sec. 5.4 of [5]) would fit into this architecture.  For an informational document, it may not be strictly necessary to specify an architecture that can support delegated attestation since an informational document would likely not be expected to cover all scenarios.  Since this is being proposed as a normative specification however, we should ensure that it does not disallow what could be common remote attestation deployments.

Agreed, the text is lacking in this regard. Every proposed text with 
respect to "Android Key Attestation" is welcomed. We did the best we 
could based on the use cases I-D.

> For instance, as per the diagram in Figure 1, all evidence must be conveyed directly to the verifier and the verifier in turn produces "attestation results" to the RP.  But "attestation results" ar…

Figure 1 is the most simple example. We are already working on moving 
that to section 1.1. It is also not using normative language. No RATS 
message must move exactly along those edges, as there can be various 
other ways to compose these workflows (e.g. Dave's work-flows).

> As per Sec. 4.4 RATS Principals, the multiplicity property may allow for multiple verifiers to take on the role of attestation proxies.  But multiplicity explicitly calls out that the instances of…

"Same role" does not imply "same task/duty". It is a class of duties. 
E.g. appraisal of evidence can be split into multiple RATS principals, 
all taking on the Verifier Role, but appraising different portions of 
the evidence. The current phrasing seems to be lacking here - this 
should be more clear, if it reads like "different subsets of evidence 
require different roles with respect to appraisal of evidence". That is 
most certainty not the intent.

> d) RATS roles:  composition:  "RATS Principals possessing different RATS Roles can be combined in to a singleton ...".  I can understand some aspects of this property, e.g. combining the RP and Ver…

The Opal Storage Specification might be a good example. And RIV is 
another use case, where this can be the case, I think.

> f) {Sorry to jump back}  Sec. 3.1.  "A Computing Environment with the capability of remote attestation ... is separate from other Attested Computing Environments (about which attestation evidence i…

The definition of attestation in 
[https://www.w3.org/TR/webauthn/#attestation] states: it "is employed to 
attest to the provenance of an authenticator and the data it emits". 
While this is very authentication-centric, first of all, your reference 
[6] also states that the Android SafetyNet Attestation Statement Format: 
"does not provide information regarding provenance of the authenticator 
and its associated data". As a result "platform-provided authenticators 
SHOULD make use of the Android Key Attestation when available, even if 
the SafetyNet API is also present."

As "statement" in that context seems to be most semantically related to 
what "Claims" are in RATS, it seems that actually - no, that does not 
seem to be evidence, but claim sets. In combination with Android Key 
Attestation, these WebAuth statements seem to become evidence.

But I am not an expert on authentication-centric attestation statements.

> g) Sec. 3.2.  "The RATS architecture anticipates recursive trustworthiness properties and the need for termination".   What is being terminated in this context?

If no attesting computational environment can create believable evidence 
about a system component in a hierarchy of system components in, e.g., a 
composite device - that is a point where recursive trustworthiness 
properties terminate (and external endorsement are required). Ned might 
be able to provide a better example.

> h) Sec. 3.2.  nit.  "For example, design reviews, manufacturing process audits and physical security." This is not a complete sentence.

This is not a complete sentence. Will be fixed.

> i)  Sec. 3.3.  "RATS architecture defines attestation Roles ..., the messages they exchange, ...".  Don't specifications such as EAT already define messaging in part?  If so, what would the RATS ar…

That is defined in the section RATS messages.

> [6] https://www.w3.org/TR/webauthn/#android-safetynet-attestation.

IHTH as start!

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 8 Oct 2019 00:16:20 +0200

Hi Giri,

I also want to apologize. We discussed this a lot, but still managed 
somehow not to create an action item out of your question... Sorry!

Viele Grüße,

Henk

On 07.10.19 23:02, Giridhar Mandyam wrote:
> 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.

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 7 Oct 2019 22:32:01 +0000

Hi Henk,

Thanks for the quick response.  

I will focus on the standards-track versus informational aspect of the document.  For the RAts chairs, please plan on addressing this topic in tomorrow's virtual meeting.  

> Does that mean the document is not ready for adoption because it is intended to be standards track or does this mean in order to be standards track there are things missing or wrong?

I believe the document should be informational.  I have not identified any aspect of the current document which corresponds to an interoperable and testable specification.  For instance - there are no protocols being defined, fixed message formats, or mandatory verification procedures. 

> 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 use BCP14 requirement notation).

So does this mean that any RAts deployment that does not strictly conform with the architecture outlined in this document would be considered non-compliant?  I hope this architectural model is sufficiently broad to cover all the corner cases then.  So far in what I've observed in my review, I am not sure that will be an easy task.

>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.

And I cannot understand why the SACM architecture is not informational either.  I do on the other hand understand why the WebRTC sec arch document (https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20) is normative - there is an extension of SDP (https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20#section-5).

>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 architectural aspects of EAT will certainly move into this doc, but they are non-normative - see Sec. 1.3 of https://www.ietf.org/id/draft-ietf-rats-eat-01.txt. Note the introductory text:  " At least the following three participants exist in all EAT operating models.  Some operating models have additional participants."

-Giri

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Henk Birkholz
Sent: Monday, October 7, 2019 3:06 PM
To: Giridhar Mandyam <[email-masked]>; [email-masked]
Subject: Re: [Rats] New RATS Architecture document

Hi Giri,
hi list,

> I have read through the latest version of the document.  At this time I do not think this document is ready to be the RAts architecture specirfication, and would object to its adoption as a Working…

Does that mean the document is not ready for adoption because it is intended to be standards track or does this mean in order to be standards track there are things missing or wrong?

> 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 the…

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).

> b)  "... this document provides normative guidance how to use, create or adopt network protocols that facilitate RATS".  So in the context of EAT, does this mean that guidance provided in this docu…

It complements EAT with corresponding definitions. I do not see how it would be possible to supersede CWT or JWT with respect to remote attestation procedures. That seems to a totally different context or am I missing something very obvious here?

IHTH as start!

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 8 Oct 2019 00:41:40 +0200

I tried to be as quick as possible - hence the typos (I seem to be 
missing a lot of "be"s...).

A document that uses normative requirements terminology is standards 
track. Only one section of this I-D uses these - the authors tried not 
to be over-perscriptive, but these are quite essential in order to 
enable basic interoparbility between different solutions. As we cannot 
go through all open issues the authors were able to collected thanks to 
the replies on the list (and thank you all for all the great feedback) 
tomorrow, I think this is one of the issue we can discuss. If you could 
vet the one place where normative language is used for tomorrows meeting 
and highlight the (sub-)issues in there - that would be great!

Viele Grüße,

Henk

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Mon, 7 Oct 2019 23:10:40 +0000

On Tue, Oct 08, 2019 at 12:41:40AM +0200, Henk Birkholz wrote:
> 
> A document that uses normative requirements terminology is standards track.
>

I just searched backwards for the most recent informational document
and I found RFC (8649) and it violates this rule. RFC 7921 is
informational and has "Architecture" in its title and uses RFC 2119
language as well. So if this rule exists, the IETF is doing pretty
bad following it. So where is the the rule defined?

The question whether a document is standards-track should follow from
its content (is there material that is normative for creating
interoperable implementations?) and not from specific keywords used to
write this content down (or other formal aspects).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 8 Oct 2019 01:21:33 +0200

Hm.. if I use requirement notation and not include the BCP14 
boilerplate, that is an idnit, because you have to include the 
boilerplate then. And BCP14 is referring to standards track documents 
and not informational documents.

I've never questioned that line of thought before, tbh. There are maybe 
some individuals subscribed that can clarify this easily?

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 8 Oct 2019 01:34:08 +0200

Just checked BCP14 again. "Standards track document" was replaced by 
"IETF documents". And wrt "when the words are in all capitals" it also 
says both "a lot of normative text does not use them and is still 
normative" and then again "when these words are not capitalized, they 
have their normal English meanings and are not affected by this 
document". I am not entirely sure what to take from this, but at the 
very minimum it says that all IETF documents can make use the 
well-defined semantics of words that are in all capitals.

On 08.10.19 01:21, Henk Birkholz wrote:
>>> track.

---

From: Dave Thaler <[email-masked]>
Date: Mon, 7 Oct 2019 23:52:00 +0000

It's not a rule.   

There's Experimental protocol RFCs that use normative requirements.
There's Informational protocol RFCs (especially in the Independent stream), typically documenting pre-existing (non-IETF) protocols, that use normative requirements.
There's BCP RFCs that use normative requirements.

There's no requirement that they only be used in standards track docs.

That said, if a doc is meant to be informational (not document a protocol like in the non-IETF protocol case above),
then it's good to not use normative language.  They're best used when the language can actually be tested.

Sometimes they're used to refer to writers of other documents (e.g., any document proposing an extension
MUST include security considerations.) and if used in that sense they might appear in an arch doc.
But generally I wouldn't use them in an arch doc case where you're referring to what an implementer does.

Dave

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Schönwälder, Jürgen
Sent: Monday, October 7, 2019 4:11 PM
To: Henk Birkholz <[email-masked]>
Cc: [email-masked]; Giridhar Mandyam <[email-masked]>
Subject: Re: [Rats] New RATS Architecture document

> A document that uses normative requirements terminology is standards track.

I just searched backwards for the most recent informational document and I found RFC (8649) and it violates this rule. RFC 7921 is informational and has "Architecture" in its title and uses RFC 2119 language as well. So if this rule exists, the IETF is doing pretty bad following it. So where is the the rule defined?

The question whether a document is standards-track should follow from its content (is there material that is normative for creating interoperable implementations?) and not from specific keywords used to write this content down (or other formal aspects).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&amp;data=02%7C01%7Cdthaler%40microsoft.com%7Cc0c57aa8221942b8992608d74b7b9a35%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637060866573277087&amp;sdata=bgWPIetMPeMz3p1s6hOtBecFlkVwaDz59il5RoQeyWI%3D&amp;reserved=0>

_______________________________________________
RATS mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7Cdthaler%40microsoft.com%7Cc0c57aa8221942b8992608d74b7b9a35%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637060866573277087&amp;sdata=8v4MjrNl9NR2gMjdW%2Bz9z12cVl13rHehbpBt5D2Xrd4%3D&amp;reserved=0

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 7 Oct 2019 18:18:25 -0700

Below...

> On Oct 7, 2019, at 3:06 PM, Henk Birkholz <[email-masked]> wrote:
> 
> ...
> 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).
> 

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Oct 2019 10:19:19 +0200

On Oct 8, 2019, at 01:21, Henk Birkholz <[email-masked]> wrote:
> 
> Hm.. if I use requirement notation and not include the BCP14 boilerplate, that is an idnit, because you have to include the boilerplate then. And BCP14 is referring to standards track documents and not informational documents.
> 
> I've never questioned that line of thought before, tbh. There are maybe some individuals subscribed that can clarify this easily?

These individuals are called ADs :-)

I don’t think the way the IETF handles this is particularly logical, so it doesn’t quite work to make arguments entirely based on logic here.  The really important question is how is the document intended to be used.

For something like an architecture document, the document will not be used standalone, but in conjunction with a protocol specification that provides the details.  If the statements in the architecture document are necessary components to correctly interpret the protocol specification, the latter needs to make a normative reference to the architecture document.  If the architecture document is just an informational document, it needs to be blessed to be on the “downref list” before this can be done.

I don’t understand why we are creating informational documents that MUST be put on the downref list before they can be used.  But, apparently, we do, all the time.  I think it is more appropriate to go for standards track if the intention is indeed normative as a component of the protocol specification.

What is the difference?  Standards-Track documents need more IESG votes (and thus more IESG work!) than informational documents.  Putting a document that contains components of a protocol specification through the light-weight informational process and then go for downref right away sounds sneaky to this process connoisseur.  But, apparently, it can be done.

Now ask the AD :-)

Grüße, Carsten