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.
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) ?
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