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

-Justin



More information about the Standards mailing list