ietf-openpgp
[Top] [All Lists]

Re: DEADBEEF vs SHA1

2011-02-18 12:41:32

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think it's very important to understand the distinction between the 
protocol(s) we have and machines that implement the protocols. Those machines 
can be APIs (e.g. OpenPGP SDK, Bouncy Castly, etc.) applications (e.g. GnuPG, 
PGP Desktop), appliances (e.g. PGP Universal), but they are not the same thing. 
It's perfectly fine for an application to do some right thing that is not 
supported by some protocol.

For example, when I was at PGP Corporation, I used to say a lot that OpenPGP is 
a standard (and a protocol), but PGP is software. The PGP Software implements 
the OpenPGP protocol, but it also implements the S/MIME protocol, as well as 
SSL/TLS, X.509, SMTP, and so on. 

It's with that in mind, the difference between the protocol and software is an 
important part of this discussion.

I agree with Ian completely that there are people who have old (v3 key) 
encrypted and signed data that they need to get to. Decrypting data is the most 
important thing. I'm sure that I have some things in old backups that maybe I'd 
like to decrypt some day without having to break the key they're encrypted to.

There are a number of ways to deal with this. For example, I could have a copy 
of PGP 2.6.3 lying around and use that to decrypt my old things. That's only a 
mild inconvenience. Similarly, PGP or GnuPG could keep v3 keys around *as* 
*software* for such archival purposes. It might even make sense from a user 
experience aspect to have them in historic keyrings that are not in one's face 
every day. Or GnuPG could handle it despite it not being any longer standard, 
or ....

The bottom line is that a key id in that context is a 64-bit binary key into a 
database. That's all that it is. Yeah, it's derived with a function, but it's 
just a key.

IETF RFCs are not programming manuals. They are also not requirements documents 
for applications. They are descriptions of how to properly interoperate, and 
that's all. Application designers still have to think.

        Jon


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.10.0 (Build 554)
Charset: us-ascii

wj8DBQFNXrqFsTedWZOD3gYRAj16AKCZ5TrOlbYAj6Zb0xyLCNkbA2NKPQCgriab
hjgYuRyiS625/fIrFoaUqB4=
=BuD3
-----END PGP SIGNATURE-----

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