ietf-openpgp
[Top] [All Lists]

undefined MAY algorithm example (Re: Question and note)

1998-06-29 19:18:18

Uri Blumenthal writes:
dontspam-tzeruch(_at_)ceddec(_dot_)com says:
.........
I would rather delete every assigned algorithm number that isn't likely to
be implemented for public consumption than to have those show up, one per
implementation so no two implementations can talk except with RSA/IDEA/MD5
or DH/DSA/SHA1/3DES since my code will be much smaller if I just
implement these two subsets exactly.  

MAY are the algorithms that is entirely up to you to have or not to
have. So the keys that are "for real" aren't likely to be of one of
them... 

I just read the spec end to end, and I think I found an example of the
sort of problem Tom is referring to, from:

http://www.ietf.org/internet-drafts/draft-ietf-openpgp-formats-05.txt

: 9.1. Public Key Algorithms
: 
:        ID           Algorithm
:        --           ---------
:        1          - RSA (Encrypt or Sign)
:        2          - RSA Encrypt-Only
:        3          - RSA Sign-Only
:        16         - Elgamal (Encrypt-Only), see [ELGAMAL]
:        17         - DSA (Digital Signature Standard)
:        18         - Elliptic Curve
:        19         - ECDSA
:        20         - Elgamal (Encrypt or Sign)
:        21         - Diffie-Hellman (X9.42)
:        100 to 110 - Private/Experimental algorithm.
: 
:    Implementations MUST implement DSA for signatures, and Elgamal for
:    encryption. Implementations SHOULD implement RSA keys.
:    Implementations MAY implement any other algorithm.

This is wrong.  For example (as Tom has been pointing out) it says
Elliptic Curve.  But then it says:

:    Implementations MAY implement any other algorithm.

implying that 18 for Elliptic Curve is more than reserved, in fact
_stating_ that you MAY go ahead implement it.  

PROBLEM: no definition of any Elliptic Curve parameters.

I would suggest either deleting 18, 19, 21, or marking them as
reserved (which means you MUST NOT borrow this ID number for your
variant/interpretation of how one might implement this algorithm).

Btw what is 21, is this real Diffie-Hellman? or Elgamal referred to as
Diffie-Hellman?  And how can real Diffie-Hellman work as a OpenPGP
cipher because you can't choose the negotiated key, and therefore
can't store information inside the ESK as with other keys.

MAY class says: "If you decide to do this - here is how it must be
done." So that *if* two implementations both have a common subset of
the MAY class, they could interoperate using them, too.

Precisely.  But as Tom says, and as the exerpt from the draft above
demonstrates, the draft is listing things as MAYs which are not
defined at all.

Adam
-- 
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

<Prev in Thread] Current Thread [Next in Thread>