Subject: [Rats] Use case -> architecture document

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 8 Oct 2019 07:24:50 -0400

Hello!

I read through the latest version of the ‘use case’ document yesterday and
found it very easy to read and understand, meaning I think it is written
well and could be easily understood by many without having to climb up a
learning curve.

First, this could be a very useful document to register claims for the use
cases.

Second, if the workflow for the passport and background check were added
and put in terms of the open trust protocol v2 from TEEP, we have a fairly
nice architecture document that’s easy to read and may gain adoption.  The
workflows cover the various interactions between roles and TEEP has
actively broken up OTrP in v2 to accommodate using EAT tokens, this
would help create that link and make it very clear.

The other thing I like about the use case document and think we should
expand on is the references to other work items.  This makes it an
architecture document that maps out the full plan of the WG.  One like that
was extremely well received by all the ADs that don’t like
informational/helpful documents.

I’m a bit nervous with the terminology being defined and would love to see
something like this that’s simplified and more easily adoptable.

I appreciate the work done to improve the architecture document, but I do
think the structure changes to the use case document as suggested could
result in an easier to understand (and therefore easier to adopt) document.

While the architecture document is more readable, I think we can do
better.  Adoption is important and our timeliness matters a lot for this
work.  EATs can be used for may use cases with OTrPv2, so let's keep it as
simple as we can.

Thoughts are appreciated.

Best regards,
Kathleen--

Best regards,
Kathleen

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 Oct 2019 14:14:00 +0000

Personally, I like that idea and would be happy to help if the WG goes in that direction.

Dave

From: RATS <[email-masked]> On Behalf Of Kathleen Moriarty
Sent: Tuesday, October 8, 2019 4:25 AM
To: [email-masked]
Subject: [Rats] Use case -> architecture document

Hello!

I read through the latest version of the ‘use case’ document yesterday and found it very easy to read and understand, meaning I think it is written well and could be easily understood by many without having to climb up a learning curve.

First, this could be a very useful document to register claims for the use cases.

Second, if the workflow for the passport and background check were added and put in terms of the open trust protocol v2 from TEEP, we have a fairly nice architecture document that’s easy to read and may gain adoption.  The workflows cover the various interactions between roles and TEEP has actively broken up OTrP in v2 to accommodate using EAT tokens, this would help create that link and make it very clear.

The other thing I like about the use case document and think we should expand on is the references to other work items.  This makes it an architecture document that maps out the full plan of the WG.  One like that was extremely well received by all the ADs that don’t like informational/helpful documents.

I’m a bit nervous with the terminology being defined and would love to see something like this that’s simplified and more easily adoptable.

I appreciate the work done to improve the architecture document, but I do think the structure changes to the use case document as suggested could result in an easier to understand (and therefore easier to adopt) document.

While the architecture document is more readable, I think we can do better.  Adoption is important and our timeliness matters a lot for this work.  EATs can be used for may use cases with OTrPv2, so let's keep it as simple as we can.

Best regards,
Kathleen--

Best regards,
Kathleen

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Wed, 9 Oct 2019 10:53:40 +0000

Hi Kathleen,

I am very concerned with this new direction and I strongly object.

Current architecture draft goes through a lot discussions and reaches many consensus. Right now, it really helps IETF (Teep for example), FIDO, TCG and many others. The only issues are on readability, the standards track and the completeness (e.g., passport and background check are still missing). It is an very good document and correct terminology is very important for remote attestation.

About use cases document, Its goal is just to clarify a sample list of scenarios that remote attestation can apply to and then deduce the requirements and the following concrete protocol drafts. It is not fit to be an architecture.

The current architecture is too important for telecom and network equipment vendors and service providers. I have strong doubts that current EAT and OTrPv2 alone is suitable for the (virtualized) network infrastructure situation.

B.R.

Frank

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

发件人: RATS [mailto:[email-masked]] 代表 Kathleen Moriarty
发送时间: 2019年10月8日 19:25
收件人: [email-masked]
主题: [Rats] Use case -> architecture document

Hello!

Best regards,
Kathleen--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 9 Oct 2019 07:31:12 -0400

Hi Frank,

Thank you for voicing your concern.  I think some may hold off until the
updates are provided, but please do voice your opinions.  I agree that this
work is too important and as such, readability is a high priority.  If you
read through the TEEP and SUIT architecture drafts, they are quite easy to
follow and understand.  That is critical for wide spread adoption.  We may
be able to find a balance, but I think this exercise may speed progress as
we have not decided to adopt this draft yet as a working group item.

As it stands, the use case document is not an architecture document, but it
could be shaped as such and I'd really like to see if we can do that in
short order to have a comparison prior to an adoption call.

Best regards,
Kathleen

On Wed, Oct 9, 2019 at 6:53 AM Xialiang (Frank, Network Standard & Patent
Dept) <[email-masked]> wrote:

> Current architecture draft goes through a lot discussions and reaches many
> consensus. Right now, it really helps IETF (Teep for example), FIDO, TCG
> and many others. The only issues are on readability, the standards track
> and the completeness (e.g., passport and background check are still
> missing). It is an very good document and correct terminology is very
> important for remote attestation.
>
>
>
> About use cases document, Its goal is just to clarify a sample list of
> scenarios that remote attestation can apply to and then deduce the
> requirements and the following concrete protocol drafts. It is not fit to
> be an architecture.
>
>
>
> The current architecture is too important for telecom and network
> equipment vendors and service providers. I have strong doubts that current
> EAT and OTrPv2 alone is suitable for the (virtualized) network
> infrastructure situation.
>
>
>
> B.R.
>
> Frank
>
>
>
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender
> by phone or email immediately and delete it!
>
>
>
> *发件人:* RATS [mailto:[email-masked]] *代表 *Kathleen Moriarty
> *发送时间:* 2019年10月8日 19:25
> *收件人:* [email-masked]
> *主题:* [Rats] Use case -> architecture document
>
>
>
> Hello!
>

-- 

Best regards,
Kathleen

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 9 Oct 2019 13:55:57 +0200

Hi Kathleen,
hi list,

it would help everybody, if you could explicitly highlight what the 
exact issues wrt readability in the current architecture I-D are - 
always in comparison with the use-case I-D, if it is doing a better job 
in that part?

Jürgen provided a good example of what he found confusing as a first 
time reader - and that was really helpful and is resulting in ongoing work.

Please mind, not everything is fleshed out in the architecture (e.g. the 
workflows derived from the use-cases). The plan was to aim for a stable 
nucleus, address the issues raised by the list, go through adoption, and 
finish the document via the issue tracker in a structured process.

In summary, without an actual understanding why you (or others!) think 
the document is still hard to read, there is no way of compare 
readability later on also. It would be really good to get more precise 
feedback on that.

Viele Grüße,

Henk

On 09.10.19 13:31, Kathleen Moriarty wrote:
> updates are provided, but please do voice your opinions.  I agree that 
> this work is too important and as such, readability is a high priority.  
> If you read through the TEEP and SUIT architecture drafts, they are 
> quite easy to follow and understand.  That is critical for wide spread 
> adoption.  We may be able to find a balance, but I think this exercise 
> may speed progress as we have not decided to adopt this draft yet as a 
> working group item.
> 
> As it stands, the use case document is not an architecture document, but 
> it could be shaped as such and I'd really like to see if we can do that 
> in short order to have a comparison prior to an adoption call.
> 
> Best regards,
> Kathleen
> 
> On Wed, Oct 9, 2019 at 6:53 AM Xialiang (Frank, Network Standard & 
> Patent Dept) <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Kathleen,____
> 
>     __ __
> 
>     I am very concerned with this new direction and I strongly object.____
> 
>     __ __
> 
>     Current architecture draft goes through a lot discussions and
>     reaches many consensus. Right now, it really helps IETF (Teep for
>     example), FIDO, TCG and many others. The only issues are on
>     readability, the standards track and the completeness (e.g.,
>     passport and background check are still missing). It is an very good
>     document and correct terminology is very important for remote
>     attestation.____
> 
>     __ __
> 
>     About use cases document, Its goal is just to clarify a sample list
>     of scenarios that remote attestation can apply to and then deduce
>     the requirements and the following concrete protocol drafts. It is
>     not fit to be an architecture.____
> 
>     __ __
> 
>     equipment vendors and service providers. I have strong doubts that
>     current EAT and OTrPv2 alone is suitable for the (virtualized)
>     network infrastructure situation.____
> 
>     __ __
> 
>     B.R.____
> 
>     Frank____
> 
>     ____
> 
>     __ __
> 
>     This e-mail and its attachments contain confidential information
>     from HUAWEI, which is intended only for the person or entity whose
>     address is listed above. Any use of the information contained herein
>     in any way (including, but not limited to, total or partial
>     disclosure, reproduction, or dissemination) by persons other than
>     the intended recipient(s) is prohibited. If you receive this e-mail
>     in error, please notify the sender by phone or email immediately and
>     delete it!____
> 
>     __ __
> 
>     *发件人:*RATS [mailto:[email-masked]
>     <mailto:[email-masked]>] *代表 *Kathleen Moriarty
>     *发送时间:*2019年10月8日19:25
>     *收件人:[email-masked] <mailto:[email-masked]>
>     *主题:*[Rats] Use case -> architecture document____
> 
>     __ __
> 
>     Hello!
> 
>     I read through the latest version of the ‘use case’ document
>     yesterday and found it very easy to read and understand, meaning I
>     think it is written well and could be easily understood by many
>     without having to climb up a learning curve. ____
> 
>     __ __
> 
>     Second, if the workflow for the passport and background check were
>     added and put in terms of the open trust protocol v2 from TEEP, we
>     have a fairly nice architecture document that’s easy to read and may
>     gain adoption.  The workflows cover the various interactions between
>     roles and TEEP has actively broken up OTrP in v2 to
>     accommodate using EAT tokens, this would help create that link and
>     make it very clear.
> 
>     The other thing I like about the use case document and think we
>     should expand on is the references to other work items.  This makes
>     it an architecture document that maps out the full plan of the WG. 
>     One like that was extremely well received by all the ADs that don’t
>     like informational/helpful documents.
> 
>     I’m a bit nervous with the terminology being defined and would love
>     to see something like this that’s simplified and more easily
>     adoptable. ____
> 
>     __ __
> 
>     I appreciate the work done to improve the architecture document, but
>     I do think the structure changes to the use case document as
>     suggested could result in an easier to understand (and therefore
>     easier to adopt) document.____
> 
>     __ __
> 
>     better.  Adoption is important and our timeliness matters a lot for
>     this work.  EATs can be used for may use cases with OTrPv2, so let's
>     keep it as simple as we can.
> 
>     Kathleen-- ____
>     __ __
>     Best regards,____
>     Kathleen____
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 9 Oct 2019 13:00:16 +0000

