Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs. EncapsulatedContentInf

As Jim already said, that is not the point of the version number.  The point is 
to avoid decode errors.

Russ


> On Nov 3, 2017, at 1:01 PM, Martin Rex <mrex(_at_)sap(_dot_)com> wrote:
>
> Russ,
>
> It seems I wasn't sufficiently clear.
>
> This is about a third-party specification refering to CMS/rfc5652.
>
> That organization specifically refers to SignedData structure and
> members as defined in section 5.1 of RFC 5652, it quotes that structure
> definition, and describes contents for the structure elements.
>
> For the version element, since they _not_ doing any of the fancy
> stuff, they came up with "version=1" from the pseudo-code.
>
>
>  https://tools.ietf.org/html/rfc5652#section-5.1
>
>   5.1.  SignedData Type
>
>   The following object identifier identifies the signed-data content
>   type:
>
>      id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
>         us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
>
>   The signed-data content type shall have ASN.1 type SignedData:
>
>      SignedData ::= SEQUENCE {
>        version CMSVersion,
>        digestAlgorithms DigestAlgorithmIdentifiers,
>        encapContentInfo EncapsulatedContentInfo,
>        certificates [0] IMPLICIT CertificateSet OPTIONAL,
>        crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
>        signerInfos SignerInfos }
>
>      DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
>
>      SignerInfos ::= SET OF SignerInfo
>
>
> However, the use of version=1 would IMHO imply the use of the original
> PKCS#7 v1.5 structure instead:
>
>  https://tools.ietf.org/html/rfc2315#section-9.1
>
> and more specifically, the use of the original PKCS#7 v1.5 ContentInfo rather
> than the CMS version 3 EncapsulatedContentInfo.
>
>
> The organization is currently assuming that CMS (rfc5652) would suggest
> combining "version=1" with CMS 3+ SignedData with EncapsulatedContentInfo.
>
> To me, this looks "underspecified".  I.e. rfc5652 section 5.1 fails to
> describe what exactly version=1 means for the ContentInfo vs.
> EncapsulatedContentInfo encoding of SignedData.
>
> -Martin
>
>
> Russ Housley <housley(_at_)vigilsec(_dot_)com> wrote:
> > The version is structure in this manner so that an implementation
> > that checks the version number and then does a decode will never
> > get a decode error on a properly constructed message.
> >
> > If the only changes are (migrate from PKCS#1 v1.5 to RSA-PSS) and
> > (migrate from PKCS#1 v1.5 to PRS-OAEP), then the change should be
> > very straightforward.
> >
> > If you are not using any version 1 attribute certificates, identifying
> > the signer with the subject public key identifier, or using a content
> > type other than id-data, then the version for Signed-Data should not change.
> >
> > I am assuming that you are not mixing RSA-OAEP with other key management
> > algorithms.  If you are not using unprotect attributes or identifying
> > the signer with the subject public key identifier, then the version
> > number for Enveloped-Data should not change.
>
>
> > > On Nov 3, 2017, at 12:04 PM, Martin Rex <mrex(_at_)sap(_dot_)com> wrote:
> > >
> > > There is a somewhat confusing ruleset around the "SignedData" PDU
> > > version field in the CMS specification, and insufficient guidance
> > > about the ramifications for the Encoder/Decoder for ContentInfo
> > > when version 1 vs. 3 is chosen.
> > >
> > > The organization responsible for certain legally mandated data exchanges
> > > in Germany is rev'ving their requirements, intoducing RSA-PSS signatures
> > > on certificates plus RSA-OAEP encryption for AppData.
> > >
> > > Previously, they've been using PKCS#7 v1.5 PDUs with RSA PKCS#1 v1.5
> > > transforms.
> > >
> > > The confusion I'm seeing is about the choice of the SignedData "version"
> > > field, and the resulting consequences for the (ASN.1) PDU encoder/decoder
> > > for the ContentInfo vs. EncapsulatedContentInfo in SignedData.
> > >
> > >
> > > For the encoder/decoder, the reasonable interpretation would be,
> > > that whenever version=1, then the PKCS#7 ContentInfo encoding will be
> > > used, and only for version>=3, the CMS EncapsulatedContentInfo encoding
> > > will be encoded or decoded.
> > >
> > >
> > > However the current reading of the CMS standard by that organization is
> > > that they want to specify version=1 in combination with 
> > > EncapsulatedContentInfo
> > > encoding -- something that looks extremely weird to me, and would require
> > > significant contortions in the ASN.1 encoder and decoder.
> > >
> > > For the encoder, it will require a laying violation from within the encoder,
> > > looking at later elements and semantics of higher level PDUs.
> > >
> > > For the decoder, it essentially will require heuristics (trial-and-error)
> > > decoding if the PDU version will no longer matter, and the data determining
> > > which encoding is appropriate, has not been decoded yet at this point
> > > requiring a retroactive verification of whether the heuristically determined
> > > encoding was actually a _valid_ encoding.
> > >
> > >
> > > Any comments from folks more experienced with CMS ?
> > >
> > > -Martin
> > >
> > > _______________________________________________
> > > 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