[Standards-JIG] The Great Encryption Debate
justin-keyword-jabber.093179 at affinix.com
Wed Aug 17 19:15:02 UTC 2005
On Tuesday 16 August 2005 02:34 pm, Ian Paterson wrote:
> I was convinced of the case for D-H in March when Peter put me in
> contact with one of the IETF "crypto mafia" (he teaches crypto at MIT).
> I asked him about using RSA instead of D-H. He patiently explained that
> it is less secure for several reasons (no Perfect Forward Security and
> "with D-H you are as secure as the best Random Number Generator in the
> negotiation, [with RSA offline messages] you are vulnerable to the worst
I agree that DH is the answer for session encryption, and I'm not saying we
shouldn't use it.
At this point I've almost forgot what I'm even arguing. I mean, I want to use
DH, too, so there's no need to prove it to me. I guess what I'm trying to
say is that the object-based security is simply easier, and there might be
some people out there that would only want to implement that instead of doing
the full-on Esessions. However, since I'm not one of them, perhaps this
portion of the thread should be ended. :)
The more I think about it, the more I like the idea of confining object-based
security to sign-only.
> More seriously, for one to many signing (like groupchat and pubsub) we
> do need a different protocol. Just a simple PKCS #1 (RFC 3447) signature
> of canonical (or base64?) XML and a Public Key ID (digest of RSA key)
> would do the trick. Optional non-repudiable authentication would also
> complement JEP-0116 (for rare on-the-record legal conversations).
Again, I would recommend using some existing high-level format for this, as
other folks have already put effort into figuring these things out. My vote
goes to S/MIME (or perhaps more specifically, CMS) since it is compact, but
xmldsig might be fine, too. Both of these formats support multiple
algorithms (good for being future-proof).
> > Sort of. Obviously JEP-27 has got to go, mainly because it
> > isn't modern. Extending RFC 3923 to support PGP or other
> > stuff would be one answer.
> We need to explore what that would involve then.
One idea I've had is to make some sort of PGP -> X.509 compatibility scheme,
because most protocols these days are based around X.509 and its primitives
(notably TLS, but also S/MIME, xmlenc, xmldsig, etc). This could be done by
having the client generate a self-signed certificate and then PGP-sign it.
Now the certificate could be used for c2s authentication (TLS), file transfer
(TLS), and RFC 3923 (S/MIME). With this in mind, maybe RFC 3923 doesn't need
to be modified at all. We'd just need a separate PGP -> X.509 JEP.
In my opinion, then, it would be worthwhile to standardize on X.509
certificates (and in this case I really do mean the certificate format, not
subjectPublicKey) as a key format, even if it is simply used in an
"ssh-style" manner (ie, self-signed, fingerprint-checked, cached).
This covers all 3 main scenarios:
1) "real X.509" (CA-signed X.509 cert)
2) PGP (PGP-signed self-signed X.509 cert)
3) "ssh-style" untrusted key (self-signed X.509 cert)
I believe there was an OASIS effort in the last year or so (maybe PSA
remembers better...) that standardized on self-signed X.509 certificates. It
may sound silly to use X.509 without a CA, since security-wise that's no
better than simply using plain RSA keys. I would assume the reason had more
to do with choosing a future-proof standard format.
Now when I write a Secure File Transfer JEP, I can just say "use TLS" and be
done with it. No need to talk about all the different kinds of keys that
might be involved.
More information about the Standards