[{"author": "Thomas Fossati", "text": "

Hi, I am your friendly zulip relay, if you want me to forward your questions to the mic, please prefix your message with \"MIC\"

", "time": "2023-11-08T08:37:41Z"}, {"author": "Kathleen Moriarty", "text": "

Would this fit more with SCITT? It seems to be pulling together supply chain details, but I need to read the draft.

", "time": "2023-11-08T08:44:54Z"}, {"author": "Kathleen Moriarty", "text": "

MIC the above

", "time": "2023-11-08T08:45:17Z"}, {"author": "A.J. Stein", "text": "

I will also have to read the document and will give feedback but this seems just like a misconception about name.

", "time": "2023-11-08T08:52:20Z"}, {"author": "Thomas Fossati", "text": "

@A.J. Stein agree, it should be called \"Concise Bill of Manifests\"

", "time": "2023-11-08T08:53:57Z"}, {"author": "Henk Birkholz", "text": "

CoBOM is just a list of required CoRIMs in the end, as a convenience to the consumer

", "time": "2023-11-08T08:54:50Z"}, {"author": "Thomas Fossati", "text": "

that would be sufficient to clear the scoping confusion

", "time": "2023-11-08T08:54:59Z"}, {"author": "Henk Birkholz", "text": "

it is a tiny part of a CoRIM

", "time": "2023-11-08T08:55:00Z"}, {"author": "Henk Birkholz", "text": "

CoRIM can be opaque SCITT statements

", "time": "2023-11-08T08:55:23Z"}, {"author": "Ned Smith", "text": "

(no hat) CoBOM is a way to prune which corims to evaluate.

", "time": "2023-11-08T08:55:46Z"}, {"author": "Henk Birkholz", "text": "

@Ned, yes. A verifier is probably in charge of appraising the evidence of several device(compositions)

", "time": "2023-11-08T08:56:35Z"}, {"author": "Nancy Cam-Winget", "text": "

(no hat) I still do not understand the compression optimizations and the narrowness of BOMs then. So understandting the use cases that drive this requirement (e.g. examples) would be of value

", "time": "2023-11-08T08:57:28Z"}, {"author": "Henk Birkholz", "text": "

a diagram will help :-)

", "time": "2023-11-08T08:57:46Z"}, {"author": "Steve Lasker", "text": "

Per the CoBOM conversation:
\nI heard two aspects:

\n\n

Some examples might help, and more clarification if you're suggesting the existing SBOM formats should adopt CoBOM, or this is in parallel.

", "time": "2023-11-08T08:59:49Z"}, {"author": "Nancy Cam-Winget", "text": "

diagram helps, but examples of how this would get used would be better

", "time": "2023-11-08T09:00:01Z"}, {"author": "Wei Pan", "text": "

CoBOM, the name itself, seems hard to be easily understood as customized set of CoRIM

", "time": "2023-11-08T09:01:33Z"}, {"author": "Thomas Fossati", "text": "

@Hannes Tschofenig regarding server support of CBOR-based stuff, we have an open-source implementation of CoRIM in go which is quite suitable for unconstrained web services

", "time": "2023-11-08T09:03:27Z"}, {"author": "Thomas Fossati", "text": "

it's a matter of tooling

", "time": "2023-11-08T09:03:38Z"}, {"author": "Yogesh Deshpande", "text": "

I agree the most appropriate full form for CoBOM is Concise Bill of Manifests

", "time": "2023-11-08T09:04:08Z"}, {"author": "Wei Pan", "text": "

Yogesh Deshpande \u53d1\u8a00\u9053\uff1a

\n
\n

I agree the most appropriate full form for CoBOM is Concise Bill of Manifests

\n
\n

Manifest is better. But the abbreviation BOM is still a little confusing with the Bill of Materials.

", "time": "2023-11-08T09:09:07Z"}, {"author": "Henk Birkholz", "text": "

@Wei, yeah you said that before and I we can be better :-)

