+ 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"
<smime-bounces(_at_)ietf(_dot_)org on behalf of
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
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime