[Standards-JIG] The Great Encryption Debate

Justin Karneges 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
> one").

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