Re: [smime] Problems with versions

[Russ Housley <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Russ Housley <[e-mail]> 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.
>