Conversation
azul
left a comment
azul
left a comment
There was a problem hiding this comment.
Looks good to me. Good idea to point out the previous situation in a note.
| 3072-bit RSA public keys. It MAY support other OpenPGP key formats | ||
| found in an Autocrypt header (for example, by passing it agnostically | ||
| to an OpenPGP backend for handling). | ||
| A Level 1 MUA MUST be capable of processing and handling Ed25519 |
There was a problem hiding this comment.
shouldn't this read "A Level 1.1 MUA ..."?
EDIT: okay, i recall and understand :) the level is the "level of protection" in general, so, probably this is fine.
however, seeing these two different requirements, both belonging to the same "Level", as a diff below each other, may be a bit confusing. maybe we should add the version number or so, sth. as "level 1, version 1.1".
There was a problem hiding this comment.
Nope. This is still level 1, but version 1.1 of it. Since all implementations are on board with this in practice, and this is mostly an update to the "how" rather than the "what", we thought that there's no point making a whole "level" out of it :)
There was a problem hiding this comment.
yeah, as mentioned, i understand. but still find this confusing ;)
but it's fine for me :)
pbrunschwig
left a comment
pbrunschwig
left a comment
There was a problem hiding this comment.
Fine with me.
@r10s The Level is an overall concept, whereas the version is the revision of the document.
|
On Mon, Nov 12, 2018 at 07:16 +0000, Patrick Brunschwig wrote:
pbrunschwig approved this pull request.
Fine with me.
@r10s The Level is an overall concept, whereas the version is the revision of the document.
however, saying "Level 1.1 client" is easier and will be chosen often over
"a Level 1 client as specified with revision 1.1" or so ;)
|
| configuration. Support for elliptic curve cryptography in deployed | ||
| OpenPGP implementations improved since then, and the switch to ECC | ||
| was made in version 1.1 (December 2018) due to message size | ||
| considerations. |
There was a problem hiding this comment.
i remain fine with this, good note 👍
|
The typical way that i'd expect such a change to happen in a protocol doc with wider adoption is to require support for handling the new crypto primitives (when seen from communications peers) in version X+1, and then mandate generation of the new key types in version X+2. Perhaps we're small enough and we have a wide enough canvas already that we can just jump ahead, though it makes me slightly nervous. PGPy still doesn't support cv25519 and ed25519, for instance, though perhaps its current stagnation is a warning about that library itself. :( I'm open to the idea, though -- i definitely like the size improvements we're seeing with the ECC keys. This change should not be merged without updates to the appendix, though -- the example keys and messages should all be re-created using 25519. |
|
Hey, when do you plan to switch? Best |
|
I updated the examples. I already double-checked myself, anyone care to double-double-check? Also added a script for generation. It works, but better not look at that too closely ;) |
|
@oliverFU now :) |
7 participants
As discussed at the meeting.
RSA remains a SHOULD. I put a remark about older versions into a note, that seemed like the appropriate place.