", "time": "2023-11-08T09:09:17Z"}, {"author": "Wei Pan", "text": "

:+1:

", "time": "2023-11-08T09:11:11Z"}, {"author": "Henk Birkholz", "text": "

@Nancy, we'll include some edn now that it is pretty stable.

", "time": "2023-11-08T09:11:15Z"}, {"author": "Yogesh Deshpande", "text": "

We will work on a new name to our cool stuff :)

", "time": "2023-11-08T09:11:57Z"}, {"author": "Kathleen Moriarty", "text": "

I've read the draft

", "time": "2023-11-08T09:15:27Z"}, {"author": "Monty Wiseman", "text": "

I'll contribute

", "time": "2023-11-08T09:20:27Z"}, {"author": "A.J. Stein", "text": "

It will be annoying to walk to the mic: I read draft-ftbs-rats-msg-wrap draft last night (per my obligation from 117), but I am new and I don't have a sense if it is \"ready.\" I found no major issues, but had to review associated specs recursively, so I gave no opinion. (Forgive me, Henk.)

", "time": "2023-11-08T09:26:29Z"}, {"author": "Thomas Fossati", "text": "

A.J. Stein said:

\n
\n

It will be annoying to walk to the mic: I read draft-ftbs-rats-msg-wrap draft last night (per my obligation from 117),

\n
\n

thanks!

\n
\n

but I am new and I don't have a sense if it is \"ready.\" I found no major issues, but had to review associated specs recursively, so I gave no opinion. (Forgive me, Henk.)

\n
\n

no worries, this will be assessed separately after adoption

", "time": "2023-11-08T09:32:20Z"}, {"author": "Thomas Fossati", "text": "

Hi Monty Wiseman, clarification:

\n
\n

I'll contribute

\n
\n

what is the target of your contribution? CoRIM, CMW, or other?

", "time": "2023-11-08T09:34:21Z"}, {"author": "Dave Thaler", "text": "

See minutes from IETF 117 at https://datatracker.ietf.org/meeting/117/materials/minutes-117-rats-00

", "time": "2023-11-08T09:38:05Z"}, {"author": "Dave Thaler", "text": "

