digital signature comments

[Greg Whitehead <[e-mail]>]

I'm new to the mailing list, so forgive me if these points have been
discussed before.  I'm looking forward to meeting everyone at the upcoming
meeting in DC.

First, I come from the PKIX world, so my attention was immediately drawn to
the digital signature aspects of the proposal:
	[1] draft-ietf-trade-iotp-v1.0-dsig-03.txt
	[2] draft-ietf-trade-hiroshi-dom-hash-03.txt

I understand that v2 of the IOTP protocol may use a completely different
signature syntax, based on the XMLDSIG WG output, but I offer the following
comments on the v1 syntax [1] in the interest of producing interoperable
implementations:

3.3 OriginatorInfo and RecipientInfo
------------------------------------

These are both familiar terms from S/MIME CMS, but I was initially confused
by the inclusion of RecipientInfo in a signature.

In CMS, a RecipientInfo is used to exchange a symmetric cipher key with a
recipient (using either RSA or DH) when encrypting data for that recipient.


OriginatorInfo was expected, as it is used in CMS when signing with DSA (but
not with RSA). It's role has been expanded in IOTP-DSIG to identify the
signer, which is fine (that info appears elsewhere in CMS).

I eventually figured out that the intent of including RecipientInfo was to
enable "signature" algorithms based on shared secrets.  I suppose that's
fine as long as the properties of these algorithms are well understood: the
proposed HMAC signature, for example, couldn't be used for non-repudiation
since the recipient could trivially forge the signature.

4.3.1 Signature
---------------

>From the text:

>  The process for generating the signed value is a multi-step process,
>  involving a canonicalization algorithm, a digest algorithm, and a
>  signature algorithm.
>
>  First, the Manifest is canonicalized with an algorithm specified
>  within the Algorithm element of the Manifest. The canonicalized form
>  removes any inconsistencies in white space introduced by XML parsing
>  engines.
>
>  This canonicalized form is then converted into a digest form which
>  uniquely identifies the canonicalized document. Any slight
>  modification in the original document will result in a very different
>  digest value.

This suggests that a canonicalization algorithm must be specified in the
Manifiest (section 4.3.2), yet the Algorithm type (section 4.3.3) provides
no way to do that. 

It appears that canonicalization has been folded into the digest algorithm,
which makes sense since the two are sometimes inseparable (DOMHASH), but
this should be clarified.

If DOMHASH is, in fact, meant to include canonicalization, it would be good
if its spec [2] provided specific details (along with test cases and their
respective digest values).

4.4.2 IssuerAndSerialNumber
---------------------------

As used in CMS, IssuerAndSerialNumber is a binary structure lifted directly
from the certificate.  In IOTP-DSIG, the issuer name (X.500 DN) and serial
number (ASN.1 Integer) are each represented as strings.  Unfortunately,
converting DNs to strings is non-trivial (internally, DNs are binary
structures that use ASN.1 OIDs to identify attributes and determine the
encoding of their values).

If IssuerNameAndSerialNumber is simply meant to serve as an opaque
identifier, to name Certificate elements included in IOTPSignatures, then
there is no problem: any scheme that produces unique identifiers will work
(why not just use an IDREF in that case?)

If, however, it is meant to serve as a key for locating certificates in an
external repository, such as an LDAP directory, then the format needs to be
more precisely specified.  I would suggest rfc2253 (LDAPv3: UTF-8 String
Representation of Distinguished Names) as a starting point:

	http://www.ietf.org/rfc/rfc2253.txt

-Greg

--
Greg Whitehead
Chief Scientist
Signio, Inc.
1600 Bridge Parkway, Suite 201
Redwood City, CA  94065
650-622-2250
650-622-2201 (fax)
[e-mail]
http://www.signio.com
-----------------------------------------------------------------------
Message addressed to: [e-mail]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [e-mail]