Update names of PKCS#7 structure members, fix obsolete structure#14559
Update names of PKCS#7 structure members, fix obsolete structure#14559
Conversation
| pub enum RecipientIdentifier<'a> { | ||
| IssuerAndSerialNumber(IssuerAndSerialNumber<'a>), | ||
| #[implicit(0)] | ||
| SubjectKeyIdentifier(&'a [u8]), |
There was a problem hiding this comment.
Sorry, I don't know how we can be clearer about this: We cannot add support for new ASN.1 structures with 0 tests or understanding of the compatibility impacts. Simply ignoring values when they have a different format is not self-evidently correct.
There was a problem hiding this comment.
The current (old) implementation selectively violates the specification, it is currently not "self-evidently" correct.
The compatibility "impact" should be covered by the current test suite, existing messages are handled exactly the same. Problems arise when the CMS payload is even remotely newer. If they contain revocation information, if the recipient is using an elliptic curve or PQ certificate - anything even remotely modern throws an incorrect parse error.
It would be of no hassle to add a test to read out SKI from CMS.
I've already spent a bunch of time trying to provide all the necessary building blocks for a holistic modern S/MIME implementation. I'm not willing to continue doing so if the actual goal is to actually keep the current incorrect incomplete implementation and to send me around in circles.
There was a problem hiding this comment.
The alternative is to update the documentation so that it accurately says that it's S/MIME 2.0 and that it is extremely picky about it, it's not going to support anything newer (from 2006).
2 participants
EnvelopedDatais also very outdated (mostly follows the 1998 RFC) and currently just errors out when it encounters something encrypted for multiple recipients if anything besides RSA is used. The only supported variant currently is actuallyKeyTransRecipientInfo, the structure is renamed as such.This PR does not aim to fix that issue, just the prerequisites for it. RSA decryption will continue to error when one of the RecipientInfos is unsupported. It only slightly aligns the names and other parts of the supported structures with RFC 5652. After that I can try to fix it and offer changes to tolerate KARI/KEKRI/PRI/ORI. If that's done, the documentation doesn't have to be updated to mention that it's S/MIME 2.0 not 3.2.