Re: PKCS#7 v1.5 vs. CMS / ContentInfo vs. EncapsulatedContentInfo based on version

> -----Original Message-----
> From: Martin Rex [mailto:[email protected]]
> Sent: Friday, November 3, 2017 2:43 PM
> To: Jim Schaad <[email protected]>
> Cc: [email protected]; [email protected]
> Subject: Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs.
> EncapsulatedContentInfo based on version
> 
> Hi Jim,
> 
> Thanks for the reply, but this leaves me even more confused now.
> 
> Admittedly my personal implementors experience is tiny.  I once patched
> support for processing rfc3161 TimeStamps into an existing PKCS#7 v1.5
> implementation, and I needed a few tweaks for the ASN.1 encoder & decoder
> -- but rfc3161 uses id-ct-TSTInfo content type and version 3 rather than
id-data
> and version 1, so I needed tweaks for processing of
EncapsulatedContentInfo.
> 
> 
> Jim Schaad <[email protected]> wrote:
> >
> > To begin with, this is only a problem if you are looking at wrapping
> > contents other than id-data, for id-data there is no difference.  In
> > both cases there is an OCTET wrapper.
> 
> This statement looks like a self-contradiction.  Either there is _no_
difference
> between PKCS#7 v1.5 SignedData for id-data, then there is no wrapper.  Or
> there is a difference, and EncapsulatedContentInfo is used.

There is zero difference in the bytes outputted by the encoder.  

For PKCS#7 v1.5 - id-data is defined to be an OCTET STRING - thus the
emitted content is an OCTET wrapped data string
For CMS - id-data is defined to not have an ASN.1 type - instead the data is
directly wrapped by the OCTET wrapper that present in all SignedData objects

> 
> >
> > For things which are not id-data, there is going to be a difference
> > between the two encodings in that for one an octet wrapper is there
> > and for the other case it is not.  I would say that you need to look
> > at the content type and the type of the field and then make a decision
about
> what you are doing.
> 
> Do you mean that while the PDU encoding for SignedData with id-data
> ContentInfo is the same for PKCS#7 v1.5 and CMS, the actual signature (or
> more precisely the hash over that id-data) is computed _differently_ for
> PKCS#7 v1.5 and CMS (covering the 0x04 plus ASN.1 length field for CMS,
and
> omitting this for PKCS#7 v1.5) ?

For PKCS #7 v1.5 - the outer ASN.1 length and tag are not included in the
signature computation.  This means that the exact same set of bytes are
going to be hashed for an id-data object.

For a non-id-data object, the bytes that would be hashed ARE different.  For
PKCS #7 v1.5 the tag and length are not included in the signature
computation.  For CMS the OCTET wrapper is not included, but all of the
contents are included.  This means that for CMS the tag and length of the
data are included in the hash computation. 

Does this answer your questions?

> 
> I wouldn't like a heuristic on decoding because it results in needlessly
complex
> code and seems to have an ambituity for certain id-data that
conicidentally
> matches the beginning of an ASN.1 DER OctetString.
> 
> But requiring a heuristic on SignedData would be magnitudes worse, because
> of significantly higher CPU cycles impact for computing and verifying two
> different hashes.
> 
> 
> > I will note that there is a security problem with the PKCS#7 encoding
> > where the content and length bytes are not correctly protected.  This
> > is one of the reasons that CMS added the OCTET wrapper in all cases
> > rather than just in the case of id-data.
> 
> But "in all cases rather than just in the case of id-data" is a
contradiction to the
> above (with respect to the encoding).  Or is this comment _not_ about the
> encoding, but rather about the data which gets signed (hashed) ?
> 
> 
> >
> > There was never any intent that a version number of one would indicate
> > that this was PKCS#7 rather than CMS.
> 
> That sounds wrong to me.  At least my copy of PKCS#7 v1.5
> (rfc2315) is _explicit_ that this version indicates PDU/protocol, and
> version==1 therefore implies PKCS#7 (rfc2315) syntax/encoding
> **AND** processing rules (semantics).
> 
> https://tools.ietf.org/html/rfc2315#section-9.1
> 
>    The fields of type SignedData have the following meanings:
> 
>         o    version is the syntax version number. It shall be
>              1 for this version of the document.
> 
> 
> The PKCS#7 v1.5 PDU was *ALWAYS* supposed to be self-describing, and later
> revisions of it to identify different syntax as well as different
processing rules by
> using a different version in the PDU.
> 
> 
> For the particular (governmentally mandated) data exchange scenario in
> Germany, they're currently using PKCS#7 v1.5 with RSA PKCS#1 v1.5, and
they
> want to transition to using RSA-PSS (signatures on certs and PKCS#7/CMS
> SignedData) and RSA-OAEP (EvelopedData), with EndEntity certs that carry
> rsaEncryption keys (so that the keys can be used for both, signature and
> encryption).
> 
> 
> -Martin

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime