Re: header protection drafts too early to implement (Re: Protect email experience not Subject:s (hypothesis, draft))
Am Freitag 12 März 2021 18:02:41 schrieb Bernhard Reiter: > To keep you in the loop, my main take-away so far: > It is not ready to be implemented yet, because If it is implemented, to me it makes sense to a) only implement one method, and this seems to be to wrap one full message in MIME, because it is most backwards compatible and proposed in the current draft. Thunderbird does implement a different outdated approach I believe (At least I've examined an email from Thunderbird/78.6.0) and I found Content-Type: multipart/mixed; boundary="."; protected-headers="v1") b) implement reading first and do not activate sending. This is something that Thunderbird should also fix. Implemententation for reading makes some sense to try out how the unaddressed usability problems will fare out. To send encrypted subjects now means losing information if an injected approach is used like Thunderbird seems to use. Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
header protection drafts too early to implement (Re: Protect email experience not Subject:s (hypothesis, draft))
Took a few hours to read through the current version of Am Freitag 29 Januar 2021 17:52:25 schrieb Bernhard Reiter: > [3] https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ draft-ietf-lamps-header-protection-03 Last updated 2021-02-22 which also aims at OpenPGP/MIME mails. To keep you in the loop, my main take-away so far: It is not ready to be implemented yet, because a) it rightfully aims to proposed one method and leans towards wrapped message approach. b) the usability problems are not addressed, mainly how to display a mixed set up headers where some are signed-only, not protected or signed-and-encrypted, but also the complexity arising from this. Also what should happen if one of the signature do not validate, displaying this for each header field is something I cannot really imaging so far. c) the drawback of server filter and access and indexing problems with implementations (where email draws a lot of usability from) are unsolved. Overall, there is some good technical work in the document. Personally I feel it focusses on some aspects more than other aspects, missing a bit on the bigger picture. Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users