Hi,

Given my current close-to-outsider position (I am afraid other more pressing issues have kept me much further away from RATS that I would have liked to), let me make a proposal in the hope this could synthesize both approaches. I agree with Frank it would be difficult to rewrite a document that has gone through a long process of consensus formation, and rebuilding that consensus with the additional goal of readability may become overly complicated. In that respect, I'd support Henk's comments regarding the identification of concrete ambiguities or statements that can be misinterpreted.

But, since I also acknowledge Kathleen concern on making the architecture well understandable and therefore applicable, I'd suggest we think of preparing a more readable document (or section if you prefer) in the form of describing application scenarios, clarifying how the general (and therefore complicated for novices) architecture can be used, and the assumptions required for that. That would not change the delicate consensus fabric in the whole architecture, making at the same time easier to understand where an how to use it.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 09/10/2019, 13:56, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Kathleen,
    hi list,

    Viele Grüße,

    Henk

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 9 Oct 2019 14:25:50 +0000

I have been interested in RATS for two reasons:

(1) The YANG model (for current needs)
Network operators are already asking for vendor independent ways for extracting router boot integrity measures.

(2) Consistent and precise architectural terms and roles (for our next needs)
I don't believe that it will be possible to explore issues in the WG without these formal constructs.  Such a document is needed for are discussions like:
 - when to use the passport model vs the background check, 
 - how to assemble a consolidated "Attester" security posture from cryptoprocessors on independent line cards, and 
 - how does a "Verifier" understand the relationship between the claims of physical and virtual components of an "Attester" 

I believe for (2), the current architecture draft is quite good.   While some wording tweaks wouldn't hurt, I certainly don't want to start over.  In fact I would prefer to see the architecture draft adopted.

Eric

> -----Original Message-----
> From: RATS <[email-masked]> On Behalf Of Diego R. Lopez
> Sent: Wednesday, October 9, 2019 9:00 AM
> To: Henk Birkholz <[email-masked]>; Kathleen Moriarty
> <[email-masked]>; Xialiang (Frank, Network Standard &
> Patent Dept) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Rats] Use case -> architecture document
> 
> Hi,
> 
> Given my current close-to-outsider position (I am afraid other more pressing
> issues have kept me much further away from RATS that I would have liked
> to), let me make a proposal in the hope this could synthesize both
> approaches. I agree with Frank it would be difficult to rewrite a document
> that has gone through a long process of consensus formation, and rebuilding
> that consensus with the additional goal of readability may become overly
> complicated. In that respect, I'd support Henk's comments regarding the
> identification of concrete ambiguities or statements that can be
> misinterpreted.
> 
> But, since I also acknowledge Kathleen concern on making the architecture
> well understandable and therefore applicable, I'd suggest we think of
> preparing a more readable document (or section if you prefer) in the form of
> describing application scenarios, clarifying how the general (and therefore
> complicated for novices) architecture can be used, and the assumptions
> required for that. That would not change the delicate consensus fabric in the
> whole architecture, making at the same time easier to understand where an
> how to use it.
> 
> Be goode,
> 
> --
> On 09/10/2019, 13:56, "RATS on behalf of Henk Birkholz" <rats-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>     Hi Kathleen,
>     hi list,
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el destinatario
> indicado, queda notificado de que la lectura, utilización, divulgación y/o
> copia sin autorización puede estar prohibida en virtud de la legislación
> vigente. Si ha recibido este mensaje por error, le rogamos que nos lo
> comunique inmediatamente por esta misma vía y proceda a su destrucción.
> 
> The information contained in this transmission is privileged and confidential
> information intended only for the use of the individual or entity named
> above. If the reader of this message is not the intended recipient, you are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this transmission
> in error, do not read it. Please immediately reply to the sender that you
> have received this communication in error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> destinatário, pode conter informação privilegiada ou confidencial e é para
> uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o
> destinatário indicado, fica notificado de que a leitura, utilização, divulgação
> e/ou cópia sem autorização pode estar proibida em virtude da legislação
> vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o
> comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 9 Oct 2019 14:50:07 +0000

Hi,

I did also look at the use cases document (I think -04) after going
through the architecture document and I must admit that I did not find
it too helpful to understand things better. I did not see anything
architectural in there either. I guess I will read the teep
architecture next and perhaps that helps me to get a better clue.

For people like me who are not deep into this technology yet, getting
used to the rather specific terminology and concepts is a certainly a
learning effort and I think the architecture document was on its way
to get terms well defined and sorted out. Some more examples or
explanations may help the reader further and I believe this can be
achieved.

/js

On Wed, Oct 09, 2019 at 01:55:57PM +0200, Henk Birkholz wrote:
> Hi Kathleen,
> hi list,
> 
> it would help everybody, if you could explicitly highlight what the exact
> issues wrt readability in the current architecture I-D are - always in
> comparison with the use-case I-D, if it is doing a better job in that part?
> 
> Jürgen provided a good example of what he found confusing as a first time
> reader - and that was really helpful and is resulting in ongoing work.
> 
> In summary, without an actual understanding why you (or others!) think the
> document is still hard to read, there is no way of compare readability later
> on also. It would be really good to get more precise feedback on that.
> 
> Viele Grüße,
> 
> Henk
> 
> 
> 
> 

-- 
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: Kathleen Moriarty <[email-masked]>
Date: Wed, 9 Oct 2019 12:03:36 -0400

I would rather see the architectural patterns come before the specific
terminology.  If you look through the slides from Dave's presentation at
our previous interim meeting, he laid out several architectural patterns
using the same language that is used in SUIT and TEEP.  It is desirable,
IMO, to begin with architectural patterns that can be used in necessary use
cases.  Additional architectural patterns may arise, but we have a nice
starting point.

See:
https://datatracker.ietf.org/meeting/interim-2019-rats-02/materials/slides-interim-2019-rats-02-sessa-teep-and-rats-alignment
It defines the passport, background check, and verifying relying party
architectural patterns for RATS.
It also provides an illustration of how the OTrP model for device state can
fold into each of those 3 RATS architectural patterns.

What Dave is planning to do is to write text describing these architectural
patterns.  It will likely be in the language similar to what's been used in
SUIT and TEEP as his slides match the terminology.

Attestation has countless use cases, and several known architectural
patterns to date.  The document would first define these patterns.  Then,
like SUIT, a high-level description of use cases could be included with
pointers to other future WG drafts that more fully define the use cases.
Any additional terminology that is necessary could then be added, but
keeping in mind that we do not want unnecessary terms.  If we start from
the models, it will be easier to maintain the scope and set of terms.  The
terms would come from the current document, but language may be adjusted as
needed.

The specific use case details that map claims could be in a later section
with the IANA section defining claims for use cases to be added to the CWT
and JWT registry.

I work for Dell and would like to be able to bring this work forward for
PoCs.  However, our teams (like many others) use pair programming.  This
means the 2 coders work as a team and in our model, they rotate to a new
project every 2 weeks.  This helps with innovation and other benefits.  If
each pairing team has a significant learning curve, a lot of time will be
wasted and the PoC would not make progress.

If the goal for service providers and others is to use this technology (as
is my goal), we need to make it something that is accessible to many.  The
developers at many organizations will use crypto libraries, but will not
necessarily be security people.  They will be starting from a point where
they do not have security specific language nor this very specific set of
terms that is being defined.  The simpler we can keep it, the better to
gain wider adoption.

I think if we step back and see what Dave does with the document to define
the architectural patterns, then we can decide how we merge content with
readability as a goal.

Best regards,
Kathleen

On Wed, Oct 9, 2019 at 10:50 AM Schönwälder, Jürgen <
[email-masked]> wrote:

> the

-- 

Best regards,
Kathleen

---

From: Ira McDonald <[email-masked]>
Date: Wed, 9 Oct 2019 12:15:14 -0400

Hi,

I am opposed to abandoning the current RATS architecture document.

Conflating architecture w/ use cases in one document doesn't make
sense to me.  Use cases collections (by their nature) should be able
to have loose ends and edge cases.  Architecture should instead have
coherence and some rigor about terminology and structure.

I'll be happy to see Dave Thaler's contributions on presentation and
organization.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
PO Box 221  Grand Marais, MI 49839  906-494-2434

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 9 Oct 2019 16:25:58 +0000

Kathleen,

I agree that these pattern (starting slide 10 on the deck you have
pointed to) would have helped me. (This was also reflected in my
review comment that the only figure that helped me was coming too
late.)  So yes, we need to improve the architecture document and it is
great if Dave can help with the pattern.

I agree that we need to keep the barrier to entry low.

/js

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 9 Oct 2019 18:37:30 +0200

Hi Kathleen,
hi list,

while I of course understand your point of "the simpler, the better", I 
am still a bit of at a loss, what the actual issue is. You are proposing 
a solution to a problem that I currently have not seen being described yet.

Maybe we should do things in order and describe the problem better first 
and then see how to resolve it inside the existing document?

That is basically the reason for my request to you on actual issues in 
my last comment. I understand the category of the problem "readability" 
and I assume analogously "comprehensibility", of course, but I think 
that is too vague to actually act on.

