Trevor,
There is yet another more
fundamental inconsistency in the core as it applies to CMS. The core protocol
supports a basic CMS Sign through use of the SignatureType element set to
urn:ietf:rfc:3369. This requires no extending or special profiling handling
and is clearly documented.
On the flip side one cannot simply
pass this newly created ASN binary signature back in for Verification without
breaking the [Optional] [Required] designations in the spec. That is,
both InputDocuments and SIgntaureObject are [Required]. If the CMS
signature is detached, this works fine since the implementation will need
both to Verify. If however the CMS Signature includes the signed
content one has nothing to put in InputDocuments.
This is just more fuel to make
InputDocuments and SignatureObjects [Optional]. Basic support for CMS is still
present in the core on the Sign, but not quite there on the
Verify. Forcing profiles to entirely new elements in these 2 basic areas
is dooming the profile to unnecessary compexity.
We are down to this last
request ... Make both InputDocuments and SIgnatureObject [Optional]. An
InputDocument can contain a signature, and a signature can carry the signed
document. Both are very common in both XMLDSIG and CMS. And in single
document or signature scenarios when one is present, the other is redundant. I
vote this needs fixing.
Ed