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