[seal] Re: Proposed update to SEAL charter

[Muhammad Usama Sardar <[e-mail]>]

(Additional to those in the other email)

On 30.09.25 02:23, Paul Wouters wrote:

>
> On Mon, Sep 29, 2025 at 6:09 PM Muhammad Usama Sardar 
> <[e-mail]> wrote:
>
>     Hi Paul,
>
>     Thank you for updates on the charter. I see that a few of the
>     comments were not accommodated. I didn't see any explicit reason
>     in the preamble of your email to not accommodate those. If there
>     is a reason, please clarify.
>
>
> There were lots of comments and discussion. I didnt think all needed 
> changes or did it differently from what you or ekr suggested. Let me 
> know where
> you think this is still an issue.
Sorry for the confusion, I should have used the word "following". The 
comments in my email were all I meant.
>
>     On 29.09.25 21:42, Paul Wouters wrote:
>
>>
>>     New Charter text:
>>
>>     # Background and motivation
>>
>>     Remote attestation (RFC9334) addresses this by allowing an entity to
>>     produce Evidence and Attestation Results about its current state. For
>>     example to prove that its software and firmware haven't been tampered
>>     with. Or to prove that a secure boot method is enabled. Or to prove
>>     that cryptographic keys are securely stored within a
>>     hardware-protected
>>     environment.
>>
>     Editorial: Ekr correctly mentioned that except for first sentence,
>     these are all phrases and not full sentences. My proposed new text
>     for this is in [0].
>
>
> I had added verbs to those sentences. I didn't like the ",or" construct.
I still think the subject is missing and these are not complete sentences.
>
> # Scope
> Mutual attestation will
> be supported with and without client TLS authentication to faciliate
> anonymous client attestation.
Maybe s/client TLS/TLS client
>
> Specific scoping:
>
> - The attested (D)TLS protocol will focus on attestation with and without
>   TLS authentication. but will not create new TLS authentication 
> mechanisms.

Server authentication is a must, otherwise it trivially breaks the 
guarantees of TLS.

Maybe s/TLS authentication./TLS client authentication, while maintaining 
TLS server authentication

or maybe mention as a separate bullet something like "The extension will 
not break the existing formally verified properties of (D)TLS protocol."

Best regards,

Usama