Re: [smime] Problems with versions

[Carl Wallace <[e-mail]>]

+ LAMPS

I wonder how many implementations defer the decoding of SignerInfos until after the version number is read. Mine does not, so presence of new SignerInfo or ReceipientInfo types would cause failure to parse without ever seeing the version number. I don't check the version number at all for SignedData/SignerInfo at verification time and just use whichever of SKID or issuer/serial is present. I have also never seen a v4 or v5. There aren't any extensibility markers in the places you’d need them to introduce new SignerInfo or ReceipientInfo types without breaking folks.

On 5/5/22, 8:34 AM, "smime on behalf of Peter Gutmann" <[e-mail] on behalf of [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.

    _______________________________________________
    smime mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/smime