Re: [lamps] Draft addition of header protection to the LAMPS charter

[[e-mail]]

Hi Stephen

Thanks for pointing this out.

Trying to answer your question:
It is _not_ my intent to include any constraints on the solution to the 
new charter item, in fact IMHO the charter shall _not_ limit the solution 
space. At the end of the day, we need to be able select the best solution.

However, I just noticed what likely triggers your concern with the wording 
in HB-3, i.e. different people may interpret the text in HB-3 differently 
(which should to be avoided).

Would the following improved suggestion HB-3.1 address your concern 
adequately?

--- BEGIN HB-3.1 ---

7. Cryptographic protection of electronic mail headers: A mechanism to 
address this in S/MIME has been standardized in RFC 5751. The WG shall 
define solutions (both for signature and encryption) to 
close significant privacy, security and usability gaps in 
cryptographically-protected electronic mail.

--- END HB-3.1 ---

cheers,
  Bernie

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology


On Sat, 5 Jan 2019, Stephen Farrell wrote:

>
> Hi Bernie,
>
> Clarifying question and a comment.
>
> On 05/01/2019 15:04, [e-mail] wrote:
>>
>> --- BEGIN HB-3 ---
>>
>> 7. Cryptographic protection of electronic mail headers: A mechanism to
>> address this in S/MIME has been standardized in RFC 5751. The WG shall
>> improve the specification (both for signature and encryption) to close
>> significant privacy, security and usability gaps in
>> cryptographically-protected electronic mail.
>>
>> --- END HB-3 ---
>
> The above reads to me like it constrains the work to be backwards
> compatible with 5751 if that is possible.
>
> Is that your intent?
>
> I'd be against having such a constraint myself.
>
> If you don't intend such a constraint then I think wording that
> makes that clear would be better.
>
> All told though, I'd prefer if the history was just omitted - I
> think we're better focusing on what's likely to get implemented,
> deployed and used, rather than our collective historic failures
> wrt e2e security for mail.
>
> Cheers,
> S.
>
>