Subject: [Rats] how does the Verifier work

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Feb 2021 16:31:37 -0500

In issue https://github.com/ietf-rats-wg/architecture/issues/210
and in quite a number of discussions in the design team, we ratholed on
whether or not we were specifiying a normative description of how verifiers
worked.

In the architecture document we want to specify what goes in to the Verifier
(from the Attester direction!), and what goes out of the Verifier (to the
Replying Party only).
https://www.ietf.org/archive/id/draft-ietf-rats-architecture-09.html#dataflow

We did not want to specify the other arcs (Endorsements, Appraisal Policy for
Verifiers), but we did need to place some requirements on what was possible.

For instance, that Evidence would be signed, and that Verifiers could verify
the signature on it.

The large X diagram at:
  https://www.ietf.org/archive/id/draft-ietf-rats-architecture-09.html#name-claims-encoding-formats

which in many ways started the entire architecture document, remains an
intentional black box from this document.

It seems that there is a desire among some participants to more clearly
articulate how many (but perhaps not all) Verifiers work.  It seems that with
an appropriate initial narrow scope that such a document could be written by
the IETF.   For pretty much all the cases of "perhaps not all", then it is
probably the case that the specifics will be very specific to a vertical, and
should be written in that technical consortium outside of the IETF.

This email is basically the concluding recommendation of the design team: we
aren't going to put this into the architecture document, but we don't object
if someone else wants to write _Architecture of common Verifiers_, or some
equivalently titled document.

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Feb 2021 16:38:59 -0500

In https://github.com/ietf-rats-wg/architecture/issues/162 it was argued that
we needed to be clear that:

  "Endorsements should have confidentiality protection when carrying
  symmetric verification keys. "

but, many of the Architecture Design Team didn't feel that the architecture
was intended to provide any kind of specification on Endorsements.
Within the dataflow diagram:
  https://www.ietf.org/archive/id/draft-ietf-rats-architecture-09.html#dataflow
  (attached below, for those who use a fixed-width font)
That only the "Evidence" and "Attestation Results", which are between
solid-lined entities was really in scope.  That the rest was for future
documents.

We felt that this requirement went into the Design Requirements which the
IETF usually tries to stay out of, sticking to Functional Requirements.
Further, we felt that the Functional Requirements in the RATS Architecture
should not even cover Endorsements.
At least, not in this edition of the document.

The recommendation is that those who need to do Endorsements with symmetric
verifification keys should write another document in which this topic would
get adequately dealt with.

  ************   *************    ************    *****************
  * Endorser *   * Reference *    * Verifier *    * Relying Party *
  ************   * Value     *    *  Owner   *    *  Owner        *
     |           * Provider  *    ************    *****************
     |           *************          |                 |
     |                  |               |                 |
     |Endorsements      |Reference      |Appraisal        |Appraisal
     |                  |Values         |Policy           |Policy for
     |                  |               |for              |Attestation
     .-----------.      |               |Evidence         |Results
                 |      |               |                 |
                 |      |               |                 |
                 v      v               v                 |
               .---------------------------.              |
        .----->|          Verifier         |------.       |
        |      '---------------------------'      |       |
        |                                         |       |
        |                              Attestation|       |
        |                              Results    |       |
        | Evidence                                |       |
        |                                         |       |
        |                                         v       v
  .----------.                                .---------------.
  | Attester |                                | Relying Party |
  '----------'                                '---------------'

---

From: Henk Birkholz <[email-masked]>
Date: Sun, 7 Feb 2021 15:51:16 +0100

Hi Michael,

thank you for putting some attention on this reoccurring pattern that we 
encountered in discussions a few times. I agree with the notion that the 
scope of the architecture document now reached its intended limit and it 
will we be completed with its current content and remaining open issues 
(aka "closing the mic again"). Anything else will have to go in separate 
documents. "The architecture of the Verifier" is one prominent thing we 
should look into next. There are some corresponding and reoccurring 
requirements we will have to take into account, I think. Maybe it helps 
if I elaborate a bit on two major topics that came up repeatedly:

* Implementing RATS requires some kind of defined management logistics 
that effectively make Conceptual Messages move around. For Evidence, we 
have https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/ 
to take on that task, but there are "other arcs in the diagrams" that 
point to the Verifier, too.

* Shedding some light into how appraisal procedures conducted by 
Verifiers actually look like will be very useful to implementers. Some 
experts are already implementing: I'd like to point out this quite open 
and inclusive effort https://github.com/veraison/veraison as an example 
that we can build on.

My expectation is that some of the presentations at the next (virtual) 
meeting will touch these topics already and if time permits, maybe we 
can plan for explicit discussion on these topics.

Viele Grüße,

Henk

On 05.02.21 22:31, Michael Richardson wrote:
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 8 Feb 2021 18:32:29 +0000

