-----Original Message-----
From: Martin Rex [mailto:mrex(_at_)sap(_dot_)com]
Sent: Friday, November 3, 2017 2:43 PM
To: Jim Schaad <ietf(_at_)augustcellars(_dot_)com>
Cc: mrex(_at_)sap(_dot_)com; smime(_at_)ietf(_dot_)org
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 <ietf(_at_)augustcellars(_dot_)com> 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
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime