[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: public key algorithm naming



	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

Version: PGP for Personal Privacy 5.5.3


|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: