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

Re: DEADBEEF vs SHA1



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