RE: Algorithm Granularity / Othogonality

> -----Original Message-----
> From: Mark Bartel [mailto:mbartel@thistle.ca]
> Sent: Friday, October 15, 1999 12:02 PM
> To: 'w3c-ietf-xmldsig@w3.org '
> Subject: RE: Algorithm Granularity / Othogonality
> 
> 
> I vote for G.1., expressing algorithm suites as one algorithm:
> 
> a) This is how most other standards seem to do it.

This has been true, however it has also lead to an explosion of OIDs for
some things (consider RSA-with-(MD2, MD5, SHA1, ...).

> 
> b) Ambiguity is possible in the case of G.2.; I believe this 
> is the reason
> for a).  In general, the technical specification for 
> different algorithms
> may express their output in different fashions.  For example, 
> in RFC 2437
> RSASSA-PKCS1-v1_5 outputs an octet string, while in FIPS 
> 186-1 DSA outputs
> two integers (r and s).  If you were specifying an algorithm 
> that could take
> RSA or DSA as a parameter, you would need to specify exactly 
> how the output
> of each is used by the encompassing algorithm.  For the G.2. 
> method you
> could always say on the encompassing algorithm definition of 
> A that "the
> algorithm parameter must be X or Y; the output of X will be 
> encoded this
> way, the output of Y will be encoded that way" but this seems 
> to me to be
> equivalent to defining A-X and A-Y.  Might as well express it 
> that way.

I am afraid that I cannot see this as a problem at the moment.  I'll think
on it.  However it seems to me that you are going to have this problem in
the core spec today if it is really ambiguious.  What is encoded into the
SignatureValue field for DSA?  R & S or the single octect stream?  If this
is an issue we need to look at it now as we already have it.

> 
> c) G.2. can be accurately and easily expressed in G.1. fashion but not
> vice-versa because of the ambiguity issue.
> 
> -Mark Bartel
> JetForm
> 


I like G.2 since it also leads to ease of implemenation.  I can look for and
hash without having to do a table lookup on the signature algorithm and then
feed the hash back into the signature code later.

jim

Received on Friday, 15 October 1999 15:22:24 UTC