[{"author": "Ned Smith", "text": "

thanks Muhammad

", "time": "2025-05-02T14:01:26Z"}, {"author": "Kathleen Moriarty", "text": "

Sorry for joining a couple of minutes late

", "time": "2025-05-02T14:03:05Z"}, {"author": "zhang jun", "text": "

i cannot hear the sound

", "time": "2025-05-02T14:04:16Z"}, {"author": "Muhammad Sardar", "text": "

Jun, maybe try rejoining.

", "time": "2025-05-02T14:05:42Z"}, {"author": "zhang jun", "text": "

yogesh, can you speak first, as i have the problem to hear the sound

", "time": "2025-05-02T14:06:15Z"}, {"author": "Muhammad Sardar", "text": "

Jun, you may need to give browser permission. If it still does not work, try this: http://www.ietf.org/how/meetings/issues/

", "time": "2025-05-02T14:07:46Z"}, {"author": "zhang jun", "text": "

still cannot hear anything

", "time": "2025-05-02T14:11:35Z"}, {"author": "Muhammad Sardar", "text": "

perhaps try different browser as a last option?

", "time": "2025-05-02T14:15:39Z"}, {"author": "Henk Birkholz", "text": "

^ this

", "time": "2025-05-02T14:15:59Z"}, {"author": "Hannes Tschofenig", "text": "

The problem is that the draft has not been updated based on the last rounds of comments. It is still very lightweight in terms of content

", "time": "2025-05-02T14:16:26Z"}, {"author": "zhang jun", "text": "

ok now. wrongly connnected with one hdmi cable.

", "time": "2025-05-02T14:16:30Z"}, {"author": "Hannes Tschofenig", "text": "

The document leaves more questions open than it answers

", "time": "2025-05-02T14:16:40Z"}, {"author": "Muhammad Sardar", "text": "

Is Verifier1 for CPU and Verifier2 for GPU?

", "time": "2025-05-02T14:17:00Z"}, {"author": "Henk Birkholz", "text": "

@Usama: yes, for example

", "time": "2025-05-02T14:17:35Z"}, {"author": "zhang jun", "text": "

we have examples in later slides.

", "time": "2025-05-02T14:17:54Z"}, {"author": "Hannes Tschofenig", "text": "

Is performance any concern here?

", "time": "2025-05-02T14:18:14Z"}, {"author": "Henk Birkholz", "text": "

\"per component set\" is a typical scenario

", "time": "2025-05-02T14:18:21Z"}, {"author": "Carsten Bormann", "text": "

Who gets to choose whom LV/V1 consults?

", "time": "2025-05-02T14:18:23Z"}, {"author": "Hannes Tschofenig", "text": "

The draft does not describe how the \"Aggregated Attestation Results\" looks like. How does it look like?

", "time": "2025-05-02T14:19:31Z"}, {"author": "Henk Birkholz", "text": "

@Hannes: depending on the message flow model. AR4SI's Below Zero Trust approach can expedite appraisal across Verifiers

", "time": "2025-05-02T14:20:25Z"}, {"author": "Hannes Tschofenig", "text": "

I do not know what \"AR4SI's Below Zero Trust\" means.

", "time": "2025-05-02T14:21:08Z"}, {"author": "zhang jun", "text": "

the cpu+gpu use case is on next slide

", "time": "2025-05-02T14:21:39Z"}, {"author": "Henk Birkholz", "text": "

@Hannes: this work is architectural, complementary message design depends on that

", "time": "2025-05-02T14:21:48Z"}, {"author": "Kathleen Moriarty", "text": "

From those verifications specific to a policy could then be summarized using the posture assessment draft to convey the result.

", "time": "2025-05-02T14:22:16Z"}, {"author": "Hannes Tschofenig", "text": "

What needs to be standardized here? A new attestation results format?

", "time": "2025-05-02T14:22:17Z"}, {"author": "Hannes Tschofenig", "text": "

New protocols?

", "time": "2025-05-02T14:22:24Z"}, {"author": "Ned Smith", "text": "

I assume they are proposing an informational arch draft

", "time": "2025-05-02T14:22:59Z"}, {"author": "Hannes Tschofenig", "text": "

This was never said

", "time": "2025-05-02T14:23:10Z"}, {"author": "Henk Birkholz", "text": "

@Hannes: https://www.ietf.org/archive/id/draft-ietf-rats-ar4si-08.html

", "time": "2025-05-02T14:23:26Z"}, {"author": "Hannes Tschofenig", "text": "

The document says \"Standards Track\"

", "time": "2025-05-02T14:23:29Z"}, {"author": "Kathleen Moriarty", "text": "

I will read the draft...

", "time": "2025-05-02T14:24:09Z"}, {"author": "Hannes Tschofenig", "text": "

The link to the \"Executive Order on Improving the Nation's Cybersecurity\" is not accessible anymore.

", "time": "2025-05-02T14:26:14Z"}, {"author": "Hannes Tschofenig", "text": "

Is this how Intel Trust Authority works (namely by reaching out to other Verifiers) or is this just an example?

", "time": "2025-05-02T14:27:52Z"}, {"author": "zhang jun", "text": "

https://assets-global.website-files.com/63c54a346e01f30e726f97cf/660e6f03b5f641606bf00258_Seamless%20Attestation%20of%20Intel%20TDX%20and%20NVIDIA%20H100GPUs%20for%20Confidential%20AI%20-%20Yeluri%20OConnor.pdf

", "time": "2025-05-02T14:28:34Z"}, {"author": "Ned Smith", "text": "

I assume TEE is a TD or Enclave or VM - not sure if that is the lead attester or relying party

", "time": "2025-05-02T14:29:31Z"}, {"author": "Kathleen Moriarty", "text": "

@Hannes, yes, as different vendors produce results that Intel has to use consistently.

", "time": "2025-05-02T14:29:40Z"}, {"author": "Ned Smith", "text": "

I assume slide 7 is showing \"cascaded verifier\" model

", "time": "2025-05-02T14:30:43Z"}, {"author": "Muhammad Sardar", "text": "

Agree with Hannes.

", "time": "2025-05-02T14:31:04Z"}, {"author": "Mike Ounsworth", "text": "

\"I believe we are rat-holing on this\"
\n:rofl:
\nIs that not what we do in this WG?

", "time": "2025-05-02T14:31:07Z"}, {"author": "zhang jun", "text": "

some attestation service does not necessary wish to share their golden measurement

", "time": "2025-05-02T14:31:15Z"}, {"author": "Kathleen Moriarty", "text": "

Yes, they meet the specifications in TCGs Reference Integrity Measurements document that aligns to NIST SP-800-193 for Firmware assurance

", "time": "2025-05-02T14:31:34Z"}, {"author": "Kathleen Moriarty", "text": "

The vendors worked together and each implemented it as part of the effort to make Intel Trusted Boot work

", "time": "2025-05-02T14:32:06Z"}, {"author": "Henk Birkholz", "text": "

@Hannes: thx 4 catching the broken us gov url

", "time": "2025-05-02T14:32:38Z"}, {"author": "Henk Birkholz", "text": "

https://www.govinfo.gov/content/pkg/FR-2021-05-17/pdf/2021-10460.pdf

", "time": "2025-05-02T14:32:50Z"}, {"author": "Hannes Tschofenig", "text": "

Here is a big problem: What the European Commission calls Attestation is not what we call attestation.

", "time": "2025-05-02T14:32:59Z"}, {"author": "Henk Birkholz", "text": "

We know

", "time": "2025-05-02T14:33:09Z"}, {"author": "Henk Birkholz", "text": "

We cannot go into every detail here

", "time": "2025-05-02T14:33:32Z"}, {"author": "Hannes Tschofenig", "text": "

This use case is totally not applicable to what we are presenting there.

", "time": "2025-05-02T14:33:32Z"}, {"author": "Kathleen Moriarty", "text": "

Otherwise BitLocker and other such checks on Intel Trust Boot and UEFI would not be consistent (the firmware checks are per vendor as there are differences in firmware and versions.)

", "time": "2025-05-02T14:33:41Z"}, {"author": "Henk Birkholz", "text": "

This usecase is actual set up in the current implementation act and arf

", "time": "2025-05-02T14:34:08Z"}, {"author": "Kathleen Moriarty", "text": "

@Hannes Yes, the term attestation is problematic, but it's late to fix that

", "time": "2025-05-02T14:34:40Z"}, {"author": "Carsten Bormann", "text": "

MCR?

", "time": "2025-05-02T14:34:54Z"}, {"author": "Thomas Fossati", "text": "

@MCR?

", "time": "2025-05-02T14:34:58Z"}, {"author": "Hannes Tschofenig", "text": "

That is not what I am saying, Kathleen.

", "time": "2025-05-02T14:35:02Z"}, {"author": "Yogesh Deshpande", "text": "

Draft for RATS Multi Verifier

", "time": "2025-05-02T14:35:09Z"}, {"author": "Yogesh Deshpande", "text": "

https://www.ietf.org/archive/id/draft-deshpande-rats-multi-verifier-01.html

", "time": "2025-05-02T14:35:10Z"}, {"author": "Hannes Tschofenig", "text": "

The last use case is completely off topic

", "time": "2025-05-02T14:35:20Z"}, {"author": "Henk Birkholz", "text": "

But nice to hear others say that using the term attestation without qualifier is mostly useless today

", "time": "2025-05-02T14:35:30Z"}, {"author": "Henk Birkholz", "text": "

Typically I am that broken record :sweat_smile:

", "time": "2025-05-02T14:35:49Z"}, {"author": "Thanassis Giannetsos", "text": "

@Hannes: yes, definition of attestation attributes is different in EUDI but these are equivalent to reference values of identity attributes...ongoing discussions in ARF is trying to bring the definitions closer

", "time": "2025-05-02T14:35:50Z"}, {"author": "Hannes Tschofenig", "text": "

@Thanassis: I am happy to have an offline conversation to explain you why the scenario is wrong

", "time": "2025-05-02T14:36:48Z"}, {"author": "Mike Ounsworth", "text": "

Mandatory XKCD?
\nhttps://xkcd.com/927/

", "time": "2025-05-02T14:37:43Z"}, {"author": "Henk Birkholz", "text": "

@Hannes: that sound productive

", "time": "2025-05-02T14:37:44Z"}, {"author": "Hannes Tschofenig", "text": "

I think so. Here is my email address: Hannes.Tschofenig@h-brs.de

", "time": "2025-05-02T14:38:37Z"}, {"author": "Muhammad Sardar", "text": "

I guess we should discuss on the list rather than offline conversation.

", "time": "2025-05-02T14:39:08Z"}, {"author": "Hannes Tschofenig", "text": "

Fair enough

", "time": "2025-05-02T14:39:27Z"}, {"author": "Henk Birkholz", "text": "

@Mike: :troll::sweat_smile:

", "time": "2025-05-02T14:39:28Z"}, {"author": "Yogesh Deshpande", "text": "

I agree with Usama!

", "time": "2025-05-02T14:39:49Z"}, {"author": "Deb Cooley", "text": "

or set up a short interim.

", "time": "2025-05-02T14:40:08Z"}, {"author": "Hannes Tschofenig", "text": "

Probably even be better

", "time": "2025-05-02T14:40:22Z"}, {"author": "Kathleen Moriarty", "text": "

We can do a short interim...

", "time": "2025-05-02T14:41:21Z"}, {"author": "Thanassis Giannetsos", "text": "

that would be great

", "time": "2025-05-02T14:41:26Z"}, {"author": "Muhammad Sardar", "text": "

I see that the security consideration section is empty. I would like to see some text in security and privacy considerations on what is the benefit of this approach.

", "time": "2025-05-02T14:43:10Z"}, {"author": "Hannes Tschofenig", "text": "

For that interim meeting I could briefly summarize the Attestation work in the OAuth working group.

", "time": "2025-05-02T14:44:59Z"}, {"author": "Kathleen Moriarty", "text": "

Thank you, Hannes!

", "time": "2025-05-02T14:45:15Z"}, {"author": "Yogesh Deshpande", "text": "

Yes Usama, we would be adding the security consideration

", "time": "2025-05-02T14:45:44Z"}, {"author": "Thanassis Giannetsos", "text": "

we could also expand to the DIF discussions on attestation that are relevant

", "time": "2025-05-02T14:46:39Z"}, {"author": "Yogesh Deshpande", "text": "

But that is not the section to add Benefit of the system, but what are implications for each of the topology and handle the security!

", "time": "2025-05-02T14:46:50Z"}, {"author": "Muhammad Sardar", "text": "

Maybe in introduction. But I am really missing the motivation of this work.

", "time": "2025-05-02T14:47:19Z"}, {"author": "Yogesh Deshpande", "text": "

Sure, let us discuss in the Open Mic, if time permits, happy to go in more detail!

", "time": "2025-05-02T14:47:51Z"}, {"author": "Hannes Tschofenig", "text": "

We had a presentation of the multi-verifier draft in the past with similar comments provided. Unfortunately, these comments have not been addressed in the draft.

", "time": "2025-05-02T14:48:37Z"}, {"author": "Yogesh Deshpande", "text": "

@Hannes That was a different draft which was addressing a slightly different problem, whcih was a deployment issue, this is different problem

", "time": "2025-05-02T14:49:30Z"}, {"author": "Henk Birkholz", "text": "

@Hannes: could you please point to unaddressed comments (or quickly summarize open comments on list)?

", "time": "2025-05-02T14:50:22Z"}, {"author": "Kathleen Moriarty", "text": "

@Yogesh, it may help others to if that is all explained in context of each draft. If Hannes has the question, others may too.

", "time": "2025-05-02T14:50:23Z"}, {"author": "Yogesh Deshpande", "text": "

Sure, let me get more details!

", "time": "2025-05-02T14:51:27Z"}, {"author": "Kathleen Moriarty", "text": "

Thank you!

", "time": "2025-05-02T14:52:35Z"}, {"author": "Hannes Tschofenig", "text": "

Yogesh, here is the presentation you gave last time: https://datatracker.ietf.org/meeting/121/materials/slides-121-rats-handling-multiple-verifiers-in-rats-architecture-01

", "time": "2025-05-02T14:53:08Z"}, {"author": "Hannes Tschofenig", "text": "

@Henk: You can look at the recording/chat/notes of the 121 meeting.

", "time": "2025-05-02T14:53:44Z"}, {"author": "Henk Birkholz", "text": "

I did

", "time": "2025-05-02T14:53:55Z"}, {"author": "Henk Birkholz", "text": "

Well notes... :sweat_smile:

", "time": "2025-05-02T14:54:19Z"}, {"author": "zhang jun", "text": "

@hannes, yogesh is not in the author list of the draft you have listed.

", "time": "2025-05-02T14:54:56Z"}, {"author": "Henk Birkholz", "text": "

It would really help to have specific comments to be addressed on the list

", "time": "2025-05-02T14:54:59Z"}, {"author": "Deb Cooley", "text": "

this is why you need good notes.

", "time": "2025-05-02T14:55:02Z"}, {"author": "Hannes Tschofenig", "text": "

Why is Yogesh then doing the presentation?

", "time": "2025-05-02T14:55:37Z"}, {"author": "zhang jun", "text": "

these are two different drafts

", "time": "2025-05-02T14:56:05Z"}, {"author": "Henk Birkholz", "text": "

Because he does the editorial lead of the new I-D

", "time": "2025-05-02T14:56:15Z"}, {"author": "Hannes Tschofenig", "text": "

Ah. That explains it.

", "time": "2025-05-02T14:57:00Z"}, {"author": "Hannes Tschofenig", "text": "

Maybe that could have been clarified in the presentation. You use the same title \"Multi-Verifier\" with an overlap of authorship.

", "time": "2025-05-02T14:58:02Z"}, {"author": "zhang jun", "text": "

@hannes, these are the two drafts, you can check the difference between them. https://datatracker.ietf.org/doc/draft-deshpande-rats-multi-verifier/

\n

https://datatracker.ietf.org/doc/html/draft-zhang-rats-multiverifiers

", "time": "2025-05-02T14:58:03Z"}, {"author": "Hannes Tschofenig", "text": "

Does this mean that draft-zhang-rats-multiverifiers got replaced by draft-deshpande-rats-multi-verifier

", "time": "2025-05-02T14:58:34Z"}, {"author": "Yogesh Deshpande", "text": "

Yes

", "time": "2025-05-02T14:58:43Z"}, {"author": "Hannes Tschofenig", "text": "

Maybe you could have said that in the presentation

", "time": "2025-05-02T14:58:55Z"}, {"author": "Yogesh Deshpande", "text": "

Sure, good point, I will mention that during Open Mic

", "time": "2025-05-02T14:59:10Z"}, {"author": "Hannes Tschofenig", "text": "

It was super confusing even for someone like me who is following the work in the group

", "time": "2025-05-02T14:59:17Z"}, {"author": "Yogesh Deshpande", "text": "

Agree, need to be clarified here and also in the IETF Madrid!

", "time": "2025-05-02T14:59:54Z"}, {"author": "Henk Birkholz", "text": "

The new I-D was highlighted on the first slide, but speaking that out loud probably would have been smart... Cpt. Hindsight

", "time": "2025-05-02T15:00:07Z"}, {"author": "Mike Ounsworth", "text": "

This attack:
\nimage.png

\n

applies equally to the TLS authentication mechanisms, right? If you have a long-lived TLS session (say 1 year), and the certificate used to authenticate the handshake is revoke (or expires), I doubt that any TLS implementations in the world would notice and kill the session.

\n

I find it odd to place a higher security model on the Attested part compared to the Authentication part.

", "time": "2025-05-02T15:01:44Z"}, {"author": "Henk Birkholz", "text": "

Mike: granted, maybe the issue trancends rats, but it hurts here at minimum

", "time": "2025-05-02T15:03:07Z"}, {"author": "Deb Cooley", "text": "

hybrid, but not actually what we think of as 'hybrid'.

", "time": "2025-05-02T15:04:18Z"}, {"author": "Deb Cooley", "text": "

mixing terminology

", "time": "2025-05-02T15:04:24Z"}, {"author": "Thomas Fossati", "text": "

@Deb, yeah, maybe \u201clayered\"

", "time": "2025-05-02T15:04:52Z"}, {"author": "zhang jun", "text": "

usama, you can have a look at TCG attestation framework, they have a part on the comparison between freshness and recentness, and propose some solution when freshness is not possible.

", "time": "2025-05-02T15:05:14Z"}, {"author": "Thomas Fossati", "text": "

(though, that would also mix terminology \u2014 layered attester\u2026)

", "time": "2025-05-02T15:05:43Z"}, {"author": "Hannes Tschofenig", "text": "

Jun, which document from the TCG are you referring to? The TCG has many documents

", "time": "2025-05-02T15:05:45Z"}, {"author": "Deb Cooley", "text": "

ephemeral key in the certificate verify?????

", "time": "2025-05-02T15:05:59Z"}, {"author": "zhang jun", "text": "

TCG attestation framework (part 1, part 2)

", "time": "2025-05-02T15:06:07Z"}, {"author": "Hannes Tschofenig", "text": "

Thanks, Jun.

", "time": "2025-05-02T15:07:01Z"}, {"author": "zhang jun", "text": "

in section 5.4.1, it has metioned \"Note that there are situations in which the freshness of Evidence cannot be known for certain. In these situations, Verifiers use the recentness of Claims collection as an approximation of freshness. If a Verifier cannot know with certainty whether the state of the Attester is accurately represented by the Claims in Evidence, the Verifier can at least ensure that the Evidence was created as recently as possible, thereby increasing the likelihood of fresh Measurements by the Attester.\"

", "time": "2025-05-02T15:07:50Z"}, {"author": "Mike Ounsworth", "text": "

I guess my point is that it seems natural to me that TLS is broken into \"handshake step\" and \"data transmission step\". You get one handshake per session at the beginning. I don't see this as an attack, but rather just how TLS works; if you want to refresh the auth step, then you need to re-do the handshake (either by starting a new session, or requesting a post-handshake auth).

", "time": "2025-05-02T15:08:02Z"}, {"author": "Carsten Bormann", "text": "

The problem really is binary authentication, when in reality the authentication is authorized by a policy that gets updates.

", "time": "2025-05-02T15:08:46Z"}, {"author": "Hannes Tschofenig", "text": "

I cannot find that document. I am searching through https://trustedcomputinggroup.org/resources/?search=attestation%20framework&

", "time": "2025-05-02T15:09:28Z"}, {"author": "Mike Ounsworth", "text": "

Carsten Bormann said:

\n
\n

The problem really is binary authentication, when in reality the authentication is authorized by a policy that gets updates.

\n
\n

Hmm.
\nThe follow-up question is whether TLS is _really_ designed for continuous authentication use-cases.

", "time": "2025-05-02T15:09:34Z"}, {"author": "zhang jun", "text": "

you need to register as a member of tcg.

", "time": "2025-05-02T15:09:46Z"}, {"author": "Kathleen Moriarty", "text": "

@Deb 15 years at least! Agreed

", "time": "2025-05-02T15:10:23Z"}, {"author": "Hannes Tschofenig", "text": "

Longer: Since the SSL days

", "time": "2025-05-02T15:10:40Z"}, {"author": "Carsten Bormann", "text": "

Mike, I think we'll have to accept the reality that some assertions are non-binary in nature.

", "time": "2025-05-02T15:12:41Z"}, {"author": "Deb Cooley", "text": "

Mike: and as server keys/certs are valid for shorter and shorter times only makes this issue worse.

", "time": "2025-05-02T15:13:38Z"}, {"author": "Deb Cooley", "text": "

But that is a TLS problem, no?

", "time": "2025-05-02T15:13:48Z"}, {"author": "Henk Birkholz", "text": "

Attestation Framework Part 1 will have a public review phase in the foreseeable future

", "time": "2025-05-02T15:13:51Z"}, {"author": "Mike Ounsworth", "text": "

Carsten Bormann said:

\n
\n

Mike, I think we'll have to accept the reality that some assertions are non-binary in nature.

\n
\n

Yes. Good.
\nBut what does that mean for TLS?
\nDo we need to modify the TLS protocol to accomodate this, which is what I think Usama is proposing. Or do we make it the application's problem to track the authz data used in the handshake and kill the session / redo the handshake if that authz data becomes invalid due to policy change?
\nI think I'm arguing for the second, which is already compatible with TLS1.3

", "time": "2025-05-02T15:14:55Z"}, {"author": "Carsten Bormann", "text": "

Killing the session is a bit gross -- the session may still be authorized for some things but not for others. Indicating the quality of the authentication and its shelf life would be more like it.

", "time": "2025-05-02T15:15:51Z"}, {"author": "Mike Ounsworth", "text": "

kill session OR trigger post-handshake auth

", "time": "2025-05-02T15:16:24Z"}, {"author": "Henk Birkholz", "text": "

The latter please

", "time": "2025-05-02T15:16:38Z"}, {"author": "Thomas Fossati", "text": "

doesn\u2019t work in all cases

", "time": "2025-05-02T15:16:46Z"}, {"author": "Thomas Fossati", "text": "

it\u2019s asymmetrical

", "time": "2025-05-02T15:16:58Z"}, {"author": "Carsten Bormann", "text": "

(I'm mostly thinking about this from an IoT point of view, where you want to be sparing with additional handshakes where they are not needed. Not a RATS specific PoV.)

", "time": "2025-05-02T15:17:11Z"}, {"author": "Deb Cooley", "text": "

(and not web POV)

", "time": "2025-05-02T15:17:28Z"}, {"author": "Henk Birkholz", "text": "

Frequency of handshakes definitely is (constrained) environment specific

", "time": "2025-05-02T15:18:22Z"}, {"author": "Mike Ounsworth", "text": "

Deb Cooley said:

\n
\n

(and not web POV)

\n
\n

Right. In a web context; say you are pulling down a very large firmware update over HTTPS. If the server cert becomes invalid part-way through, then I think killing and restarting is actually the correct action because you now no longer trust the partial data you already have, right?

", "time": "2025-05-02T15:18:35Z"}, {"author": "Henk Birkholz", "text": "

Depends also on freshness characteristics of Attester

", "time": "2025-05-02T15:18:56Z"}, {"author": "Kathleen Moriarty", "text": "

We'll need another interim for the follow up as the remaining 10 minutes won't be enough

", "time": "2025-05-02T15:19:44Z"}, {"author": "Hannes Tschofenig", "text": "

Agree, Kathleen.

", "time": "2025-05-02T15:19:54Z"}, {"author": "Henk Birkholz", "text": "

Yes please

", "time": "2025-05-02T15:20:07Z"}, {"author": "Hannes Tschofenig", "text": "

There are a lot of details to talk about here.

", "time": "2025-05-02T15:20:08Z"}, {"author": "Yogesh Deshpande", "text": "

Agree with you Kathleen

", "time": "2025-05-02T15:20:25Z"}, {"author": "Thomas Fossati", "text": "

Mike Ounsworth said:

\n
\n

Deb Cooley said:

\n
\n

(and not web POV)

\n
\n

Right. In a web context; say you are pulling down a very large firmware update over HTTPS. If the server cert becomes invalid part-way through, then I think killing and restarting is actually the correct action because you now no longer trust the partial data you already have, right?

\n
\n

seems like a reasonable policy

", "time": "2025-05-02T15:20:48Z"}, {"author": "Henk Birkholz", "text": "

This Friday timeframe works well, right?

", "time": "2025-05-02T15:20:50Z"}, {"author": "Carsten Bormann", "text": "

Mike: You would use SUIT or some other object security for the very large firmware update anyway...

", "time": "2025-05-02T15:20:53Z"}, {"author": "Hannes Tschofenig", "text": "

Yes, Friday is better

", "time": "2025-05-02T15:20:59Z"}, {"author": "zhang jun", "text": "

usama, for point 2, it is possible when you have the memory sharing.

", "time": "2025-05-02T15:21:08Z"}, {"author": "Thomas Fossati", "text": "

Carsten Bormann said:

\n
\n

Mike: You would use SUIT or some other object security for the very large firmware update anyway...

\n
\n

sure, but you also need to trust your SUIT server to send you the latest available update, no?

", "time": "2025-05-02T15:22:03Z"}, {"author": "Hannes Tschofenig", "text": "

It depends what you call a \"SUIT server\", Thomas

", "time": "2025-05-02T15:22:36Z"}, {"author": "Carsten Bormann", "text": "

Yes. \"Latest\" becomes interesting if the download takes longer than a cert lifetime.

", "time": "2025-05-02T15:22:42Z"}, {"author": "Thomas Fossati", "text": "

Hannes Tschofenig said:

\n
\n

It depends what you call a \"SUIT server\", Thomas

\n
\n

I mean the service that the update agent is supposed to trust as its \"parent\"

", "time": "2025-05-02T15:24:00Z"}, {"author": "Mike Ounsworth", "text": "

Carsten Bormann said:

\n
\n

Yes. \"Latest\" becomes interesting if the download takes longer than a cert lifetime.

\n
\n

@Deb Cooley is right that this question has interesting implications in CA/B land with 14-day certs and TLS sessions that last longer than 14 days. But that's wildly outside the scope of RATS.

", "time": "2025-05-02T15:24:11Z"}, {"author": "Hannes Tschofenig", "text": "

But this is the CA/B Forum Policy and not an IoT PKI policy. So, there is no problem for constrained devices since there certificate lifetimes are in years

", "time": "2025-05-02T15:25:35Z"}, {"author": "Carsten Bormann", "text": "

What expires in a cert? The power to authenticate or the authorization how to use the results of the authentication?
\nWhat do I do with the firmware I'm running while the cert I used to authorize its installation expired?

", "time": "2025-05-02T15:26:20Z"}, {"author": "Mike Ounsworth", "text": "

What expires in a cert is the CA's responsibility to maintain revocation information ... ie past the expiry date, you have no assurance that the cert is not compromised.

", "time": "2025-05-02T15:27:13Z"}, {"author": "Mike Ounsworth", "text": "

To me, where this overlaps with RATS is whether the authentication problem of \"Cert expired / revoked during TLS session\" is the same or different problem from the analogous Attested TLS problem. Does the Attested TLS continuous auth problem need a distinct solution from the long-lived cert-auth problem?

", "time": "2025-05-02T15:28:01Z"}]