RE: [dss] spec-wd-21

[Trevor Perrin <trevp@trevp.net>]

At 11:42 PM 5/16/2004 -0400, you wrote:
>Hi Trevor,
>
>     Some feedback on wd-21.
>
>- in section 1.3 line 175 you state "The signing and verifying protocols are
>chiefly designed to support the creation and verification of XML signatures
>[XMLSig] and XML timestamps (see section 5.1)."
>
>With the more complete support of CMS in this version, I think this sentence
>needs some rewording to more accurately reflect the "dual nature" of the DSS
>protocols.

Agreed, it needs some rewording.


>- In section 4.5 (CMS Verify) you simply state ... "3. The CMS signature and
>input data are verified in the conventional way (see [RFC 3369] for
>details).". Whereas in section 3.5.8 you state "In the case of a CMS
>signature, the input document's decoded octet stream will be placed in the
>eContent field of the encapContentInfo structure."
>
>I would change the latter phrase to be less specific to allow
>implementations to create ASN.1 signatures that are backward compatible with
>PKCS#7.

Okay, I'll look into that.


>- In section 3.5.5 lines 683-696, lettered sequence is off (extra d.
>bulletted item at the end on line 696 ?)

Thanks.


>- Section 4.1 844-850. Wording is clumbsy. Paragraphs should be rewritten as
>opposed to patched. Sentence starting on 847 is especially clumbsy. It still
>reads like the old spec with the new "optionality" as an afterthough.

The sentence on 847 is the same as it was, plus one clause.  Maybe it 
should have more details of the problem it's trying to avoid.

I'm not sure how else to improve this paragraph.


>- Section 4.3 896-904. Wording is clumbsy. The sentence beginning on 900
>should be at the top of the Section.

Okay.


>  Sentence on 903 should be dropped and a
>a more direct sentence substituted.

Okay, we can replace it with text copied from the first 2 sentences in the 
previous paragraph.


>- Section 4.3.1 para at 937 should simply state that the server result codes
>reflect first error encountered.

I think the 1st sentence is necessary.  The 2nd is just a security 
consideration, I'll plan on deleting it.


>Client's do not have to be warned, but
>rather implementations should be invited to extend error reporting.

I'm not sure what you mean - implementations shouldn't be invited to do 
anything not in the spec.  *Profiles* can of course add things, do you mean 
we should remind readers of that?


>In general, the language shows that these features are being discouraged 
>by the
>authors, which should not be the case. Line 948 in another example.
>In addition to telling implementors what they can't do, tell them what 
>they can
>do, to make this feature more useable through use of the OptionalInputs and
>Outputs.
>- In Section 4.4.4 line 1032. Same comment as above. It is obvious, when
>written this way, that the spec is discouraging use of multi-signature
>verification, which it shouldn't.

About 948 and 1032:  How do you think they should be changed?


Trevor