Russ Housley wrote:
I prefer:
... However, signed attributes within the signed-data content type and
authenticated attributes within the authenticated-data content type require
DER
encoding. Signed attributes and authenticated attributes must be transmitted
in DER form to ensure that recipients can validate a content that contains an
unrecognized attribute. Signed attributes and authenticated attributes are
the
only CMS data types that require DER encoding.
Agreed.
[snip]
I know. This is a philosophy question. Since these identifiers will
eventually be in the IANA registry, I did not know whether or not these values
should be part of the module.
I would be glad to add these values to the module if the working group thinks
they belong there. Comments?
Either include the OIDs, or include a pointer to a document containing the
OIDs (that of course, uses the same names).
[snip]
7. Section 5.1: Text on version needs to be expanded to deal with SKI.
Must be 3 if any SignerInfo version is 3.
Are you saying that a version 3 SignerInfo should cause parent SignedData
version to be 3?
Is there a reason to prohibit version 3 SignerInfo from being encapsulated in
a
version 1 SignedData?
[snip]
I can see arguments on each side:
If the SignedData version is bumped, that will possibly make some ASN.1
decoders happier.
If the SignedData version is left as is, then messages that contain
multiple SignerInfos, some of which are v1/v2, may be partially processed.
Neither of these are critical (both problems can be programmed around),
but I
think the later would be better for implementors (although the spec needs
to state
what to do when there are SignerInfos with "too high" version numbers).
On the other hand, my guess would be that bumping the SignedData version number
is ASN.1 Best Current Practice. Does anyone know?