What you are describing with respect to workflow diagrams that is using 
the roles - Dave did already provided those and walked us through them 
for example at the first interim, and we are doing ASCII art on them 
currently.

In fact, that very first action item wrt what we are working on (well, 
we paralleled some other items, too) back in early September was:

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

So what am I hearing now is that Dave is now starting to do the exact 
same thing, with the exception of not using the terms defined in the 
architecture. Is that correct? I am still not sure what issues we are 
trying to address here.

Viele Grüße,

Henk

p.s. with respect to pair programming, I really hope that solutions 
drafts simplify that process the same way the first RATS YANG module 
does it today, already.

On 09.10.19 18:03, Kathleen Moriarty wrote:
> IMO, to begin with architectural patterns that can be used in necessary 
> use cases.  Additional architectural patterns may arise, but we have a 
> nice starting point.
> 
> See: 
> It also provides an illustration of how the OTrP model for device state 
> can fold into each of those 3 RATS architectural patterns.
> 
> What Dave is planning to do is to write text describing these 
> architectural patterns.  It will likely be in the language similar to 
> what's been used in SUIT and TEEP as his slides match the terminology.
> 
> patterns to date.  The document would first define these patterns.  
> Then, like SUIT, a high-level description of use cases could be included 
> with pointers to other future WG drafts that more fully define the use 
> cases.  Any additional terminology that is necessary could then be 
> added, but keeping in mind that we do not want unnecessary terms.  If we 
> start from the models, it will be easier to maintain the scope and set 
> of terms.  The terms would come from the current document, but language 
> may be adjusted as needed.
> 
> The specific use case details that map claims could be in a later 
> section with the IANA section defining claims for use cases to be added 
> to the CWT and JWT registry.
> 
> project every 2 weeks.  This helps with innovation and other benefits.  
> If each pairing team has a significant learning curve, a lot of time 
> will be wasted and the PoC would not make progress.
> 
> If the goal for service providers and others is to use this technology 
> (as is my goal), we need to make it something that is accessible to 
> many.  The developers at many organizations will use crypto libraries, 
> but will not necessarily be security people.  They will be starting from 
> a point where they do not have security specific language nor this very 
> specific set of terms that is being defined.  The simpler we can keep 
> it, the better to gain wider adoption.
> 
> I think if we step back and see what Dave does with the document to 
> define the architectural patterns, then we can decide how we merge 
> content with readability as a goal.
> 
> Best regards,
> Kathleen
> 
> On Wed, Oct 9, 2019 at 10:50 AM Schönwälder, Jürgen 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     <mailto:[email-masked]>
>      > > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      > >
>      > >     Hi Kathleen,____
>      > >
>      > >     __ __
>      > >
>     <mailto:[email-masked]>
>      > >     <mailto:[email-masked]
>     <mailto:[email-masked]>>] *代表 *Kathleen Moriarty
>      > >     *发送时间:*2019年10月8日19:25
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      > >     First, this could be a very useful document to register
>     claims for
>      > >     the use cases.
>      > >
>      > > [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 9 Oct 2019 13:33:01 -0400

Hi Henk,

> and then see how to resolve it inside the existing document?

I tried to provide extensive comments, but they were not considered and I
was asked by you to look at the new version again.  I spent over 2 days
trying to help, but I think to speed this work up, we need to do a pivot
and focus first on the architectural patterns.

> that is too vague to actually act on.

I tried to help...

> for example at the first interim, and we are doing ASCII art on them

As a reminder, we don't need ASCII art anymore, version 3 was released for
publishing.  If Dave contributes his pictures, we can use them.

In terms of how roles are discussed, I think that can be improved further.
Can we just wait and give Dave a chance to write up the text he has said he
would help with on this rather than trying to all do the same thing?

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

Not necessarily.  His work used terms in TEEP and SUIT.  Some of these
terms are defined int he current architecture document.  Once he has this
written, then merging again makes sense so that we can then get language
consistent and using what's been agreed upon to date. I think this will
actually speed up the work and adoption.  It will also lower the learning
curve.  You've done really good work and I would like the barrier to entry
lowered.  I would really like to see all of this be successful and don't
think this exercise will take much time, but do think it will be very
worthwhile.

I'd like to see this happen in a few steps as described in my last message.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 9 Oct 2019 16:09:42 -0400

Hello,

Henk expressed concern with my use of the word 'merge'.  By exploring this
new structure, I am not suggesting that we drop content.  It's a
restructure proposal and hopefully a way to make the document more
accessible.  I am not suggesting essential components be dropped, but would
like them described more clearly.  This may help reset the readability of
the document.  Obviously, the WG is who decides what gets adopted as a WG
item.  I'd also like to make sure the end result is something that is
easily adoptable by industry that are already moving forward with
proprietary solutions.  We should put our best foot forward to try to
influence and gain adoption.

Michael offered to look at the structures of the TEEP and SUIT architecture
documents and to see what might make sense here and will post to the list.

Best regards,
Kathleen

On Wed, Oct 9, 2019 at 1:33 PM Kathleen Moriarty <
[email-masked]> wrote:

> In terms of how roles are discussed, I think that can be improved
> further.  Can we just wait and give Dave a chance to write up the text he
> has said he would help with on this rather than trying to all do the same
> thing?
>
>

-- 

Best regards,
Kathleen

---

From: Guy Fedorkow <[email-masked]>
Date: Wed, 9 Oct 2019 23:41:11 +0000

Hi Henk,

    Do you think that the ‘readability’ concerns would be addressed if the architecture doc were to adopt a summary of some sort of the use-cases as part of its introductory material?  That would give a definition of the problem to be solved written in common language, so ordinary people could read it, followed by the more-carefully-defined terms, roles and procedures?

    /guy

From: RATS <[email-masked]> On Behalf Of Kathleen Moriarty
Sent: Wednesday, October 9, 2019 4:10 PM
To: Henk Birkholz <[email-masked]>; [email-masked]
Subject: Re: [Rats] Use case -> architecture document

Hello,

Henk expressed concern with my use of the word 'merge'.  By exploring this new structure, I am not suggesting that we drop content.  It's a restructure proposal and hopefully a way to make the document more accessible.  I am not suggesting essential components be dropped, but would like them described more clearly.  This may help reset the readability of the document.  Obviously, the WG is who decides what gets adopted as a WG item.  I'd also like to make sure the end result is something that is easily adoptable by industry that are already moving forward with proprietary solutions.  We should put our best foot forward to try to influence and gain adoption.

Michael offered to look at the structures of the TEEP and SUIT architecture documents and to see what might make sense here and will post to the list.

Best regards,
Kathleen

On Wed, Oct 9, 2019 at 1:33 PM Kathleen Moriarty <[email-masked]<mailto:kathleen.moriarty.ietf@gmail..com>> wrote:
Hi Henk,

On Wed, Oct 9, 2019 at 12:37 PM Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kathleen,
hi list,

I tried to provide extensive comments, but they were not considered and I was asked by you to look at the new version again.  I spent over 2 days trying to help, but I think to speed this work up, we need to do a pivot and focus first on the architectural patterns.

I tried to help...

As a reminder, we don't need ASCII art anymore, version 3 was released for publishing.  If Dave contributes his pictures, we can use them.

In terms of how roles are discussed, I think that can be improved further.  Can we just wait and give Dave a chance to write up the text he has said he would help with on this rather than trying to all do the same thing?

Not necessarily..  His work used terms in TEEP and SUIT.  Some of these terms are defined int he current architecture document.  Once he has this written, then merging again makes sense so that we can then get language consistent and using what's been agreed upon to date. I think this will actually speed up the work and adoption.  It will also lower the learning curve.  You've done really good work and I would like the barrier to entry lowered.  I would really like to see all of this be successful and don't think this exercise will take much time, but do think it will be very worthwhile.

Best regards,
Kathleen

Viele Grüße,

Henk

On 09.10.19 18:03, Kathleen Moriarty wrote:
> https://datatracker.ietf.org/meeting/interim-2019-rats-02/materials/slides-interim-2019-rats-02-sessa-teep-and-rats-alignment<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/interim-2019-rats-02/materials/slides-interim-2019-rats-02-sessa-teep-and-rats-alignment__;!8WoA6RjC81c!Xz1GeTjlra7rsEhGZBIFjXbzUMZsT36gMEFiL-d44MZXsNi-luOg0-LeFo4qWKJ61OI$>
> patterns to date.  The document would first define these patterns..
> PoCs.  However, our teams (like many others) use pair programming..  This
> <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Hi,
>
>      > > Patent Dept) <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>      > > <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>      > >
>      > >     Hi Kathleen,____
>      > >
>      > >     __ __
>      > >
>      > >     *发件人:*RATS [mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>      > >     <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>] *代表 *Kathleen Moriarty
>      > >     *发送时间:*2019年10月8日19:25
>      > >     *收件人:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>      > > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      > > https://www.ietf.org/mailman/listinfo/rats<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rats__;!8WoA6RjC81c!Xz1GeTjlra7rsEhGZBIFjXbzUMZsT36gMEFiL-d44MZXsNi-luOg0-LeFo4qdJAAYPI$>
>      > >
>      >
>      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      > https://www.ietf.org/mailman/listinfo/rats<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rats__;!8WoA6RjC81c!Xz1GeTjlra7rsEhGZBIFjXbzUMZsT36gMEFiL-d44MZXsNi-luOg0-LeFo4qdJAAYPI$>
>
>     --
>     Fax:   +49 421 200 3103         <https://www.jacobs-university.de/<https://urldefense.com/v3/__https:/www.jacobs-university.de/__;!8WoA6RjC81c!Xz1GeTjlra7rsEhGZBIFjXbzUMZsT36gMEFiL-d44MZXsNi-luOg0-LeFo4qb0VL94k$>>
>
>
>
> --
>
> Best regards,
> Kathleen

--

Best regards,
Kathleen

--

Best regards,
Kathleen

Juniper Business Use Only

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 10 Oct 2019 06:45:59 +0000

Hi,

