Re: [dss] Another Inconsistency

[Trevor Perrin <trevp@trevp.net>]

At 07:18 AM 4/19/2004 -0400, ed.shallow@rogers.com wrote:
>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.

Right.


>  If however the CMS Signature includes the signed content one has nothing 
> to put in InputDocuments.

Yes, the core spec doesn't say how to handle enveloping CMS signatures.  I 
think that's ok.


>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].

Well, this is a larger proposal than we were discussing yesterday 
(yesterday we were just discussing modifying <SignaturePtr>).  It has 
ramifications on 4.3 Basic Processing.  I think we'll have to think about 
this some more.


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

The redundancy doesn't bother me much - adding special-cases to eliminate 
it seems like a cure worse than the disease, imho.

Trevor