I realize that your example is hypothetical. However it cannot happen under
RFC 5652.
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.
Russ
On May 5, 2022, at 8:34 AM, Peter Gutmann
<pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz> wrote:
Russ Housley <housley(_at_)vigilsec(_dot_)com> writes:
That is, an unrecognized version can save the recipient for getting a parsing
error.
But they won't be getting a parsing error, see the example I gave:
SignedData {
version = 7,
digestAlgorithms,
content,
signerInfos {
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?
Peter.
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime