README changes for 2.0 #275
Conversation
README.md
Outdated
| | `digest` | | Enables `Context`, `SigningKey::{with_context, sign_prehashed}` and `VerifyingKey::{with_context, verify_prehashed, verify_prehashed_strict}` for Ed25519ph prehashed signatures | | ||
| | `asm` | | Enables assembly optimizations in the SHA-512 compression functions | | ||
| | `pkcs8` | | Enables [PKCS#8](https://en.wikipedia.org/wiki/PKCS_8) serialization/deserialization for `SigningKey` and `VerifyingKey` | | ||
| | `pem` | | TODO | |
There was a problem hiding this comment.
@tarcieri can you fill this and pkcs8 out? I'm pretty confused actually. How is pem different from PKCS#8? Isn't PEM a container format within the PKCS#8 spec? What does it contain? What are the other things in PKCS#8?
There was a problem hiding this comment.
TL;DR PEM is additive "text formatting" feature over PKCS#8 because 7bit US-ASCII "convenience" 🤷♀️
PEM = "Enable text PEM formatting over PKCS#8" and
PKCS8 = "Enable PKCS#8 DER Binary encoding"
Long version:
PEM "Privacy Enchanced Email" (yes confusing) is a text file format .. like Base64 wrapping/formatting of binary X.509 certificates e.g. PEM is the --BEGIN ASCII blocks that simply contain the Base64 formatting of the PKCS#8 but it also carries things like X.509 certificates and other binary data thus PEM is it's own thing.
The origin was from the early internet as e-mail in it's 7bit form wasn't really designed to carry binary data and it was encoded and wrapped (the --BEGIN block) in as Base64 text formatting that allowed itself to be carried in 7bit SMTP - https://en.wikipedia.org/wiki/Base64 - which still ends up in text files.
PEM is optional but often used thus included esp when writing files that contain data such as PKCS#8
PKCS#8 in turn is the binary encoded container under it which may contain passphrase etc - it's just ASN.1/DER
PKCS#8 ASN.1 schema is here - https://datatracker.ietf.org/doc/html/rfc5208#page-5
Today we can still think - why are we still using Base64 given the large overhead it causes like in e-mail attachments a'la MIME Multipart is anyone's guess ? 🤷♀️
README.md
Outdated
|
|
||
| Since `verify_batch()` is intended to be high-throughput, we think it's best not to put weak key checks in it. If you want to prevent weird behavior due to weak public keys in your batches, | ||
| TODO | ||
| you should call `VerifyingKey::is_weak` on the inputs in advance. |
|
These are most of the changes I wanted to make to the README. I might add some tweaks here and there tho |
README.md
Outdated
| @@ -71,9 +75,11 @@ Below are the specific policies: | |||
| | :--- | :--- | :--- | | |||
| | 2.x | Dependencies `digest`, `pkcs8` and `rand_core` | Minor SemVer bump | | |||
|
|
|||
| TODO @tarcieri what about PEM? | |||
There was a problem hiding this comment.
We only lists the crates / dependencies but not features as such here -
pem as a feature comes via pkcs8 (unstable) crate via optional feature of ed25519 which itself is stable on all-default-on -
Since it's not a crate or dependency itself unlike pkcs8 - theoretically we don't need to mention pem here, just pkcs8 given it's optional dependency of ed25519 thus exempted.
Given anyone who is using pem will inherently use pkcs8 I don't see much problem not mentioning pem here ?
Co-authored-by: pinkforest(she/her) <[email protected]>
Rendered
Other changes:
Contextandwith_contextbehinddigest. No reason to have those if you can't use them.CONTRIBUTING.mdand updated authors list inCargo.toml