[Top] [All Lists]

Re: [smime] Problems with versions

2022-05-05 10:37:59
But the problem would be here (assuming wholesale replacement of SignerInfo):

SignerInfos ::= SET OF SignerInfo

Or here (assuming mods to existing definition):

  SignerInfo ::= SEQUENCE {
      version CMSVersion,
      sid SignerIdentifier,
      digestAlgorithm DigestAlgorithmIdentifier,
      signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
      signatureAlgorithm SignatureAlgorithmIdentifier,
      signature SignatureValue,
      unsignedAttrs [1] IMPLICIT Attributes
          {{UnsignedAttributes}} OPTIONAL }

Both of these snips are from 5911.

On 5/5/22, 10:44 AM, "Russ Housley" <housley(_at_)vigilsec(_dot_)com> wrote:


    The first versions of PKCS#7 and then CMS (RFC2630) all used the earlier 
version of ASN.1, so extensibility markers did not exist yet.  So, the version 
number logic gives the recipient a heads up about the fields that might be 

    RFC 5911 uses the new ASN.1 syntax, and it makes use extension markers.  It 
also makes use of the ASN.1 idiom for noting in which version of CMS changes 
were made from the original PKCS #7.  For example:

       RevocationInfoChoice ::= CHOICE {
           crl CertificateList,
           [[5: other [1] IMPLICIT OtherRevocationInfoFormat ]] }


    > On May 5, 2022, at 9:06 AM, Carl Wallace 
<carl(_at_)redhoundsoftware(_dot_)com> wrote:
    > + 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 
    >> 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 
    >    understand version 6 or 7 signerInfos can still process the message 
    >    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 
    >    (meaning read the header and skip the remaining payload) entry 
    >    further down in the message doesn't mean that the whole message should 
    >    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 
    >    was 1 instead of 7?
    >    Peter.
    >    _______________________________________________
    >    smime mailing list
    >    smime(_at_)ietf(_dot_)org

smime mailing list