[zeromq-dev] Certificate formats

T. Linden tlinden at cpan.org
Wed Oct 9 15:46:13 CEST 2013


Hello all,

first of all: I only subscribed to the list today and wasn't aware of
the discussion about certs here, but I've read the posts on the topic in
the archive.

Some time ago I started to write a tool to generate curve keypairs just
like "makecert", which is part of CZMQ but with some enhancements. Among
them is the possibility to encrypt the secret key. It's on github:
https://github.com/TLINDEN/curve-keygen.

So, here are my 0.02 cents about the certificate issue:

I don't want to have yet another PKI for curve keypairs. There are some
things a certificate requires though: an identifier, some kind of CN and the
like, just like the meta-data already present in zcert_t certificates.

But if you start adding stuff like issuers, certificate chains, signing
and so forth, you'll end up with certificate authorities, maybe you'll
have to pay to get an "official" curve certificate just like it is today
with ssl certificates. This would lead to the same problems of CA's
we've got today: a CA can be compromised (by rogue intelligence agencies
for example, or malicious attackers) and due to the certificate chaining
feature it'll become overly complicated.

So, in my opinion, if this is what would be required, then just stick
with X.509 and SSL. There's no need to re-invent the very same
monstrosity. Just replace the RSA keys with curve keys and that's it.

My requirements of a certificate format would be:

- It should support an arbitrary number of meta data in simple key/value
  form and should not depend on the existence of a certain meta key. In
  the most simple case, I'd need the actualy key only. So, a certificate
  should still be valid even if there are no meta information contained
  at all.

- Encryption of the secret key should be mandatory and standardized. I'd
  suggest using secret_box() as I used in curve-keygen. The encrypted
  secret key should be armored (e.g. using Z85) and marked using a
  header and a footer.

- The encrypted secret key should contain everything to restore the
  public key from it, including all meta information.

- Both the secret and the public key should be in some serialized form
  (the secret key encrypted after serialization though), so reading a
  key should require not more than:
    - read in the file
    - feed it into a de-serializer
    - get the complete structure back
  So, as some already sugested, something as YAML or JSON should be used
  internally.

- Both keys should contain a checksum over this structure. So, instead of
  parsing and checking each meta data separately, a programmer just has
  to verify this checksum which tells him the certificate is properly
  formatted and hasn't been tampered with (this is not a signature!).

- Stuff like signatures, issuers, expire times and so on should be
  optional.



Best regards,
Tom

-- 
    PGP Key: https://www.daemon.de/txt/tom-pgp-pubkey.txt
S/Mime Cert: https://www.daemon.de/txt/tom-smime-cert.pem
 Bitmessage: BM-2DAcYUx3xByfwbx2bYYxeXgq3zDscez8wC

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the zeromq-dev mailing list