I realize that your example is hypothetical. However it cannot happen under
For SignerInfo, there are only two allowed values:
version is the syntax version number. If the SignerIdentifier is
the CHOICE issuerAndSerialNumber, then the version MUST be 1. If
the SignerIdentifier is subjectKeyIdentifier, then the version
MUST be 3.
On May 5, 2022, at 8:34 AM, Peter Gutmann
Russ Housley <housley(_at_)vigilsec(_dot_)com> writes:
That is, an unrecognized version can save the recipient for getting a parsing
But they won't be getting a parsing error, see the example I gave:
version = 7,
signerInfo version = 7,
signerInfo version = 6,
signerInfo version = 1
If you change the SignedData version to 1 then an implementation that doesn't
understand version 6 or 7 signerInfos can still process the message because
there's a version 1 signerInfo present. However if you set it at 7 then the
implementation is being told it can't (or shouldn't) process the message even
though it can.
The fact that there's some not-currently-recognised but totally processable
(meaning read the header and skip the remaining payload) entry somewhere
further down in the message doesn't mean that the whole message should be
marked as unprocessable by an implementation.
If there's any implementers still on the list, what would your code do if it
encountered the above message? And what would it do if the SignedData version
was 1 instead of 7?
smime mailing list