That was precisely what I was proposing, may be in a not so clear way…

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 10/10/2019, 01:41, "RATS on behalf of Guy Fedorkow" <[email-masked]<mailto:[email-masked]> on behalf of gfedorkow=[email-masked]<mailto:gfedorkow=[email-masked]>> wrote:

Hi Henk,

    /guy

Hello,

Best regards,
Kathleen

I tried to help...

Best regards,
Kathleen

Viele Grüße,

Henk

--

Best regards,
Kathleen

--

Best regards,
Kathleen

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 10 Oct 2019 09:34:42 +0200

Hello Guy.
hi list,

if adding the exemplary workflows before the definition of the 
principals and interactions between them is increasing the readability 
of the architecture, then yes.

I think the notion was to add them up front.

I am well aware of how the SUIT architecture looks like and it is fueled 
by the information model, because the use cases live in there and 
requirements are inferred from them. The goal in SUIT is not to create a 
shopping list of elements for the corresponding manifest, but to provide 
a valid reason why the information elements should be defined and then 
go into the manifest data model.

In SUIT, use cases in the Information Model use English language and a 
pattern to deduct the Requirements and actual Information Elements from 
- but that all happens in the Information Model (because the manifest 
and complementary draft around it are the target there).

In the TEEP architecture, first the terminology is defined and then four 
very concise use-cases are defined, which directly leads to the system 
model. That is possible, because the application of OTrPv1 is 
well-understood and small in scope, I assume. But I am not as familiar 
to the background of TEEP as I am familiar with the background of SUIT.

So we have one case where a big number of use-cases go into the 
Information Model and one case where a small number of use-cases go into 
the architecture. Both designs are based on the background of the 
solution space of the working groups.

Only the WG can decide, if it makes sense to put a big number of use 
cases at the top of the architecture, then derive workflow compositions 
from them, and then derive the terminology from that after that.
That has not been done yet, as far I can see (and I only know SUIT and 
TEEP as the related working groups, SACM uses a different approach and 
has a separate use-case document).

Viele Grüße,

Henk

