XML-Signature Editors' Page [ ascii]

>In this section there is no hint (neither in the textual description nor in the >Schema definition) that the "Transform" element could have mixed content. But >in section 5.6 the specification defines some character content for the "Transform" >element.
>
>To solve this contradiction, I suggest the following:
>
>* Keep the content model as-is (content='elementOnly')
>
>* Put the stuff defined in section 5.6 into a parameter element (for example the XPath language expression).

6. Typos:
section Status, "editoral"
section 2.3 "idenitifies", "ojbect", "Arbritrary"
section 3.0 "exampes".
section 3.3.3 "fragement", "ommit"
section 3.4 "inband"
section 4.1 "applicaiton"
section 5.5.1. "tranforms"
section 10 "DigetsValue" (and section should be 10.0 instead of 10)
section 13.0. "Signture"
section 14.0 "ECSDA"

From: david.solo@citicorp.com
Date: Mon, 3 Jan 2000 14:14:57 -0500
Subject: RE: core 20000104?

Joseph and Don (I'm not sure who has the ball),

Just a few comments/questions on the 04 draft (mostly typos)

- 1.0 (and many other places) "envoloping" should be "enveloping"

- 2.1, par 1 "While the data object(s) are not directly .... over the data
object(s)." I don't like this as it implies some weaker cryptographic binding
(one could argue signatures are always indirect merely by signing a hash in the
first place). I would prefer deleting this.

- 2.3 third from last par "Transforms can include arbitrary specifications such
as..." I'd rather see "Transforms can include operations such as ...."

- 2.4 (and later) I thought we'd decided to kill package

- 3.3 Missing ? after C14nmethod in the DTD

- 3.3.3 ObjectReference in DTD should be Reference (twice)

- 3.3.3 Add to the end "The type attribute is purely advisory, no validation
of the type information is required by this document."

- 3.5, par 3, line 2 "acual" should be "actual"

- 3.6 (and throughout 3) I thought we'd decided that algorithm parameters were
to be handled by namespace so
<DigestMethod alg="....">
<sss:keylength>160</sss:keylength>
</DigestMethod>

Rather than with an explicit <Parameterelement

Section 3.4, Schema Definition and DTD of Element KeyInfo:

The content model is inconsistent:

Schema Definition:
"<group order='choice' minOccurs='1' maxOccurs='1'>"

DTD:
"(KeyName | KeyValue | SubjectName | RetrievalMethod | x509Data | PGPData
| MgmtData)*"

There are two possibilities:

a) KeyInfo can contain exactly one child element; then Schema Definition
is OK and the asterisk has to be omited from the DTD

b) KeyInfo can be a repeated choice of its children; then maxOccurs must
be changed to maxOccurs='*' in the Schema Definition and the asterisk
must be replaced by a plus sign in the DTD.

############################################
Section 3.4, Schema Definition Element X509Data:

The Schema Definition contradicts the textual description:

Schema Definition:
"<element name='X509Certificate' type='string' minOccurs='0' maxOccurs='1'/>"

Textual description:
"X509Data contains ... an optional collection of certificates ..."

I think the textual description is correct, so the Schema Definition should
be updated with:

"<element name='X509Certificate' type='string' minOccurs='0' maxOccurs='*'/>"

################################################

Section 3.4, DTD content model for Element X509Data:

The DTD content model contradicts both the textual description and the
Schema Definition:

"((X509IssuerSerial | X509SKI | X509Name),(X509Certificate | X509CRL)*)"

Complying with the suggested error correction above the content model should
be replaced as follows:

"((X509IssuerSerial | X509SKI | X509Name), X509Certificate*, X509CRL?)"

#################################
Section 3.5, Schema vs. DTD content model for Element Object:

Schema:
"<type content='mixed'>"

DTD:
"<!ELEMENT Object ANY>"

The mixed content model is expressed by the attribute value 'mixed' in
Schema and by the keyword "#PCDATA" in a DTD. So please change DTD part with

"<!ELEMENT Object #PCDATA>"

#####################################

Section 3.5, DTD comment:

"<!-- Where type and encoding CDATA conforms to the
productions specified by [URI] -->"

Attribute names Type and Encoding have to be capitalized.

#####################################

Section 4.1, DTD:

The content models of elements Manifest and Package are currently:

"( (Reference | Object )+ )"

In order to comply with both the Schema definition and the corresponding
sections in chapter 2 both models should be replaced with

"( Reference+, Object* )"

[Should go with original DTD]

#####################################
Section 4.2, Schema vs. DTD content model for Element SignatureProperty:

a) DTD content model for SignatureProperies is currently:

"<!ELEMENT SignatureProperties SignatureProperty >"

and should be replaced with

"<!ELEMENT SignatureProperties SignatureProperty+ >"

b) DTD content model for SignatureProperty is currently:

"<!ELEMENT SignatureProperty ANY >"

and should be replaced with

"<!ELEMENT SignatureProperty #PCDATA >"

(same as with content model for element Object).

########################################
Section 5.4.1, Schema and DTD:

Since the key values refer to the algorithm (DSA) and not to the standard
(DSS) I suggest to rename the element name from

"<element name='DSSKeyValue'>" and
"<!ELEMENT DssKeyValue (P, Q, G, Y, J?, (seed, pgenCounter)?) >"

into

"<element name='DSAKeyValue'>" and
"<!ELEMENT DSAKeyValue (P, Q, G, Y, J?, (seed, pgenCounter)?) >"

BTW: Currently the element names are different in Schema and DTD
(DSSKeyValue and DssKeyValue respectively).