Subject: [Rats] DISCUSS on Canonical Event Log reference affects multiple drafts

From: Roman Danyliw <[email-masked]>
Date: Tue, 8 Feb 2022 14:53:02 +0000

Hi!

Summary: draft-ietf-rats-tpm-based-network-device-attest has a DISCUSS from last week's telechat.  draft-ietf-rats-yang-tpm-charra is going to have the same issue.  What should we do?

Draft-ietf-rats-tpm-based-network-device-attest was reviewed at the telechat last week (Feb 3 2022).  It yielded at DISCUSS on the Canonical Event Log reference.

Ballot email: https://mailarchive.ietf.org/arch/msg/rats/MaB18pOu50eLNsw4d8sB4F4ht9g/

Datatracker link: https://datatracker.ietf.org/doc/draft-ietf-rats-tpm-based-network-device-attest/ballot/

==[ relevant DISCUSS text ]==

Something of a process question, but in §2.3 we refer to [Canonical-Event-Log] in a normative manner ("MUST be formatted according to ..."), but the referenced document is marked as "draft" and "work in progress", with warning that "Readers should not design products based on this document".  Are we planning to hold publication of this document until the TCG dependency is finalized?

==[ end ]==

The specific reference in question from draft-ietf-rats-tpm-based-network-device-attest-11 is:

   [Canonical-Event-Log]
              Trusted Computing Group, "DRAFT Canonical Event Log Format
              Version: 1.0, Revision: .30", December 2020,
              <https://www.trustedcomputinggroup.org/wp-content/uploads/
              TCG_IWG_CEL_v1_r0p30_13feb2021.pdf>.

draft-ietf-rats-yang-tpm-charra-13 is scheduled to be on the March 3 telechat.  This document also has the same normative reference and will also face the same issue:

   [ima-log]  "Canonical Event Log Format, Section 4.3", n.d.,
              <https://www.trustedcomputinggroup.org/wp-content/uploads/
              TCG_IWG_CEL_v1_r0p30_13feb2021.pdf>.

I would also expect a bit more push back since charra is to be a proposed standard (as opposed to information in the draft-ietf-rats-tpm-based-network-device-attest).

Is there a final version of this TCG document?  I found a slightly newer version at https://trustedcomputinggroup.org/wp-content/uploads/TCG_IWG_CEL_v1_r0p35_11july2021.pdf (it is still roughly marked as draft just like the "v1_r0p30_13feb2021" version).  Can we find out the expected timeline of publication of this document by the TCG (if at all)?

Thanks,
Roman

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 8 Feb 2022 15:37:33 +0000

I think on charra we can await Guy's current investigation for RIV on when the TCG log becomes official.  

>From the beginning we knew we had this reference dependency.  If it turns out the TCG will not publish soon, we could always fall back to older IMA references.  The content is the same.  But referencing TCG is better, so it is worth a little wait.

Eric

> Hi!
> 
> Summary: draft-ietf-rats-tpm-based-network-device-attest has a DISCUSS from
> last week's telechat.  draft-ietf-rats-yang-tpm-charra is going to have the same
> issue.  What should we do?
> 
> Draft-ietf-rats-tpm-based-network-device-attest was reviewed at the telechat
> last week (Feb 3 2022).  It yielded at DISCUSS on the Canonical Event Log
> reference.
> 
> Ballot email:
> https://mailarchive.ietf.org/arch/msg/rats/MaB18pOu50eLNsw4d8sB4F4ht9g/
> 
> Something of a process question, but in §2.3 we refer to [Canonical-Event-Log]
> in a normative manner ("MUST be formatted according to ..."), but the
> referenced document is marked as "draft" and "work in progress", with warning
> that "Readers should not design products based on this document".  Are we
> planning to hold publication of this document until the TCG dependency is
> finalized?
> 
> ==[ end ]==
> 
> draft-ietf-rats-yang-tpm-charra-13 is scheduled to be on the March 3 telechat.
> This document also has the same normative reference and will also face the
> same issue:
> 
> I would also expect a bit more push back since charra is to be a proposed
> standard (as opposed to information in the draft-ietf-rats-tpm-based-network-
> device-attest).
> 
> Is there a final version of this TCG document?  I found a slightly newer version at
> https://trustedcomputinggroup.org/wp-
> content/uploads/TCG_IWG_CEL_v1_r0p35_11july2021.pdf (it is still roughly
> marked as draft just like the "v1_r0p30_13feb2021" version).  Can we find out
> the expected timeline of publication of this document by the TCG (if at all)?
> 
> Thanks,
> Roman
> 
> 
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 10 Feb 2022 16:32:43 +0100

