Re: digital signature comments

["Donald E. Eastlake 3rd" <dee3@torque.pothole.com>]

Greg,

I think that the DOMHASH document makes it pretty clear that its
output is a message digest.  This is certainly less flexible than
specifying canonicalization and digesting separately but, given
the plan to convert to the XMLDSIG standard when it is set for
future versions of IOTP, I don't see this as much of a problem.

On dinstinguished names, I also tend to think the view of them
as opaque identifiers within IOTP is the simplest.  On the other
hand, does anyone see any problem with recommending or speicfying
use of the RFC 2253 syntax?

Thanks,
Donald

From:  Yoshiaki KAWATSURA <kawatura@bisd.hitachi.co.jp>
Message-Id:  <199909240356.MAA21734@bisdmail.bisd.hitachi.co.jp>
To:  ietf-trade@lists.eListX.com
Cc:  kawatura@bisd.hitachi.co.jp
Date:  Fri, 24 Sep 1999 12:56:13 +0900 (JST)

>Hello Greg,
>Thank you for your feedback.
>My comments below.
>
>>>>>> Tue, 21 Sep 1999 13:56:07 -0700,
>	Greg Whitehead <gwhitehead@signio.com> said:
>
>>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).
>
>I understand.
>If we want to use the canonicalization algorithm, which can not be hashed
> by itself, we need to use Parameter element as follows:
>
><Algorithm name='urn:fips:sha1' type='digest' ID='P.3'>
></Algorithm>
><Algorithm name='urn:w3c:C14N' type='digest' ID='P.4'>
> <Parameter type="AlgorithmRef">P.3</Parameter>
></Algorithm>
>
>Of course, I know C14N is not digest algorithm, but if we revise that
>'canonicalization' is added as the type parameter, we have to revise
>the IOTP Specification also(though this is minor change...).
>As results, I do not change until other people appeals to want to do it.
>
>>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
>>
>
>I assume the first case but the second case is very interested for me.
>I suggest this issue should be discussed in the xml-dsig WG.
>
>Thanks,
>----
>Yoshiaki Kawatsura : E-mail kawatura@bisd.hitachi.co.jp
> Business & Information Systems Development Division, Hitachi,Ltd.
>Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
-----------------------------------------------------------------------
Message addressed to: ietf-trade@lists.elistx.com
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: ietf-trade-request@lists.elistx.com