+1 "Endorsements with symmetric verification keys should write another document"

This is a reason to re-charter. It would allow drafts that address the corner of the diagram that was ruled out of scope during chartering discussion to be written and adopted as a way to clarify content that isn't appropriate to include in an architecture draft.

-Ned

On 2/5/21, 1:40 PM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 8 Feb 2021 12:35:48 -0800

So the proposal is to say nothing about when/if Endorsements should have confidentially protection in the architecture document, right?  This leaves it up to the designer/implementor/user of symmetric verification keys to figure this out on their own. I’m fine with this.

(Note that I was only suggesting a security considerations statement like “if endorsements carry symmetric keys for verification the endorsements should have confidentially protection”.  Given that the UCCS draft has paragraphs about integrity and confidentially, then a statement like this seems appropriate).

I'm happy it is closed.

LL

> On Feb 8, 2021, at 10:32 AM, Smith, Ned <[email-masked]> wrote:
>

---

From: Simon Frost <[email-masked]>
Date: Wed, 10 Feb 2021 11:43:17 +0000

> * Shedding some light into how appraisal procedures conducted by Verifiers actually look like will be very useful to implementers. Some experts are already implementing: I'd like to point out this quite open and inclusive effort https://github.com/veraison/veraison as an example that we can build on.

Thanks for the mention Henk, the Veraison project is fairly new but I've been meaning to send a FYI briefing to the RATS group. There is an overlap in the Veraison core team with RATS discussions (myself & Thomas Fossati), hence there should be consistency with WG output and terminology. The background to the project was some prototyping work done at Arm on how a Verification Service would be constructed. Discussions on what the scope of such a service might be revealed that the reality of diverse supply chains and ecosystems make creating a unified service solution unlikely. Instead the Veraison project concentrates on implementing components that can be used to build verification services.  We regard this as an industry problem rather than just for the Arm ecosystem, hence there is an emphasis on flexibility and extensibility within the project. Initial targets for support are EAT (PSA profile) and DICE. If this is an area of interest then the project welcomes feedback & collaboration https://github.com/veraison/veraison/blob/main/docs/project-overview.md.

Thanks
Simon

-----Original Message-----
From: Henk Birkholz <[email-masked]>
Sent: 07 February 2021 14:51
To: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Rats] how does the Verifier work

Hi Michael,

thank you for putting some attention on this reoccurring pattern that we encountered in discussions a few times. I agree with the notion that the scope of the architecture document now reached its intended limit and it will we be completed with its current content and remaining open issues (aka "closing the mic again"). Anything else will have to go in separate documents. "The architecture of the Verifier" is one prominent thing we should look into next. There are some corresponding and reoccurring requirements we will have to take into account, I think. Maybe it helps if I elaborate a bit on two major topics that came up repeatedly:

* Implementing RATS requires some kind of defined management logistics that effectively make Conceptual Messages move around. For Evidence, we have https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/
to take on that task, but there are "other arcs in the diagrams" that point to the Verifier, too.

* Shedding some light into how appraisal procedures conducted by Verifiers actually look like will be very useful to implementers. Some experts are already implementing: I'd like to point out this quite open and inclusive effort https://github.com/veraison/veraison as an example that we can build on.

My expectation is that some of the presentations at the next (virtual) meeting will touch these topics already and if time permits, maybe we can plan for explicit discussion on these topics.

Viele Grüße,

Henk

On 05.02.21 22:31, Michael Richardson wrote:
> and in quite a number of discussions in the design team, we ratholed
> on whether or not we were specifiying a normative description of how
> verifiers worked.
>
> In the architecture document we want to specify what goes in to the
> Verifier (from the Attester direction!), and what goes out of the
> Verifier (to the Replying Party only).
> We did not want to specify the other arcs (Endorsements, Appraisal
> Policy for Verifiers), but we did need to place some requirements on what was possible.
>
> For instance, that Evidence would be signed, and that Verifiers could
> verify the signature on it.
>
> The large X diagram at:
>
> which in many ways started the entire architecture document, remains
> an intentional black box from this document.
>
> It seems that there is a desire among some participants to more
> clearly articulate how many (but perhaps not all) Verifiers work.  It
> seems that with an appropriate initial narrow scope that such a document could be written by
> probably the case that the specifics will be very specific to a
> vertical, and should be written in that technical consortium outside of the IETF.
>
> This email is basically the concluding recommendation of the design
> team: we aren't going to put this into the architecture document, but
> we don't object if someone else wants to write _Architecture of common
> Verifiers_, or some equivalently titled document.
>
> --

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 Feb 2021 14:22:36 -0500

Maybe something should be said in the Security Considerations that the design in this document does not cover Endorsements should have confidentially protection such as ones that employ symmetric keys.

Russ

> On Feb 8, 2021, at 3:35 PM, Laurence Lundblade <[email-masked]> wrote:
>