Hi Roman,

a quick inquiry about the Canonical Event Log Format status yielded an 
optimistic projection. Pending any concerns raised by the TCG BoD in the 
last steps the draft could see the light of publication even before the 
I-D cut-off date.

Fingers crossed. In the worst case scenario, it seems that affected I-D 
swill not have to simmer in auth48 for too long. I'd say, press the buttons!

Viele Grüße,

Henk

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 10 Feb 2022 17:44:09 +0000

Hi Henk!

> -----Original Message-----
> From: RATS <[email-masked]> On Behalf Of Henk Birkholz
> Sent: Thursday, February 10, 2022 10:33 AM
> To: Roman Danyliw <[email-masked]>; [email-masked]
> Subject: Re: [Rats] DISCUSS on Canonical Event Log reference affects multiple
> drafts
> 
> Hi Roman,
> 
> optimistic projection. Pending any concerns raised by the TCG BoD in the last
> steps the draft could see the light of publication even before the I-D cut-off
> date.

Thanks for the update.

> Fingers crossed. In the worst case scenario, it seems that affected I-D swill not
> have to simmer in auth48 for too long. I'd say, press the buttons!

To clarify the process, these documents wouldn't make it to AUTH48 (which is with the RFC Editor).  Since the sticking point is an external reference, there is no concept of a MISREF state with the RCFEd.  RIV will continue to sit in IESG Evaluation with a DISCUSS.  If it takes longer than IETF 113 when the AD turn-over happens, it will lose the needed position to pass.  The question is whether to pull charra from the upcoming IESG telechat (Mar-3).  Generally, advancing a document which is not "done" (i.e., is known to get a DISCUSS) is bad form as it blocks agenda time (which is capped as a particular page count).  Let's watch this carefully as we closer to the date.

Roman

> > Summary: draft-ietf-rats-tpm-based-network-device-attest has a DISCUSS
> from last week's telechat.  draft-ietf-rats-yang-tpm-charra is going to have the
> same issue.  What should we do?
> >
> > Datatracker link:
> > https://datatracker.ietf.org/doc/draft-ietf-rats-tpm-based-network-dev
> > ice-attest/ballot/
> >
> > Something of a process question, but in §2.3 we refer to [Canonical-Event-
> Log] in a normative manner ("MUST be formatted according to ..."), but the
> referenced document is marked as "draft" and "work in progress", with
> warning that "Readers should not design products based on this document".
> Are we planning to hold publication of this document until the TCG dependency
> is finalized?
> >
> > ==[ end ]==
> >
> > draft-ietf-rats-yang-tpm-charra-13 is scheduled to be on the March 3
> telechat.  This document also has the same normative reference and will also
> face the same issue:
> >
> > Is there a final version of this TCG document?  I found a slightly newer version
> at https://trustedcomputinggroup.org/wp-

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 11 Feb 2022 12:28:46 +0100

Hi Roman,

Okay - it seems that I am also easily confused by RFC 7322. I actually 
thought it was pretty clear on that, but obviously I am reading it 
wrong. Thanks, Roman!

Yes, please let's watch that progress carefully. On Feb 25th we'll know 
more. Maybe pushing it to IESG telechat 2022-03-10 is the sensible 
choice? That's before IETF 113 and has a lesser chance of wasting IESG 
cycles.

Viele Grüße,

Henk

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 11 Feb 2022 14:50:19 +0000

Hi Henk!

> From: Henk Birkholz <[email-masked]>
> Sent: Friday, February 11, 2022 6:29 AM
> Okay - it seems that I am also easily confused by RFC 7322. I actually thought it
> was pretty clear on that, but obviously I am reading it wrong. Thanks, Roman!
> 
> Yes, please let's watch that progress carefully. On Feb 25th we'll know more.
> Maybe pushing it to IESG telechat 2022-03-10 is the sensible choice? That's
> before IETF 113 and has a lesser chance of wasting IESG cycles.

