RE: [dss] spec-wd-21

["Edward Shallow" <ed.shallow@rogers.com>]

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.

- 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. For example, S/MIME v2 encapsulates the MIME content in the Data
type carried in the PKCS#7 SignedData contentInfo content ANY field, whereas
CMS uses signedData encapContentInfo eContent which is an OCTET STRING. I do
not believe you have to go into this detail, but just defer to RFC3369 which
provides guidelines for PKCS#7 backward compatibility should implementations
wish to support both.

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

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

- Section 4.3 896-904. Wording is clumbsy. The sentence beginning on 900
should be at the top of the Section. Sentence on 903 should be dropped and a
a more direct sentence substituted.

- Section 4.3.1 para at 937 should simply state that the server result codes
reflect first error encountered. Client's do not have to be warned, but
rather implementations should be invited to extend error reporting. 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.

Ed

  

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: May 12, 2004 10:13 PM
To: dss@lists.oasis-open.org
Subject: [dss] spec-wd-21


Some big changes:

  1) CMS processing rules added (3.4 and 4.4).
  2) Special handling for verifying DSIG enveloping or enveloped
signatures: instead of having to separate the Signature from the Input
Documents, the client can send a "lump" containing an enveloping/enveloped
signature and input docs, and let the server sort it out.  See 4.3.
  3) Multi-signature verification.  See 4.3 and and 4.3.1.

These add a lot of complexity, I doubt that I got them right or explained
them well.  Please send feedback.


http://www.oasis-open.org/apps/org/workgroup/dss/download.php/6745/oasis-dss
-1.0-core-spec-wd-21.doc
(my PDF-making tool chokes on this, sorry....)


Trevor


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
.