Henk: Request call for adoption by RATS WG
\nNed: question regarding COSE and epoch markers and its relation and influence to signature formats, does that draft specify anything?
\nHenk: recommend but not require COSE but will potentially address this as a COSE profiling problem.
\nNed: is there a clear demarcation line about what the COSE WG and the RATS WG would work on?
\nHenk: Not yet (my answer, not COSE WG's official answer)
\nKathleen: ok to leave this slightly ambiguous so long as we have the appropriate cross-review when the time comes.
\nDave Thaler: reviewed the document and 90% of this document is not specific to RATS, why is it applicable here?
\nHenk: the use case of freshness is important in the context of RATS and the expertise on freshness in regards to attestion are in this working group.
\nDaveT: Suggestion: this go to COSE flagged for RATS expert review.
\nKathleen: Suggestion: get the expert opinions you need from this room on the 10% that pertains to RATS, then send it over to COSE.

", "time": "2023-11-08T09:38:24Z"}, {"author": "A.J. Stein", "text": "

What is RedFish in the attestation local and remote slide in the diagram on the right, where it says JSON/RedFish? (And feel better, Kathleen.)

", "time": "2023-11-08T09:43:34Z"}, {"author": "Monty Wiseman", "text": "

Local Attestation is when a policy is enforced by the TPM's policies

", "time": "2023-11-08T09:52:47Z"}, {"author": "A.J. Stein", "text": "

I have not read this draft but I will today or very soon, I look forward to it. I skimmed and have some feedback I can take to list. Excellent presentation Kathleen, and embarrassed I miss this at 117.

", "time": "2023-11-08T09:52:49Z"}, {"author": "Monty Wiseman", "text": "

Local attestation is also called \"implicit\" attestation

", "time": "2023-11-08T09:53:32Z"}, {"author": "Monty Wiseman", "text": "

I will contribute

", "time": "2023-11-08T09:53:46Z"}, {"author": "Henk Birkholz", "text": "

ah, implicit attestation. yeah - that makes sense. local appraisal with no external exposure of that evidence

", "time": "2023-11-08T09:57:06Z"}, {"author": "Michael Richardson", "text": "

I found there were too many TLAs in the attestation sets that I didn't know, so I couldn't read the document. It also means I probably lack the background to understand it.

", "time": "2023-11-08T09:57:08Z"}, {"author": "Kathleen Moriarty", "text": "

Thank you, Monty!

", "time": "2023-11-08T09:59:33Z"}, {"author": "Kathleen Moriarty", "text": "

Michael - that may be the references to other standards documents that just specify an expected configuration level

", "time": "2023-11-08T10:00:17Z"}, {"author": "Kathleen Moriarty", "text": "

Being able to communicate what was tested for posture assurance of firmware, OS, applications is the goal

", "time": "2023-11-08T10:01:04Z"}, {"author": "Kohei Isobe", "text": "

Fips / CC is endorsement?

", "time": "2023-11-08T10:01:25Z"}, {"author": "Brendan Moran", "text": "

In 2018, I brought the SUIT manifest, ASN.1 encoded, to the IETF. I was told, unequivocally, \"No new ASN.1\"
\nWhy is this special?

", "time": "2023-11-08T10:01:29Z"}, {"author": "Kathleen Moriarty", "text": "

A.J. - Thank you! You can ignore the RedFish note on the slide, I can explain though another time - just a RESTful protocol used for system management by some systems.

", "time": "2023-11-08T10:02:51Z"}, {"author": "Kathleen Moriarty", "text": "

I look forward to your feedback and contributions.

", "time": "2023-11-08T10:03:19Z"}, {"author": "Michael Richardson", "text": "

Brendan Moran said:

\n
\n

In 2018, I brought the SUIT manifest, ASN.1 encoded, to the IETF. I was told, unequivocally, \"No new ASN.1\"
\nWhy is this special?

\n
\n

SUIT manifests are not processed by things that already have a ton of ASN.1, and are reluctant to bring in new encoders. I didn't find the argument very persuasive myself, btw.

", "time": "2023-11-08T10:03:49Z"}, {"author": "Brendan Moran", "text": "

At the time, the expectation was that they'd consume certificates, which were ASN.1 encoded, so they were, in fact, processing lots of ASN.1, which was the reason for that design choice. It wasn't good enough then. Why is it good enough now?

", "time": "2023-11-08T10:05:32Z"}, {"author": "Muhammad Sardar", "text": "

Just to clarify, I am not against the draft. I am saying TEE terminology does not fit here.

", "time": "2023-11-08T10:07:31Z"}, {"author": "Carl Wallace", "text": "

Re: maintaining EAT semantics, there're some misalignments in the current draft.

", "time": "2023-11-08T10:08:02Z"}, {"author": "Dave Thaler", "text": "

Queue is closed so putting it here... we did X.509 because OPC-UA carries X.509 certs and we needed to do attesttion with OPC-UA. We didn't want to add a whole new parser and do embedding of something else, which was unnatural and comparatively bug prone.

", "time": "2023-11-08T10:09:53Z"}, {"author": "Brendan Moran", "text": "

That was exactly the argument I used in 2018 for ASN.1 SUIT. It wasn't good enough then...

", "time": "2023-11-08T10:10:34Z"}, {"author": "Brendan Moran", "text": "

I mean, I can dig out the recording if you really want

", "time": "2023-11-08T10:11:15Z"}, {"author": "Thomas Fossati", "text": "

RFC 9334 figure 9 (the \"bow-tie\" diagram) has X.509 as one of the input formats. It looks to me this is perfectly in scope for RATS

", "time": "2023-11-08T10:11:40Z"}, {"author": "Carl Wallace", "text": "

The problem with that argument is the CSR format is format agnostic (correctly) and it's difficult to see where a CA can avoid CBOR across the board. In CA augmentation work I've done, we ran into CBOR needs since 2018. But there are ASN.1 formats already too, this is just another one.

", "time": "2023-11-08T10:11:45Z"}, {"author": "Brendan Moran", "text": "

Like I said, I was told \"no new ASN.1\" Why is that rule being changed?

", "time": "2023-11-08T10:12:17Z"}, {"author": "Dave Thaler", "text": "

@Brendan Moran SUIT isn't something you need to slot into existing authentication mechanisms in protocols. Attestation is.

", "time": "2023-11-08T10:12:46Z"}, {"author": "Michael Richardson", "text": "

Brendan Moran said:

\n
\n

At the time, the expectation was that they'd consume certificates, which were ASN.1 encoded, so they were, in fact, processing lots of ASN.1, which was the reason for that design choice. It wasn't good enough then. Why is it good enough now?

\n
\n

Let me repeat, that I still don't find the argument very convincing, but there are lots of non-IETF cats to heard. I also think that this is step one of a larger effort that might come back around to be CBOR. I'd also have been really annoyed if SUIT had been ASN.1 based. I believe it would have been a market failure.

", "time": "2023-11-08T10:12:47Z"}, {"author": "Dave Thaler", "text": "

+1 to Thomas F.

", "time": "2023-11-08T10:13:18Z"}, {"author": "Henk Birkholz", "text": "

@Carl asn.1 first, then cmw? Or both in the same I-D?

", "time": "2023-11-08T10:13:20Z"}, {"author": "Carl Wallace", "text": "

@Henk Birkholz I don't follow the question.

", "time": "2023-11-08T10:14:10Z"}, {"author": "Brendan Moran", "text": "

SUIT does need to fit existing authentication mechanisms. Specifically, key delegation by certificates. At the time, there were NO COSE-based certificate mechanisms.

", "time": "2023-11-08T10:14:56Z"}, {"author": "Henk Birkholz", "text": "

I feel that the \"non-asn.1\" attitude is really going away in the last 3 years

", "time": "2023-11-08T10:15:18Z"}, {"author": "Henk Birkholz", "text": "

some CA are more open to CBOR encodiings than others I'd say

", "time": "2023-11-08T10:15:44Z"}, {"author": "Brendan Moran", "text": "

IMO, these HSM vendors should be engaging with the efforts in CBOR certificates, rather than ASN.1 attestation.

", "time": "2023-11-08T10:16:22Z"}, {"author": "Henk Birkholz", "text": "

so when we do \"new evidence formats\" in asn.1 today they might be just extras steps towords cmw conveyed evidence

", "time": "2023-11-08T10:16:24Z"}, {"author": "Brendan Moran", "text": "

This draft pushes things in the wrong direction.

", "time": "2023-11-08T10:16:31Z"}, {"author": "Carl Wallace", "text": "

got it. no argument. my comments on the draft were in the spirit that this work is going to proceed and trying to tighten it up. some CAs will support CBOR, no doubt.

", "time": "2023-11-08T10:16:33Z"}, {"author": "Carl Wallace", "text": "

whether or not this draft exists, CAs will have to deal with ASN.1 formats too though.

", "time": "2023-11-08T10:17:30Z"}, {"author": "Henk Birkholz", "text": "

wrt to CAs I have more patience than usually ;-)

", "time": "2023-11-08T10:18:08Z"}, {"author": "Michael Richardson", "text": "

Brendan Moran said:

\n
\n

This draft pushes things in the wrong direction.

\n
\n

Yes, it sure seems to. The document parrots some EAT claims, so it seems that it should be trivial to turn it into EAT, and I think that once adopted, we should add EAT as a second choice. But, I also see that bringing the HSM vendors into the IETF is a good step.

", "time": "2023-11-08T10:27:22Z"}, {"author": "Carl Wallace", "text": "

Probably UCCS is the right thing as a peer option

", "time": "2023-11-08T10:31:31Z"}]