Add support for RSA-OAEP (key) encryption #5
Conversation
| @@ -77,7 +75,11 @@ var ( | |||
| OIDEncryptionAlgorithmECDSAP384 = asn1.ObjectIdentifier{1, 3, 132, 0, 34} | |||
| OIDEncryptionAlgorithmECDSAP521 = asn1.ObjectIdentifier{1, 3, 132, 0, 35} | |||
|
|
|||
| // Encryption Algorithms | |||
| // Asymmetric Encryption Algorithms | |||
There was a problem hiding this comment.
Both are defined here https://datatracker.ietf.org/doc/html/rfc8017 (and its obsoleted version https://datatracker.ietf.org/doc/html/rfc3447)
There was a problem hiding this comment.
I've added some references now. Not to all of them; will revisit sometime.
| // KeyEncryptionAlgorithm determines the algorithm used to encrypt a | ||
| // content key. Change the value of this variable to change which | ||
| // algorithm is used in the Encrypt() function. | ||
| var KeyEncryptionAlgorithm = OIDEncryptionAlgorithmRSA |
There was a problem hiding this comment.
If possible, we should use RSA OAEP by default.
There was a problem hiding this comment.
Are we considering adding new encrypt methods so we don't have to change the value of this variable?
The same applies to ContentEncryptionAlgorithm. And should we default to EncryptionAlgorithmAES256GCM. I guess we cannot use XSalsa20+Poly1305 here.
There was a problem hiding this comment.
Right now it uses the current default, making this fork backwards compatible with the current Mozilla one (with some fixes and new features). But I agree that defaulting to RSA OAEP is better going forward. Same applies to EncryptionAlgorithmAES256GCM.
For XSalsa20+Poly1305 in CMS there exists a proposed standard: https://datatracker.ietf.org/doc/html/rfc8103. So I guess it can be added; it's just a bit less "standard" than the other algorithms, but still something that has been reviewed by IETF.
Yes, changing the API of this package is something I would like to do. If we add new functions, the changes could be backwards compatible: create new methods that take options, backed by private methods, and adapt the current methods. But it might also make sense to start a new major version, so that there's no need to be fully backwards compatible and can make breaking changes in terms of supported algorithms.
No description provided.