[Top] [All Lists]

Re: I have a technical idea/change for the ECC draft

2008-04-15 14:28:38

Hash: SHA1

On Apr 15, 2008, at 5:25 AM, Ian G wrote:

A high level / managerial perspective.  Apologies in advance for  
where it drifts from actual specifications.

We are deep down the rabbit hole known as

   _profiles v. algorithms_

It is worth standing back and thinking about this because when V5  
keys are looked it, it is possible that we could solve this.

PGP was designed in the early 90s when algorithms were thought to be  
all there was to crypto.  Now, we know that's wrong [1].  Now, we  
know it is all about applications and users, and they want  
communication before security, and security before crypto.  From a  
crypto standpoint, profiles are the only way forward, because they  
remove interoperability issues, which improves communications.

But, still, today, OpenPGP prefers to indicate algorithms not  
profiles, so what to do?

 From here, nothing. This is layering. At the bottom layer, there's  
the algorithms, as you note. A layer up from that you get profiles.  
The profiles can either be implicit in the implementation, or they can  
be explicit in some standard.

I would actually say that there's the raw algorithm (like AES), the  
extended algorithm (like CFB), and the protocol (like OpenPGP). Above  
that, as you note are the profiles. This isn't even a Kerchoff issue,  
it's a systems engineering and design issue. If you don't give the  
implementers liberty, they can't do cool things no one else thought  
of. If you give them too much liberty, they write crap. Between those  
two problems is wisdom.

I have no personal interest in making profile documents. I support  
other people who have such interest. The profiles do exist, however.  
They're just implicit in the application.

I think it's better for ECC/SuiteB to have them implicit. But if  
someone else wants to do the work, sure.


Version: PGP Universal 2.6.3
Charset: US-ASCII