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. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