On 10.10.19 01:41, Guy Fedorkow wrote:
> Hi Henk,
> 
>      Do you think that the ‘readability’ concerns would be addressed if 
> the architecture doc were to adopt a summary of some sort of the 
> use-cases as part of its introductory material?  That would give a 
> definition of the problem to be solved written in common language, so 
> ordinary people could read it, followed by the more-carefully-defined 
> terms, roles and procedures?
> 
>      /guy
> 
> *From:* RATS <[email-masked]> *On Behalf Of * Kathleen Moriarty
> *Sent:* Wednesday, October 9, 2019 4:10 PM
> *To:* Henk Birkholz <[email-masked]>; [email-masked]
> *Subject:* Re: [Rats] Use case -> architecture document
> 
> Hello,
> 
> Henk expressed concern with my use of the word 'merge'.  By exploring 
> this new structure, I am not suggesting that we drop content.  It's a 
> accessible.  I am not suggesting essential components be dropped, but 
> would like them described more clearly.  This may help reset the 
> readability of the document.  Obviously, the WG is who decides what gets 
> adopted as a WG item.  I'd also like to make sure the end result is 
> something that is easily adoptable by industry that are already moving 
> forward with proprietary solutions.  We should put our best foot forward 
> to try to influence and gain adoption.
> 
> Michael offered to look at the structures of the TEEP and SUIT 
> architecture documents and to see what might make sense here and will 
> post to the list.
> 
> Best regards,
> 
> Kathleen
> 
> On Wed, Oct 9, 2019 at 1:33 PM Kathleen Moriarty 
> <[email-masked] 
> <mailto:kathleen.moriarty.ietf@gmail..com>> wrote:
> 
>     Hi Henk,
> 
>     On Wed, Oct 9, 2019 at 12:37 PM Henk Birkholz
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi Kathleen,
>         hi list,
> 
>     I tried to provide extensive comments, but they were not considered
>     and I was asked by you to look at the new version again.  I spent
>     over 2 days trying to help, but I think to speed this work up, we
>     need to do a pivot and focus first on the architectural patterns.
> 
> 
>     As a reminder, we don't need ASCII art anymore, version 3 was
>     released for publishing.  If Dave contributes his pictures, we can
>     use them.
> 
>     further.  Can we just wait and give Dave a chance to write up the
>     text he has said he would help with on this rather than trying to
>     all do the same thing?
> 
> 
>          > * 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)
> 
>     Not necessarily..  His work used terms in TEEP and SUIT.  Some of
>     these terms are defined int he current architecture document.  Once
>     he has this written, then merging again makes sense so that we can
>     then get language consistent and using what's been agreed upon to
>     date. I think this will actually speed up the work and adoption.  It
>     will also lower the learning curve.  You've done really good work
>     and I would like the barrier to entry lowered.  I would really like
>     to see all of this be successful and don't think this exercise will
>     take much time, but do think it will be very worthwhile.
> 
>         <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/interim-2019-rats-02/materials/slides-interim-2019-rats-02-sessa-teep-and-rats-alignment__;!8WoA6RjC81c!Xz1GeTjlra7rsEhGZBIFjXbzUMZsT36gMEFiL-d44MZXsNi-luOg0-LeFo4qWKJ61OI$>
>         <mailto:[email-masked]>
>          > <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>          >
>          >     Hi,
>          >
>          >      > Hi Kathleen,
>          >      > hi list,
>          >      >
>          >      > it would help everybody, if you could explicitly
>         highlight what
>          >     the exact
>          >      > issues wrt readability in the current architecture I-D
>         are -
>          >     always in
>          >      > comparison with the use-case I-D, if it is doing a
>         better job in
>          >     that part?
>          >      >
>          >      > Jürgen provided a good example of what he found
>         confusing as a
>          >     first time
>          >      > reader - and that was really helpful and is resulting
>         in ongoing
>          >     work.
>          >      >
>          >      > Please mind, not everything is fleshed out in the
>         architecture
>          >     (e.g. the
>          >      > workflows derived from the use-cases). The plan was to
>         aim for a
>          >     stable
>          >      > nucleus, address the issues raised by the list, go through
>          >     adoption, and
>          >      > finish the document via the issue tracker in a
>         structured process.
>          >      >
>          >      > In summary, without an actual understanding why you
>         (or others!)
>          >     think the
>          >      > document is still hard to read, there is no way of compare
>          >     readability later
>          >      > on also. It would be really good to get more precise
>         feedback on
>          >     that.
>          >      >
>          >      > Viele Grüße,
>          >      >
>          >      > Henk
>          >      >
>          >      >
>          >      >
>          >      >
>          >      > On 09.10.19 13:31, Kathleen Moriarty wrote:
>          >      > > Hi Frank,
>          >      > >
>          >      > > Thank you for voicing your concern.  I think some
>         may hold off
>          >     until the
>          >      > > updates are provided, but please do voice your
>         opinions.  I
>          >     agree that
>          >      > > this work is too important and as such, readability is a
>          >     high priority.
>          >      > > If you read through the TEEP and SUIT architecture
>         drafts, they are
>          >      > > quite easy to follow and understand.  That is
>         critical for wide
>          >     spread
>          >      > > adoption.  We may be able to find a balance, but I
>         think this
>          >     exercise
>          >      > > may speed progress as we have not decided to adopt
>         this draft
>          >     yet as a
>          >      > > working group item.
>          >      > >
>          >      > > As it stands, the use case document is not an
>         architecture
>          >     document, but
>          >      > > it could be shaped as such and I'd really like to
>         see if we can
>          >     do that
>          >      > > in short order to have a comparison prior to an
>         adoption call.
>          >      > >
>          >      > > Best regards,
>          >      > > Kathleen
>          >      > >
>          >      > > On Wed, Oct 9, 2019 at 6:53 AM Xialiang (Frank,
>         Network Standard &
>          >      > > Patent Dept) <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]>>
>          >      > > <mailto:[email-masked]
>         <mailto:[email-masked]>>>> wrote:
>          >      > >
>          >      > >     Hi Kathleen,____
>          >      > >
>          >      > >     __ __
>          >      > >
>          >      > >     I am very concerned with this new direction and
>         I strongly
>          >     object.____
>          >      > >
>          >      > >     __ __
>          >      > >
>          >      > >     Current architecture draft goes through a lot
>         discussions and
>          >      > >     reaches many consensus. Right now, it really
>         helps IETF
>          >     (Teep for
>          >      > >     example), FIDO, TCG and many others. The only
>         issues are on
>          >      > >     readability, the standards track and the
>         completeness (e.g.,
>          >      > >     passport and background check are still
>         missing). It is an
>          >     very good
>          >      > >     document and correct terminology is very
>         important for remote
>          >      > >     attestation.____
>          >      > >
>          >      > >     __ __
>          >      > >
>          >      > >     About use cases document, Its goal is just to
>         clarify a
>          >     sample list
>          >      > >     of scenarios that remote attestation can apply
>         to and then
>          >     deduce
>          >      > >     the requirements and the following concrete protocol
>          >     drafts. It is
>          >      > >     not fit to be an architecture.____
>          >      > >
>          >      > >     __ __
>          >      > >
>          >      > >     The current architecture is too important for
>         telecom and
>          >     network
>          >      > >     equipment vendors and service providers. I have
>         strong
>          >     doubts that
>          >      > >     current EAT and OTrPv2 alone is suitable for the
>         (virtualized)
>          >      > >     network infrastructure situation.____
>          >      > >
>          >      > >     __ __
>          >      > >
>          >      > >     B.R.____
>          >      > >
>          >      > >     Frank____
>          >      > >
>          >      > >     ____
>          >      > >
>          >      > >     __ __
>          >      > >
>          >      > >     This e-mail and its attachments contain confidential
>          >     information
>          >      > >     from HUAWEI, which is intended only for the
>         person or
>          >     entity whose
>          >      > >     address is listed above. Any use of the information
>          >     contained herein
>          >      > >     in any way (including, but not limited to, total
>         or partial
>          >      > >     disclosure, reproduction, or dissemination) by
>         persons
>          >     other than
>          >      > >     the intended recipient(s) is prohibited. If you
>         receive
>          >     this e-mail
>          >      > >     in error, please notify the sender by phone or email
>          >     immediately and
>          >      > >     delete it!____
>          >      > >
>          >      > >     __ __
>          >      > >
>          >      > >     *发件人:*RATS [mailto:[email-masked]
>          >     <mailto:[email-masked] <mailto:[email-masked]>>
>          >      > >     <mailto:[email-masked]
>         <mailto:[email-masked]>>>] *代表 *Kathleen Moriarty
>          >      > >     *发送时间:*2019年10月8日19:25
>          >      > >     *收件人:[email-masked] <mailto:[email-masked]>
>          >     <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>          >      > >     *主题:*[Rats] Use case -> architecture document____
>          >      > >
>          >      > >     __ __
>          >      > >
>          >      > >     Hello!
>          >      > >
>          >      > >     I read through the latest version of the ‘use
>         case’ document
>          >      > >     yesterday and found it very easy to read and
>         understand,
>          >     meaning I
>          >      > >     think it is written well and could be easily
>         understood by many
>          >      > >     without having to climb up a learning curve. ____
>          >      > >
>          >      > >     __ __
>          >      > >
>          >      > >     First, this could be a very useful document to
>         register
>          >     claims for
>          >      > >     the use cases.
>          >      > >
>          >      > >     Second, if the workflow for the passport and
>         background
>          >     check were
>          >      > >     added and put in terms of the open trust
>         protocol v2 from
>          >     TEEP, we
>          >      > >     have a fairly nice architecture document that’s
>         easy to
>          >     read and may
>          >      > >     gain adoption.  The workflows cover the various
>          >     interactions between
>          >      > >     roles and TEEP has actively broken up OTrP in v2 to
>          >      > >     accommodate using EAT tokens, this would help
>         create that
>          >     link and
>          >      > >     make it very clear.
>          >      > >
>          >      > >     The other thing I like about the use case
>         document and think we
>          >      > >     should expand on is the references to other work
>         items.
>          >     This makes
>          >      > >     it an architecture document that maps out the
>         full plan of
>          >     the WG.
>          >      > > One like that was extremely well received by all the
>         ADs that don’t
>          >      > >     like informational/helpful documents.
>          >      > >
>          >      > >     I’m a bit nervous with the terminology being
>         defined and
>          >     would love
>          >      > >     to see something like this that’s simplified and
>         more easily
>          >      > >     adoptable. ____
>          >      > >
>          >      > >     __ __
>          >      > >
>          >      > >     I appreciate the work done to improve the
>         architecture
>          >     document, but
>          >      > >     I do think the structure changes to the use case
>         document as
>          >      > >     suggested could result in an easier to
>         understand (and
>          >     therefore
>          >      > >     easier to adopt) document.____
>          >      > >
>          >      > >     __ __
>          >      > >
>          >      > >     While the architecture document is more
>         readable, I think
>          >     we can do
>          >      > >     better.  Adoption is important and our
>         timeliness matters a
>          >     lot for
>          >      > >     this work.  EATs can be used for may use cases
>         with OTrPv2,
>          >     so let's
>          >      > >     keep it as simple as we can.
>          >      > >
>          >      > >     Thoughts are appreciated.
>          >      > >
>          >      > >     Best regards,
>          >      > >     Kathleen-- ____
>          >      > >
>          >      > >     __ __
>          >      > >
>          >      > >     Best regards,____
>          >      > >
>          >      > >     Kathleen____
>          >      > >
>          >      > >
>          >      > >
>          >      > > --
>          >      > >
>          >      > > Best regards,
>          >      > > Kathleen
>          >      > >
>          >      > > _______________________________________________
>          >      > > RATS mailing list
>          >      > > [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>          >      > > https://www.ietf.org/mailman/listinfo/rats
>         <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rats__;!8WoA6RjC81c!Xz1GeTjlra7rsEhGZBIFjXbzUMZsT36gMEFiL-d44MZXsNi-luOg0-LeFo4qdJAAYPI$>
>          >      > >
>          >      >
>          >      > _______________________________________________
>          >      > RATS mailing list
>          >      > [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>          >      > https://www.ietf.org/mailman/listinfo/rats
>         <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rats__;!8WoA6RjC81c!Xz1GeTjlra7rsEhGZBIFjXbzUMZsT36gMEFiL-d44MZXsNi-luOg0-LeFo4qdJAAYPI$>
>          >
>          >     --
>          >     Fax:   +49 421 200 3103       
>           <https://www.jacobs-university.de/
>         <https://urldefense.com/v3/__https:/www.jacobs-university.de/__;!8WoA6RjC81c!Xz1GeTjlra7rsEhGZBIFjXbzUMZsT36gMEFiL-d44MZXsNi-luOg0-LeFo4qb0VL94k$>>
>          >
>          >
>          >
>          > --
>          >
>          > Best regards,
>          > Kathleen
> 
> 
>     -- 
> 
>     Best regards,
> 
>     Kathleen
> 
> 
> -- 
> 
> Best regards,
> 
> Kathleen
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Oct 2019 13:27:15 +0200

Kathleen Moriarty <[email-masked]> wrote:
    > As it stands, the use case document is not an architecture document,
    > but it could be shaped as such and I'd really like to see if we can do
    > that in short order to have a comparison prior to an adoption call.

As the primary author of the use case document, I can't see how the document
can be manipulated easily into an architecture document.  If I were to do so,
I'd wind up with a document that looks much like Henk's -02 document.

And I'm not sure I'm willing to do an architecture document "on my own"

Henk and I have had many discussions about these documents going back at
least 8 months.  What I am hearing is that some people prefer my lazy
Canadian use of imprecise language over Henk's precise, almost mathetical,
use of language.  Perhaps this is a case of "Only Nixon can go to China"...
  ( https://en.wikipedia.org/wiki/Nixon_goes_to_China )
that is, only a native English speaker is allowed to be lazy and familiar
with language.  Any non-native speaker must be more precise.

Henk and I have agreed that I will help with the Architecture document.
We are in the process of setting up a time for a weekly work session.

So my ask is that we go to the end of IETF106 before we change direction.

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Oct 2019 13:28:07 +0200

> what's been used in SUIT and TEEP as his slides match the terminology.

Sounds good.  The text is good to have.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Oct 2019 13:45:48 +0200

Hi Kathleen,

It is hard to keep up with this torrent, and I’ll respond to a snapshot.

However, I would like to point out that there is a place for specs, and a place for books.
When 6LoWPAN was done (RFC 4919, RFC 4944), we wrote a book, and that is definitely a better place to get a thorough introduction.

The job of the spec is to crystallize consensus, not to serve as a textbook.
Where editorial issues hinder understanding, this can (and should!) be fixed in the WG process.
Restarting the effort comes with the danger of diluting the hard-earned consensus.

I like the fact that the spec is 10 pages net now.  Adding examples and other material may hinder adoption by making people think that the architecture is complex.  It is not.  (I made this mistake enough already, no need to repeat it here.)

The main point of the architecture is to define the roles in unambiguous terms, and the axioms we have about these roles.  Without this, we cannot communicate.  If you try buying a house and don’t understand the roles of buyer, seller, bank, and notary, you won’t get a good outcome.  The architecture document provides this, and adding introductory material is only going to help so much (i.e., please do, but in moderation).

So my recommendation would be to adopt this document quickly, and to fix any impediments to understanding it.
Let the flowers bloom and write great documents about use cases (done), usage scenarios and workflow patterns.  These can then also make use of the agreed terminology, which will tremendously help in understanding them as a group.
But please don’t hold up the progress of the architecture document by introducing non-essential surgery.  We need this document, shipped.

Grüße, Carsten

> On Oct 9, 2019, at 18:03, Kathleen Moriarty <[email-masked]> wrote:
> 
> 
> I would rather see the architectural patterns come before the specific terminology.  If you look through the slides from Dave's presentation at our previous interim meeting, he laid out several architectural patterns using the same language that is used in SUIT and TEEP.  It is desirable, IMO, to begin with architectural patterns that can be used in necessary use cases.  Additional architectural patterns may arise, but we have a nice starting point.
> 
> See: https://datatracker.ietf.org/meeting/interim-2019-rats-02/materials/slides-interim-2019-rats-02-sessa-teep-and-rats-alignment
> It defines the passport, background check, and verifying relying party architectural patterns for RATS.  
> It also provides an illustration of how the OTrP model for device state can fold into each of those 3 RATS architectural patterns.
> 
> What Dave is planning to do is to write text describing these architectural patterns.  It will likely be in the language similar to what's been used in SUIT and TEEP as his slides match the terminology.  
> 
> Attestation has countless use cases, and several known architectural patterns to date.  The document would first define these patterns.  Then, like SUIT, a high-level description of use cases could be included with pointers to other future WG drafts that more fully define the use cases.  Any additional terminology that is necessary could then be added, but keeping in mind that we do not want unnecessary terms.  If we start from the models, it will be easier to maintain the scope and set of terms.  The terms would come from the current document, but language may be adjusted as needed.
> 
> The specific use case details that map claims could be in a later section with the IANA section defining claims for use cases to be added to the CWT and JWT registry.
> 
> I work for Dell and would like to be able to bring this work forward for PoCs.  However, our teams (like many others) use pair programming.  This means the 2 coders work as a team and in our model, they rotate to a new project every 2 weeks.  This helps with innovation and other benefits.  If each pairing team has a significant learning curve, a lot of time will be wasted and the PoC would not make progress.  
> 
> If the goal for service providers and others is to use this technology (as is my goal), we need to make it something that is accessible to many.  The developers at many organizations will use crypto libraries, but will not necessarily be security people.  They will be starting from a point where they do not have security specific language nor this very specific set of terms that is being defined.  The simpler we can keep it, the better to gain wider adoption.
> 
> I think if we step back and see what Dave does with the document to define the architectural patterns, then we can decide how we merge content with readability as a goal.
> 
> Best regards,
> Kathleen
> 
> On Wed, Oct 9, 2019 at 10:50 AM Schönwälder, Jürgen <[email-masked]> wrote:
> Hi,
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 10 Oct 2019 10:43:00 -0400

Hi Carsten,

On Thu, Oct 10, 2019 at 7:45 AM Carsten Bormann <[email-masked]> wrote:

> When 6LoWPAN was done (RFC 4919, RFC 4944), we wrote a book, and that is
> definitely a better place to get a thorough introduction.
>

I'm sure that will be helpful in time too, but companies are moving forward
with attestation using proprietary formats now.  I am concerned and would
like this effort to be as successful as possible.  As a former AD, I have
read thousands of drafts, readability can be achieved with the use of
complex terms being defined.  Just to note, even Henk is not happy with
several of the terms defined.  Please don't insinuate that I don't know the
difference between a book and a draft, this is not helpful to advance this
discussion.  My goal is to actually speed this work up and make it easily
adoptable.  There has been excellent work done and interoperability, as
well as adoptability are critical.

Dave Thaler agreed it could be more readable and offered to help.  He has
likely read as many drafts/RFCs, including architecture drafts across
areas.

> Restarting the effort comes with the danger of diluting the hard-earned

I didn't say the work would be discarded and clarified that yesterday as I
interpret 'merge' differently than Henk and possibly you, maybe others. You
may have missed that in previous threads.

I believe we are at a point where many would like to see what is produced
in short term to figure out how to make the document more readable.  I
would also like to make it as useful as possible for the IESG approval
process.  The ADs must see the document as useful and having just rolled
off as an AD recently, I am familiar with the inner workings and
challenges. Making this as easy as we can for the current AD is most
appreciated.  They are overburdened, so avoiding unnecessary discusses or
abstains is a goal.

> I like the fact that the spec is 10 pages net now.  Adding examples and
> other material may hinder adoption by making people think that the
> architecture is complex.  It is not.  (I made this mistake enough already,
> no need to repeat it here.)
>
> The main point of the architecture is to define the roles in unambiguous
> terms, and the axioms we have about these roles.  Without this, we cannot
> communicate.  If you try buying a house and don’t understand the roles of
> buyer, seller, bank, and notary, you won’t get a good outcome.  The
> architecture document provides this, and adding introductory material is
> only going to help so much (i.e., please do, but in moderation).
>

I think we should let the work progress and see how the document can be
improved instead of continuing to comment here.  Please do watch your
phrasing on list as this message is an insult to me more personally.

Some do agree the document could read better, so I do hope this has an
impact on improving the document and making the technology more easily
adoptable.  I do hope more at the end of this process agree, and if not,
the WG decides in any case.
I think an improved document that's readable and perceived by others
outside of the area of work is important.

> any impediments to understanding it.

This work has begun.

> Let the flowers bloom and write great documents about use cases (done),
> usage scenarios and workflow patterns.  These can then also make use of the
> agreed terminology, which will tremendously help in understanding them as a
> group.
> But please don’t hold up the progress of the architecture document by
> introducing non-essential surgery.  We need this document, shipped.
>

I think this short break will actually speed things up.  We will also have
the IESG process and my goal is to make that smooth as well.

Best regards,
Kathleen

> section with the IANA section defining claims for use cases to be added to
> the CWT and JWT registry.
> >
> (as is my goal), we need to make it something that is accessible to many.
> The developers at many organizations will use crypto libraries, but will
> not necessarily be security people.  They will be starting from a point
> where they do not have security specific language nor this very specific
> set of terms that is being defined.  The simpler we can keep it, the better
> to gain wider adoption.
> >
> define the architectural patterns, then we can decide how we merge content
> with readability as a goal.
> >
> > Best regards,
> > Kathleen
> >
> exact
> time
> but
> > > >     First, this could be a very useful document to register claims
> for
> > > >     the use cases.
> > > >

-- 

Best regards,
Kathleen

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 10 Oct 2019 11:45:44 -0700

I know Henk has put lots of work into this. Here’s some hopefully concrete and helpful comments on why it is hard for me to read.

I think this work is hard because we have different well-establishes worlds (TCG, TEE, router/Yang, mobile apps worlds) coming together that have been unconsciously using terminology in very particular ways for a long time. Coming to common terminology seems important.

In the intro:
The long-standing Internet Threat Model [RFC3552] focuses on threats to the communication channel, as pioneered by Dolev and Yao [DOLEV-YAO] in 1983. However, threats to the endpoint [RFC5209] and system components [RFC4949] of transited communication gear (i.e. hosts) are increasingly relevant for assessing the trustworthiness properties of a communication channel. Beyond the collection and conveyance of security posture [RFC5209] about an endpoint (host), remote attestation provides believable trustworthiness claims ("Evidence") about an endpoint (host). In general, this document provides normative guidance how to use, create or adopt network protocols that facilitate RATS.

This sentence about transited gear and trusting the channel is confusing. Is the gear in moving around or is something moving through the gear? It is hard to tell from the sentence. I don’t think we are assessing communication channels, so mention of them seems both wrong and extraneous.
Mention of NEA [RFC5209] is probably not needed in the introduction. The way it is introduced, you have to follow the link to know what the  sentence is trying to say unless you happen to know that 5209 is NEA and what NEA is.
The last sentence could probably be left off.

First bullet in 1.1:

   o  In remote attestation workflows, trustworthiness Claims are
      accompanied by a proof of veracity.  Typically, this proof is a
      cryptographic expression such as a digital signature or message
      digest.  Trustworthiness Claims with proof is what makes
      attestation Evidence believable.

Claims haven’t been properly introduced at this point in the document
The word “workflow” is unnecessary. 
The adjective “trustworthiness” applied to claims is unnecessary and confusing. Are they different from untrustworthy claims?
“proof of veracity” and “cryptographic expression” are bonus technical terms that don’t help.
Instead of the whole paragraph: “Claims are digitally signed to prove their origin” (yes, they can be MAC’d, but it is very untypical and the intro doesn’t need to be burdened mentioning it).

Some of the sources of difficult readability are:
Use of lots of extra and varying technical terms for roughly the same thing. For example “proof of veracity”, “cryptographic expression”. 
Out of order introduction of concepts and terminology. For example, “claim” is used before being described. 
Extraneous words and framing. 
It feels like each sentence or paragraph is trying to say too much.
Lots of abstraction and few easy-to-relate-to examples.

LL

---

From: Dave Thaler <[email-masked]>
Date: Mon, 14 Oct 2019 23:01:04 +0000

[…] 
> content with readability as a goal.
[…]

As requested, I have written a document for the WG to consider, that
includes my architectural patterns work, plus some content pulled from
others' docs.  It's not complete (i.e., some stuff is not covered), but I do
hope it's readable by a general audience.

Besides some topics I just didn't get to, I omitted some other topics either
because I was intentionally trying to reduce the number of terms needed to
understand the doc, or because I didn't understand the content enough to
know how to rephrase it in more accessible terms, or because I actually disagreed
with it and so wanted to punt that discussion until after people could
see the direction I was going :)

I will post a -00 shortly and then you can all review it and hopefully figure
out what path forward the WG would like to take.

Dave

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Tue, 15 Oct 2019 15:45:01 +0000

> hope it's readable by a general audience.

This document is well readable and the use case examples seem to be
about right (although it is not entirely clear for all of them how the
architecture supports them). Dave's document defines fewer terms
compared to Henk's document and I assume the WG needs to decide what
the set of terms is that should be defined in the WG's architecture
document.

Dave takes a minimalist approach, but then he introduces some terms
later on in the document (e.g., Endorsement) that may actually belong
into the terminology section.

If an Endorsement is a statement, why is it defined under Conceptual
Messages? I assume messages may carry endorsements.  Perhaps the
section title "Conceptual Messages" is a bit misleading?  Henk's
document uses the term 'claim' (which does not really show up in
Dave's document), as a superclass, i.e., Endorsements and Evidence are
all forms of Claims (instead of 'Conceptual Messages'). Perhaps Dave's
'statements' used informally in the 'Conceptual Messages' section are
Henk's 'claims' and we need to pick a term and then change the section
title to 'Types of Claims' or 'Types of Statements' or something like
that and we likely want to define the concept of a 'Claim' or
'Statement'.

Henk's architecture discusses 'Attestation Principles' that are not in
Dave's proposal. I guess the WG needs to decide whether to include
them or not. Are these important for understanding or guiding the RATS
work?

I also like to mention that there are research papers where the remote
attestation process is described more in the form of a challenge
response interaction, where the verifier sends a specific challenge to
a device and the device returns a response that is than evaluated by
the verifier. An example is "compute a hash over certain memory areas
within a certain time limit" and then the device returns the result
and the verifier checks whether it is what is expected.  The time
limit is used to control that an infected device can't reasonably
forward the challenge to obtain an answer from an unaffected device
that is then relayed back to the verifier. The question is whether the
architecture includes models where a stimuli is used to trigger the
production of a certain Evidence or whether this is left out of the
architectural picture on purpose. For more details, see for example
<doi.org/10.1145/2988546> (you will find a preprint if you search).

/js

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 15 Oct 2019 18:24:30 +0200

Hi Jürgen,

a quick reply on the most simple item (I hope):

> challenge response interaction

The authors decided to split solution references out of the architecture 
and at the moment reference interaction models are maintained here:

> https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interaction-model/

We are working on the request to move information elements that are not 
Claims but used in the transfer protocols to this I-D, too.

There is also running code as a "proof of concept on freshness & 
veracity" for the nonce-based handshake to enable some hand-on experience:

> https://github.com/fraunhofersit/charra

The next steps are to include more interaction are to include additional 
interaction models for DICE, DAA & TUDA (and corresponding minimal sets 
of elements for network protocols).

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 15 Oct 2019 18:34:04 +0200

Hi Jürgen,

There is also running code as a "proof of concept on freshness & 
veracity" for the nonce-based handshake to enable some hand-on 
experience:ifc	

Viele Grüße,

Henk

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 15 Oct 2019 17:52:30 +0000

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

---

From: Ira McDonald <[email-masked]>
Date: Tue, 15 Oct 2019 14:14:57 -0400

Hi Thomas,

I agree with your support for continuing development of Henk's RATS
architecture
document.  Also your suggestion of profiles.

With respect to Network Endpoint Assessment, folks would benefit from
reading
RFC 5209 NEA Overview and Requirements:

https://datatracker.ietf.org/doc/rfc5209/

Which was the requirements document of the IETF NEA WG, who standardized
the TCG-contributed TNC protocol suite 10 years ago.

Cheers,
- Ira

On Tue, Oct 15, 2019 at 1:54 PM Thomas Hardjono <[email-masked]> 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).
>

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 15 Oct 2019 19:55:12 +0000

​

My apologies that this email is late.  I'm just catching up on the reading RATS mail-list.

In her 10/8th email Kathleen has suggested some major changes to the direction of the RATS architecture as a whole, which may have dramatic impact on the applicability of RATS to broader scenarios.

So I have a question about WG procedure: what is the role/capacity and weight of a co-chair when the person makes statements.

I'd also like to hear from the other two co-chairs on this matter.

Apologies again for the delay.

-- thomas --

​

________________________________
From: RATS <[email-masked]> on behalf of Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]>
Sent: Wednesday, October 9, 2019 6:53 AM
To: Kathleen Moriarty
Cc: [email-masked]
Subject: [Rats] 答复: Use case -> architecture document

Hi Kathleen,

B.R.

Frank

Hello!

Best regards,
Kathleen--

Best regards,
Kathleen

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 15 Oct 2019 20:36:36 +0000

Hello Thomas!

From: RATS [mailto:[email-masked]] On Behalf Of Thomas Hardjono
Sent: Tuesday, October 15, 2019 3:55 PM
To: [email-masked]
Subject: [Rats] Question about WG Procedure -- Re: 答复: Use case -> architecture document

​

[Roman] As to procedure, WG consensus will decide which drafts get adopted into the WG, the content of these drafts, and when they are “done”.  I’m repeating what both Kathleen [1] and Henk [2] have already noted.  Additionally, the WG charter [3] guides scope and the milestones [4] hint at timing.

Regards,

Roman

(as the responsible AD of RATS)

[1] https://mailarchive.ietf.org/arch/msg/rats/CVH91BCKrU1SxraM4M_aHpYMx-U

[2] https://mailarchive.ietf.org/arch/msg/rats/5Z505xW0PWgWHbPfMwdPnpJsMzk

[3] https://datatracker.ietf.org/doc/charter-ietf-rats/

[4] https://datatracker.ietf.org/wg/rats/about/

-- thomas --

​

________________________________
From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, October 9, 2019 6:53 AM
To: Kathleen Moriarty
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Rats] 答复: Use case -> architecture document

Hi Kathleen,

B.R.

Frank

发件人: RATS [mailto:[email-masked]] 代表 Kathleen Moriarty
发送时间: 2019年10月8日 19:25
收件人: [email-masked]<mailto:[email-masked]>
主题: [Rats] Use case -> architecture document

Hello!

Best regards,
Kathleen--

Best regards,
Kathleen

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 15 Oct 2019 20:19:43 -0700

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 <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Oct 2019 14:04:24 +0200

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.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Oct 2019 14:07:02 +0200

Schönwälder, Jürgen wrote:
    > Dave's proposal. I guess the WG needs to decide whether to include them
    > or not. Are these important for understanding or guiding the RATS work?

I think that, to the extent that the architecture document includes
requirements on the technical document must answer, that these principles
need to be made explicit.   They should be numbered as well so that we know
which principle to compromise to maintain another one.

    > within a certain time limit" and then the device returns the result and

That's an interesting thing to add.
I think that this makes for some interesting additions to use cases.

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 16 Oct 2019 12:10:02 +0000

> this is an act of Attestation, and this the Verifier is the Attester.

This took me off as well when I started reading about RATS. :-) Henk
told me that the industry has settled on somewhat confusing terms in
this area and it might confuse this part of the industry if the IETF
picks different terms... Not sure what is the right thing to do.

/js

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 16 Oct 2019 10:18:08 -0400

On Wed, Oct 16, 2019 at 8:06 AM Michael Richardson <[email-masked]>
wrote:

> them

In a sense, Dave's document covers this idea as it does discuss the ability
for 2 functions to be combined.  I don't think adding a term is needed to
state that though and adding a specific term for that leads to confusion.

> and

And an architectural pattern.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 16 Oct 2019 10:27:36 -0400

> picks different terms... Not sure what is the right thing to do.

I gave a keynote at the TCG meeting yesterday and it was a very well spent
day.  They were receptive to learning more on the IETF and related work
areas that could be of interest to the TCG and participants.

As for terminology, it was stated that the terminology is confusing for
them as well in their space and they'd like to see it easier
to understand.  This may not be the opinion of everyone that was in the
room, but no one argued the point.

One of the main purposes of the talk was to enhance collaboration in this
area of work, and to help those in TCG understand how to engage in the
IETF.  Additionally, I wanted to (and still do) learn more about their
other work in the area of attestation.  Many of us, including TCG
leadership (lunch discussion) are interested to see a clearer picture of
the space painted and to reduce the chance of overlapping work.  Hopefully,
we will see additional TCG participants begin to review and weigh in on
RATS WG items.  I also hope that some more of their work may transition to
this working group, but that may take some time.  This could help to paint
that larger picture and distill the numerous set of use cases.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Oct 2019 16:31:57 +0200

> state that though and adding a specific term for that leads to

I need the architecture document to introduce terms like "freshness" and "provenance"
and explain how they apply in an attestation context.  I need to know, if I
have to compromise one or the other to satisfy a particular use case, which
one is more important.

