Arvola,
I concur that (re)use of the XML Signature SignatureMethod
element
as a replacement for the existing CPP/A SignatureAlgorithm element
should be considered for the next draft.
More to the point, it would probably benefit the specification
if SignatureAlgorithm be replaced with a combination of
CanonicalizationMethod and SignatureMethod from XML Signature.
The HashFunction element should be replaced with DigestMethod
from XML Signature.
There are a couple of ways that this might be handled. One would
be to replace the SignatureAlgorithm content model (presently
a string) with the borrowed SignatureMethod and C14NMethod
elements:
replace:
<element name="SignatureAlgorithm"
type="string"/>
with:
<element name="SignatureAlgorithm">
<complexType>
<sequence>
<element ref="ds:SignatureMethod"/>
<element ref="ds:CanonicalizationMethod" minOccurs="0"/>
</sequence>
</complexType>
</element>
The other approach would be to simply have these elements as direct
children of the NonRepudiation element itself:
replace:
<element name="NonRepudiation">
<complexType>
<sequence>
<element ref="tns:Protocol"/>
<element ref="tns:HashFunction"/>
<element ref="tns:SignatureAlgorithm"/>
<element ref="tns:CertificateRef"/>
</sequence>
</complexType>
</element>
with:
<element name="NonRepudiation">
<complexType>
<sequence>
<element ref="tns:Protocol"/>
<element ref="ds:DigestMethod"/>
<element ref="ds:SignatureMethod"/>
<element ref="ds:CanonicalizationMethod" minOccurs="0"/>
<element ref="tns:CertificateRef"/>
</sequence>
</complexType>
</element>
In either case, replacing HashFunction with DigestMethod seems in order.
I concur with your point that the HMACOutputLength should be a
number.
IMHO, the CPP/A spec should simply defer/refer to the XML Signature
specification
for any description of its use so as to avoid any inconsistencies such
as this.
Cheers,
Chris
Arvola Chan wrote:
In
the 1.0 CPPA spec (lines 3116 to 3118), we have the following declarations:
<element name="HashFunction" type="string"/>
<element name="EncryptionAlgorithm" type="string"/>
<element name="SignatureAlgorithm" type="string"/>
On the other hand, the April 19,
2001 W3C Candidate Recommendation of XML-Signature shows:
<element name="SignatureMethod"
type="ds:SignatureMethodType"/>
<complexType name="SignatureMethodType"
mixed="true">
<sequence>
<element name="HMACOutputLength" minOccurs="0" type="ds:HMACOutputLengthType"/>
<any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
<!-- (0,unbounded) elements from (1,1) external namespace -->
</sequence>
<attribute name="Algorithm"
type="anyURI" use="required"/>
</complexType> This
means that the SignatureMethod element in XML-Signature may have an optional
HMACOutputLength sub-element plus 0 or more wildcard elements from other
namespaces. Shouldn't SignatureAlgorithm be defined in the CPPA spec accordingly? Likewise,
I think it may be useful to allow wildcard attributes/sub-elements in the
declaration of HashFunction and EncryptionAlgorithm to provide for the
specification of properties like encryption strength. In
addition, the following sentence on lines 874-876 does not seem to make
sense:
"As
an alternative to the string value of the ds:DigestMethod, shown
in the above example, the child element, ds:HMACOutputLength, with
a string value, MAY be used."
It does not correspond to the example
on lines 811-814 (which in itself seems erroneous, the HMACOutputLength
should be a number, not a string) or to the schema definition of ds:DigestMethod
in XML-Signature:
<element name="DigestMethod" type="ds:DigestMethodType"/>
<complexType name="DigestMethodType"
mixed="true">
<sequence>
<any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute
name="Algorithm" type="anyURI" use="required"/>
</complexType> According
to the above definition, any sub-element under DigestMethod would have
to come from some other namespace! -Arvola Arvola
Chan (arvola@tibco.com)
TIBCO Software (on loan to RosettaNet)
+1-650-846-5046 (US-Pacific)