Re: [Jmap] [Extra] Choosing between the S/MIME drafts

[Ken Murchison <[e-mail]>]

Adding the JMAP list since this is a JMAP question, not an IMAP/Sieve one.

Since the end-to-end Email security draft referenced below emphasizes 
simplicity in several places, I agree with Bron, that fewer controls in 
JMAP is preferable.  This, in my mind, would take any model that allows 
the client explicitly specify a list/array of sign and/or encrypt 
operations off of the table.

I don't have any strong opinion on whether we keep the model in the 
existing draft or switch to Bron's even simpler model.


On 3/20/24 8:42 PM, Bron Gondwana wrote:
> Hi All,
>
> Jim and I have discussed, and don't believe that - as chairs - it is 
> our position to choose which approach to take.  This is something that 
> belongs to consensus of the group.  So removing my chair hat, here's 
> what I see as most "jmappy".
>
> When we create an email using Email/set - we don't define the exact 
> MIME structure, we describe the elements of the email and have the 
> server generate MIME.
>
> Likewise, when we ask for Protection on an email, my preference as a 
> JMAP enthusiast is that we don't specify the exact algorithm, whether 
> it's sign-encrypt-sign or just encrypt-sign, etc.  We just request the 
> server do the currently defined thing.
>
> Basically, the client just asks for:
>
> protection: null / 'automatic' | 'unprotected' | 'verified' | 
> 'confidential'
>
> With these name meaning things as per e2-guidance 
> <https://datatracker.ietf.org/doc/draft-ietf-lamps-e2e-mail-guidance/>.  
> Automatic is "server chooses the default for this recipient", and NULL 
> or missing key means "automatic", such that a client naive of this 
> specification might wind up creating emails which all get sent 
> |verified| if that's the server default, but a client can also choose 
> to turn that off (again; the server could reject that!  It could say 
> it has a policy of only sending protected messages).
>
> Potentially we could have a separate draft for "S/MIME configuration" 
> allowing a client to update the server settings for what the server 
> should do in terms of the MIME structure generated for those different 
> protection levels; if there's an agreement on what those options 
> should be.  But the most basic level should be a way to tell the 
> server to do the configured current best practice for each of the 
> enumerated types of protection.
>
> The protection values would be a registry with "RFC required" as the 
> policy for adding new values.
>
> Bron.
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
> [e-mail]
>
>