Good idea.  I've moved it to the 2022-03-10 telechat as suggested.

One thing I will ask in advance is that a team be ready to review and resolve the IESG feedback as quickly as possible.  Since the new IESG will be seated at IETF 113, some of the ballots required to approve this document will expire.

Roman

> >> Subject: Re: [Rats] DISCUSS on Canonical Event Log reference affects
> >> multiple drafts
> >>
> >> Hi Roman,
> >>
> >> a quick inquiry about the Canonical Event Log Format status yielded
> >> an optimistic projection. Pending any concerns raised by the TCG BoD
> >> in the last steps the draft could see the light of publication even
> >> before the I-D cut-off date.
> >
> > Thanks for the update.
> >
> >> Fingers crossed. In the worst case scenario, it seems that affected
> >> I-D swill not have to simmer in auth48 for too long. I'd say, press the
> buttons!
> >
> > To clarify the process, these documents wouldn't make it to AUTH48 (which is
> with the RFC Editor).  Since the sticking point is an external reference, there is
> no concept of a MISREF state with the RCFEd.  RIV will continue to sit in IESG
> Evaluation with a DISCUSS.  If it takes longer than IETF 113 when the AD turn-
> over happens, it will lose the needed position to pass.  The question is whether
> to pull charra from the upcoming IESG telechat (Mar-3).  Generally, advancing a
> document which is not "done" (i.e., is known to get a DISCUSS) is bad form as it
> blocks agenda time (which is capped as a particular page count).  Let's watch
> this carefully as we closer to the date.
> >
> > Roman
> >
> >> Viele Grüße,
> >>
> >> Henk
> >>
> >>
> >> from last week's telechat.  draft-ietf-rats-yang-tpm-charra is going
> >> to have the same issue.  What should we do?
> >>>
> >> last week (Feb 3 2022).  It yielded at DISCUSS on the Canonical Event
> >> Log reference.
> >>>
> >>> Ballot email:
> >>> https://mailarchive.ietf.org/arch/msg/rats/MaB18pOu50eLNsw4d8sB4F4ht
> >>> 9g
> >>> /
> >>>
> >>> Datatracker link:
> >> Log] in a normative manner ("MUST be formatted according to ..."),
> >> but the referenced document is marked as "draft" and "work in
> >> progress", with warning that "Readers should not design products based on
> this document".
> >> Are we planning to hold publication of this document until the TCG
> >> dependency is finalized?
> >>>
> >>> ==[ end ]==
> >>>
> >>> The specific reference in question from
> >>> draft-ietf-rats-tpm-based-network-
> >> device-attest-11 is:
> >>>
> >>>      [Canonical-Event-Log]
> >> telechat.  This document also has the same normative reference and
> >> will also face the same issue:
> >>>
> >> content/uploads/TCG_IWG_CEL_v1_r0p35_11july2021.pdf (it is still
> >> roughly marked as draft just like the "v1_r0p30_13feb2021" version).
> >> Can we find out the expected timeline of publication of this document by
> the TCG (if at all)?
> >>>
> >>> Thanks,
> >>> Roman
> >>>
> >>>
> >>>

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 12 Feb 2022 11:40:16 +0100

Hi Roman,

yes, we are standing by :-) and are closely following the IESG 
evaluation for I-D.ietf-rats-yang-tpm-charra.

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 25 Feb 2022 16:14:08 +0100

Hi Roman,

the TCG CEL document seems to have passed it's final gateway function 
yesterday and should become public in February therefore. In 
consequence, even with minor delays on the way, I think that a March 
10th telechat for yang-tpm-charra should work out and the DISCUSS on Riv 
should resolve soon, analogously.

Viele Grüße,

Henk

On 12.02.22 11:40, Henk Birkholz wrote:
>>> multiple
>> One thing I will ask in advance is that a team be ready to review and 
>> resolve the IESG feedback as quickly as possible.  Since the new IESG 
>> will be seated at IETF 113, some of the ballots required to approve 
>> this document will expire.
>>
>> Roman
>>
>>> Viele Grüße,
>>>
>>> Henk
>>>