Parameters and Algorithms.

I have a very different perference for how algorithm parameters are
represented that has been presented todate.  I strongly prefer the last
alternative that Mark suggested.  That is:

 <SignatureAlg Algorithm="urn:ietf-org:hmac-sha1">
    <HmacOutputLength>128</HmacOutputLength>
  </SignatureAlg>

I do not see a big problem with naming of all of the parameters and it
allows 1) for  providing  reasonable defaults for each field and 2)
preventing yet another parser from being introduced for each different
algorithm to get the parameters parsed correct.  (Just what does ",,5:1"
mean anyway?).

As part of this I would like to see some massive changes in the way that
algorithms are being presented in section 7.1.

1)  HMAC should be as follows:

<SignatureAlgorithm name="urn:ietf-org:hmac">
   <DigestAlgorithn name="urn:nist-gov:sha1"/>
</SignatureAlgorithm>

- The default digest algorithm can be defined as SHA if desired (not
necessary) and the set of recognized algorithms can be the same as for
digest algorithms.

2)  DSA does not (to the best of my knowledge) specify that SHA must be
used, this is done in the DSS standard.  Thus to mix the naming of DSA and
DSS is bad practice.  One could actually use DSA today with RIPEMD-160 as
that also produces a 160-bit hash.  Also the new AES algorithm will
undoubtly work with DSA (I don't remember if DSA or DSS specifies the sizes
of Q and P) and we should be ready for that.  So I suggest:

<SignatureAlgorithm name="urn:nist-gov:dsa">
   <DigestAlgorithm name="urn:nist-gov:sha1"/>
</SignatureAlgorithm>

- Again we can specfy SHA as the default if desired.

3)  RSA is underspecfied in the name and we should deal with the 3 (to date)
different padding algorithms that are possible for RSA.  So I suggest:

<SignatureAlgorithm name="urn:rsadsi-com:rsa">
  <DigestAlgorithm name="urn:nist-gov:sha1"/>
  <PaddingAlgorithm name="urn:rsadsi-com:pkcs1_v1.5"/>
</SignatureAlgorithm>

- Here I would recomend no default digest algorithm but we could default the
padding alg.  Additional values for this would be
"urn:rsadsi-com:pkcs1_v2.0", some name for the IEEE P1363 padding algorithm
and some string for a new OEAP algorithm (descibed here).  As part of this I
think we want to also think about the wisdom of removing the OIDs from the
signature padding algorithm.  If we want to add in a new hash algorithm,
there is no real need to put the OID value as a prefix on the digest before
encrypting the data, the hash algorithm is already covered in the SignerInfo
object and therefore is not easily changable.  As new hash algorithms come
into existance we do not want to have to wait for  and agree on an OID to be
assigned to the algorithm before it can be used.

4)  Doing this also allows us to deal with the KeyValue structures in a very
simpilar manner.  Thus one can write:

<KeyValue name="urn:nist-gov:dsa">
  <P/>
  <Q/>
  <G/>
  <Y/>
</KeyValue>

The same name is used in both the key and signature structures, just with a
different set of parameters.

jim schaad

Received on Wednesday, 13 October 1999 18:43:39 UTC