Skip to main content

Secure Evidence and Attestation Layer
charter-ietf-seal-00-03

Yes

(Paul Wouters)

No Objection

Andy Newton
Jim Guichard
Mike Bishop
(Erik Kline)

Note: This ballot was opened for revision 00-02 and is now closed.

Ballot question: "Do we approve of this charter?"

Mohamed Boucadair
Yes
Comment (2025-10-08) Sent
Hi all,

As indicated in my previous ballot [1], this is useful work. 

Thanks for taking into account some of the comments. The version that went for external review, included 

"have taken into account any Operational Considerations that apply"

.. which I see removed in the latest version as a side effect of wimse mention removal. 

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/seal/BJmfAFQxap4tDNfNbCbhRfGwJ3s/
Andy Newton
No Objection
Deb Cooley
No Objection
Comment (2025-10-08) Sent
Scope, para 1, last sentence:  I'm assuming that one isn't really going to allow 'anonymous client attestation', since without knowing what device, H/W, manufacturer is attempting to connect/attest, it is impossible to prove that the unknown client is holding an unknown device is deemed to be trustworthy.  I'm assuming that in this case, the TLS session is merely server authenticated and that the attestation layer will have to do whatever ID proofing is required for the application.  I would change anonymous to 'privacy preserving'.
Éric Vyncke
No Objection
Comment (2025-10-08) Sent
Strong suggestion to s/(Proposed) Milestones/Work Items/ (this would keep the list inside the charter and have dates in the outside-of-charter datatracker milestone).
Jim Guichard
No Objection
Ketan Talaulikar
No Objection
Comment (2025-10-07) Sent
Please move the (proposed) milestone from within the charter text to the milestones portion (where it would also capture dates).
Mahesh Jethanandani
No Objection
Comment (2025-10-07 for -00-02) Sent
Paragraph 11
> - This effort will be restricted to leveraging the (D)TLS 1.3 protocol
>   and a potential attestation binding to a (D)TLS 1.3 session.
>   
> - It will leverage the existing RATS WG documents to ensure
>   interoperability with existing and future attestation technologies.
> 
> - The (D)TLS protocol solution will focus on attestation and authenticated
>   attestation, but will not create new authentication mechanisms.

I am a little confused by the first and third bullet point here. Are they not pretty much saying the same thing? Can they be combined? Something like:

This effort will be restricted to leveraging the (D)TLS 1.3 protocol and its solution for authenticated attestation and binding to a (D)TLS 1.3 session. No new authentication mechanisms will be defined.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"RATS", paragraph 1
> ing formal analysis of the working groups's resulting work. - The working gro
>                                    ^^^^^^^^
Did you mean "group's" or "groups'"?
Mike Bishop
No Objection
Roman Danyliw
No Objection
Comment (2025-10-07) Sent
Milestones need dates.
Paul Wouters Former IESG member
Yes
Yes (for -00-02) Not sent

                            
Erik Kline Former IESG member
No Objection
No Objection (for -00-02) Not sent