{I don't claim the other document does a great job at defining those terms, btw}

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 16 Oct 2019 10:35:21 -0400

On Wed, Oct 16, 2019 at 10:31 AM Michael Richardson <[email-masked]>
wrote:

>     >> > Henk's architecture discusses 'Attestation Principles' that are
> not
>     >> in

Agreed, this is important.  Attestations also provide origin
authentication, which is the basis for provenance.  Provenance just makes
that origin authentication (possibly for nested components) to be
possible.  IMO, it's a well understood term and should be easy to add, but
I'd like to see it in context of origin authentication that helps to
provide provenance.  It's how I talked about it yesterday.

> {I don't claim the other document does a great job at defining those
Hopefully, my explanation helps toward a definition in terms used in the
IETF already.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 16 Oct 2019 17:06:55 +0200

Hi Kathleen,
hi list,

there was an interesting follow-up on discussion how RFC4949 data origin 
authentication ("The corroboration that the source of data received is 
as claimed."), attestation provenance & device identity are strongly 
intertwined, but mean different things in the context of RATS (well, 
actually the example this was discussed on was a subset of RATS: the RIV 
use-case).

Another good example coming out of that discussion were the subtle 
difference between the RFC4949 term "fresh" ("Recently generated; not 
replayed from some earlier interaction of the protocol") evidence and 
the "freshness of evidence" (in contrast to "recentness of claim _and_ 
evidence creation"), which also mean quite different things.

Last example I want to provide as food of though from that discussion is 
"proof of possession" vs "proof of availability at a specific point in 
time" This differentiation is a quite important for DICE-based remote 
attestation procedures, where the persistence of an alias key and 
corresponding certificates for attestation can be significantly shorter 
than, e.g. an associated DevID [1]. The point being, the semantics 
around the terms are vital, but unfortunate also easily conflated, if 
not worded with precision in a bigger context.

The conclusion was to be very carefully about not conflating different 
things for the sake of simplicity, I think.

Viele Grüße,

Henk

[1] 
https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf

On 16.10.19 16:35, Kathleen Moriarty wrote:
> origin authentication

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 16 Oct 2019 15:13:34 +0000

Speaking as a co-chair the activity on the list related to architecture at the very least points to consensus around a desire/need for an architecture draft to be adopted. 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? List activity seems to suggest the latter – at least in terms of adopting an architecture draft that is recognized as a starting point for the architecture. There may be differences of opinion on what content should exist in the starting point.

Speaking as one of the authors of the birkholtz arch draft (h.arch) the primary contribution it makes (as a starting point) is the definition of a set of roles and messages that make up an attestation system.

The thaler arch draft (t.arch) seems to focus primarily on protocol endpoint interactions and coins the terms “passport” and “background check” as a way to model connectivity paths. The endpoint names in t.arch appear to overlap/conflate role names in b.arch. This may be confusing or illustrative depending on the reader.

The h.arch roles architecture purposefully avoids trying to capture endpoint connectivity semantics so that the role interactions could be appreciated. A litmus test for roles might be that addition of endpoint connectivity semantics shouldn’t breaks roles definitions. The t.arch defines two connectivity models (passport and background check) that are very relevant to TEEP but may also be relevant outside of a TEEP context. There are other connectivity models not described by either h.arch or t.arch for example broadcast/multicast, pub-sub, mesh, blockchain. An expectation of the h.arch is that a mapping of roles onto a broad spectrum of connectivity models will preserve the defined role-message interactions. The connectivity arch models in t.arch seems to demonstrate the validity of the h.arch roles model since the mapping in t.arch borrows the terminology and semantics of h.arch.

The h.arch doesn’t have a section that details various endpoint connectivity options. Such a section could go in a couple of directions (1) identify the need for mapping roles to connectivity endpoints and connectivity semantics, (e.g. request-response, pub-sub, mesh, blockchain); but stop short of defining them in the arch draft or (2) define the possible connectivity models with role mappings, but inclusion in the RATS arch draft would be exemplary.

Given passport and background check models (and variations / hybrids) seem to be highly synergistic with TEEP. If option (1) is desirable, the TEEP arch draft could be a good place to map the passport and background check models to RATS roles. If option (2) is desirable, the TEEP arch might still need to qualify what the RATS arch considers as exemplary.

-Ned

On 10/15/19, 15:56 PM, "RATS on behalf of Thomas Hardjono" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

​

-- thomas --

​

Hi Kathleen,

B.R.

Frank

Hello!

Best regards,
Kathleen--

Best regards,
Kathleen

---

From: Dave Thaler <[email-masked]>
Date: Wed, 16 Oct 2019 15:39:36 +0000

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

I intentionally did not, since every use case I listed could use either model, which was why I
put the models after the use cases.  Were the order to be reversed, I would need to
replace every use case with multiple "use cases", one per model.   That's why the intro
above the use cases says they're solution independent.  The choice of model is made
by a solution to a scenario, not the scenario.   Maybe it's a terminology point and
I should call them scenarios?   That is, if you think that a "use case" is a specific solution
to a scenario, rather than the scenario that needs to be solved with some solution
which is how I was using the term.

> I still find the terms Attester and Verifier confusing.

I have no strong opinion on that matter, and will go along with whatever the WG consensus is,
but was trying to use Henk's terms where I think a concept is essential to understand.

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

I think it comes from the phrase "A attests to B" (meaning "A supplies claims to B so that
B can evaluate A's trustworthiness"), which is how I've often heard people
talk about attestation.   In that phrasing A is the Attester.

In your phrasing, people would say "B attests A", but I've never heard anyone say that.

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

That was an area I just hadn't gotten to in my draft attempt, so I don't have a better
suggestion yet either, but I do think such a discussion is useful to help motivate the
discussion around different ways to model sets of claims (nesting, chaining, etc.)

Dave

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 16 Oct 2019 08:49:52 -0700

> On Oct 16, 2019, at 8:13 AM, Smith, Ned <[email-masked]> 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

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 16 Oct 2019 15:55:42 +0000

Hi Thomas,
I echo Roman’s comments and pointedly, to the role and responsibilities of the WG chairs….those are described in RFC2418.

As chairs, we do have to ensure we can continue to stimulate discussion so as to keep progress moving forward.  The intent discussed at the virtual interim was that there needed to be readability of the architecture draft.  Options were also discussed on how to proceed were made and as Dave volunteered to provide draft text, he has done so but as an individual contribution as an alternate architecture draft.

In the end, the chairs are guided by the working group consensus to adopt or move forward any of the documents which has already been stated.

I am trying to catch up on all the emails as I do think there are points of agreement on the general concepts in Henk’s architecture draft which I’m trying to figure out how to craft a response for now that there’s another architecture draft, e.g. Dave’s.

Best, Nancy

From: RATS <[email-masked]> on behalf of Roman Danyliw <[email-masked]>
Date: Tuesday, October 15, 2019 at 13:37
To: Thomas Hardjono <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Question about WG Procedure -- Re: 答复: Use case -> architecture document

Hello Thomas!

​

Regards,

Roman

-- thomas --

​

Hi Kathleen,

B.R.

Frank

Hello!

Best regards,
Kathleen--

Best regards,
Kathleen

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 16 Oct 2019 16:00:47 +0000

Hi,
Comments below:

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Wednesday, October 16, 2019 at 08:50
To: "Smith, Ned" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Thomas Hardjono <[email-masked]>
Subject: Re: [Rats] Question about WG Procedure -- Re: 答复: Use case -> architecture document

On Oct 16, 2019, at 8:13 AM, Smith, Ned <[email-masked]<mailto:[email-masked]>> 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.
[NCW] Fully agree….and  we did state (perhaps it was during the BoFs) that the architecture could be done in parallel as on several occasions the architecture gets “tweaked” based on the adoption of the actual schemas, protocols and interfaces adopted.

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.
[NCW] Abstractly, I think there is general agreement on most of the roles despite the naming of the roles and how they potentially fllow.  That, to me, can be the basis for the architecture, the models that Dave describes are more of the interactions that define the interfaces or communications between the roles.  I’m not convinced yet on the hardship other  than the discussions on the terminology

LL

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 16 Oct 2019 13:21:29 -0400

On Wed, Oct 16, 2019 at 12:01 PM Nancy Cam-Winget (ncamwing) <
[email-masked]> wrote:

> Hi,
>
> Comments below:
>
>
>
> *From: *RATS <[email-masked]> on behalf of Laurence Lundblade <
> [email-masked]>
> *Date: *Wednesday, October 16, 2019 at 08:50
> *To: *"Smith, Ned" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Thomas Hardjono <[email-masked]>
> *Subject: *Re: [Rats] Question about WG Procedure -- Re: 答复: Use case ->
> architecture document
>
>
>
>
>
> 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?
>
> ...
>
> [NCW] Fully agree….and  we did state (perhaps it was during the BoFs) that
> the architecture could be done in parallel as on several occasions the
> architecture gets “tweaked” based on the adoption of the actual schemas,
> protocols and interfaces adopted.
>
>
>
> 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.
>
> [NCW] Abstractly, I think there is general agreement on most of the roles
> despite the naming of the roles and how they potentially fllow.  That, to
> me, can be the basis for the architecture, the models that Dave describes
> are more of the interactions that define the interfaces or communications
> between the roles.  I’m not convinced yet on the hardship other  than the
> discussions on the terminology
>

+1 - I agree with Nancy's responses.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 16 Oct 2019 19:34:18 +0200

Hi all,

I 2nd this for the first YANG module, too. +1 to Nancy's summary.

We explicitly illustrated during chartering that the architecture should 
grow and be inclusive to be able to represent the evolution of other WG 
items and be able to map solutions outside the IETF.

 From my subjective point of view today, EAT might actually have the 
least dependencies as it is intended to be quite versatile by design.

Viele Grüße,

Henk

On 16.10.19 19:21, Kathleen Moriarty wrote:
> 
> 
> On Wed, Oct 16, 2019 at 12:01 PM Nancy Cam-Winget (ncamwing) 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi,____
> 
>     Comments below:____
> 
>     __ __
> 
>     *From: *RATS <[email-masked] <mailto:[email-masked]>>
>     on behalf of Laurence Lundblade <[email-masked]
>     <mailto:[email-masked]>>
>     *To: *"Smith, Ned" <[email-masked] <mailto:[email-masked]>>
>     *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, Thomas Hardjono <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject: *Re: [Rats] Question about WG Procedure -- Re: 答复: Use
>     case -> architecture document____
> 
>     __ __
> 
>     __ __
> 
>         On Oct 16, 2019, at 8:13 AM, Smith, Ned <[email-masked]
>         <mailto:[email-masked]>> 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. ____
> 
>     [NCW] Fully agree….and  we did state (perhaps it was during the
>     BoFs) that the architecture could be done in parallel as on several
>     occasions the architecture gets “tweaked” based on the adoption of
>     the actual schemas, protocols and interfaces adopted.____
> 
>     __ __
> 
>     i think it is still true that architecture can lag the other
>     documents.____
> 
>     __ __
> 
>     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.____
> 
>     [NCW] Abstractly, I think there is general agreement on most of the
>     roles despite the naming of the roles and how they potentially
>     fllow.  That, to me, can be the basis for the architecture, the
>     models that Dave describes are more of the interactions that define
>     the interfaces or communications between the roles.  I’m not
>     convinced yet on the hardship other  than the discussions on the
>     terminology
> 
> 
>     LL____

---

From: Dave Thaler <[email-masked]>
Date: Wed, 16 Oct 2019 19:16:36 +0000

Schönwälder, Jürgen <[email-masked]> wrote:
> Dave takes a minimalist approach, but then he introduces some terms later on 
> in the document (e.g., Endorsement) that may actually belong into the terminology section.

I agree it does belong in terminology, the omission was not intentional.

Dave

---

From: Guy Fedorkow <[email-masked]>
Date: Thu, 17 Oct 2019 01:20:14 +0000

Nancy, thanks for the summary.

  I think the RIV work is depending on the YANG model, but I don't think there's an immediate dependency on the architecture document.  I do think Henk's architecture doc serves an important role of unifying the terminology so it's not all so darn confusing to talk about, but that's an evolving process.

  TEEP, EAT and RIV all share a common set of roles and concepts, centered on claims, evidence and proof, but the plumbing seems sure to be different...  YANG is the obvious path for RIV, but likely of no interest in TEEP.  Reference Manifests are critical for RIV, but probably don't make much sense in some of the other applications.  And I'm sure we'll find lots of other areas where the broad concepts and roles align, but the nuts and bolts differ.  And I can’t really say yet whether RIV is a passport, a background check or some other kind of statement of authority, without some more thought.

 So I'm not sure of the implication of using the name "Profile" to describe these application spaces, but it does seem like a way to achieve as much commonality as possible without imposing artificial requirements on one application because of some aspect of another.

  So I agree that we should carry on with the path of developing the applications while keeping them synchronized where practical with an evolving architectural framework.

  Thanks

/guy

From: RATS <[email-masked]> On Behalf Of Kathleen Moriarty
Sent: Wednesday, October 16, 2019 1:21 PM
To: Nancy Cam-Winget (ncamwing) <[email-masked]>
Cc: [email-masked]; Thomas Hardjono <[email-masked]>; Smith, Ned <[email-masked]>; Laurence Lundblade <[email-masked]>
Subject: Re: [Rats] Question about WG Procedure -- Re: 答复: Use case -> architecture document

On Wed, Oct 16, 2019 at 12:01 PM Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
Comments below:

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 16, 2019 at 08:50
To: "Smith, Ned" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Thomas Hardjono <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Question about WG Procedure -- Re: 答复: Use case -> architecture document

Best regards,
Kathleen

LL

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rats__;!8WoA6RjC81c!QPjU6lR6J46IpURFEcp4c8wKWOkTyCdcWEdS8JSelGCgaNiMA-8LefPfKHUTOPM5tdM$>

--

Best regards,
Kathleen