[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: public key algorithm naming
-----BEGIN PGP SIGNED MESSAGE-----
Eric,
thank you for the detailed explanation.
You have effectively demolished my (II) and (III) straw-men.
As I noted in my previous message, the urgency is off this decision since I
believe the BNF remains the same no matter which way we go on this.
However, I think you're raising an important issue.
At 04:10 PM 3/12/98 -0800, EKR wrote:
>I agree that this is slightly more complicated, but I think that
>this complication is worthwhile, because it adds substantial flexibility.
>I agree that simplicity is a virtue, but so is flexibility. And the
>simplicity you want to achieve in this code comes at the cost of
>complexity in other code.
First of all, I am inclined to agree with you on these points. I like
flexibility. OTOH, I've been beaten up severely at IETF meetings on just
this issue. :)
That aside, ...
you mention:
1. hash algorithm negotiation in SSL and maybe other protocols; and
2. strange signing mechanisms (which might show up as hashing or packing
algorithm names in public key structure definitions).
I recognize (1) but I am not very sympathetic. If we're going to allow
negotiation of hash algorithm, why not of public key algorithm? I suspect
the reason we see hash algorithm negotiation is because we have a bunch and
we can't tell how good they are, so some protocol designer prefers to leave
the binding to the last minute, complicating the protocol. It doesn't
bother me a great deal to do negotiation of whole packages (e.g., in the PGP
case, you have public key algorithm, hash algorithm and symmetric algorithm
flexibility). If you can negotiate whole packages, then you can bind those
together into key structure definitions.
Let me modify my statement here. Part of me likes the flexibility and
negotiation of everything could be just great. It could maximize the number
of people you connect to. However, it could also lead to the annoyance in
SSL of making a "secure" connection that got negotiated down to 40-bit
symmetric crypto.
Anyway, I'm of two minds on (1). Part of me really likes the flexibility
but part of me is wary of it.
Your (2) suggests that a single key with a single certificate might be used
in some unusual protocol that just came up at the spur of the moment. I
don't think that matches reality. I have several PGP keys and have had them
for a long time, but when I installed my firewall tunnel and it needed a
public key, I got a new one for that purpose. In the old days, it was
expensive to generate an RSA key. Today it isn't. It might even be a
security weakness to use one key too many places. I don't know of any, but
there is the general rule of thumb that the more keys you use, the better.
Even if I were to use the same key for multiple purposes, each purpose would
need a new certificate. SPKI, at least, doesn't generate one-size-fits-all
certificates. When you generate that new certificate, you can attach the
appropriate verification algorithm name.
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3
iQCVAwUBNQlYsBN3Wx8QwqUtAQHxcAP8D4dUP9ehPV7GT0nqKhweKlNXx5o4EXpY
+jJKhfPfIbrEPAWj5lL0ZuW+ATz+Oq4QXpES7mgJ2aXQ+nnWWiChr6BB2oMM2hsu
M1RG9mcJDy3+65RIMB7Q/cIfsHTTsbQOpSqPTWGsGQXvgNsI43ZtJQ+17S8zF1Ke
W67nc6OOdJU=
=hHPQ
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc. http://www.cybercash.com/ |
|207 Grindall Street PGP 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
+------------------------------------------------------------------+
Follow-Ups:
References: