For what it's worth I've proposed a format here: http://hintjens.com/blog:62
On Tue, Oct 15, 2013 at 5:55 PM, Tony Arcieri <[email protected]> wrote: > On Fri, Oct 11, 2013 at 5:15 AM, T. Linden <[email protected]> wrote: >> >> That's a good idea but it has a drawback: if it's readable by humans >> >> it's editable by humans as well. A parser for it has to be very robust >> >> therefore. > > > Yes, this is why I'm proposing to have extremely strict rules about what's > considered a valid certificate, and also suggesting using content hashes > (perhaps in a DKIM-like fashion) to identify certificates, i.e.: if you make > any changes to a certificate, it becomes a new certificate entirely. > >> So, why not using something easily recognizable by software, encoding it >> with something like DER and putting the same information in human >> readable form into the cert as well. > > > This sounds a lot like PKCS#12 "Friendly Names", which if I was happy with > I'd just use PKCS#12 ;) > > There's a few reasons why I don't like this: > > - Duplication of information makes certificates longer. IMO longer > certificates are hard to work with > - Not all of the information is human readable. Ideally I'd like to make > everything human readable (albeit not memorable) > - I would like for humans to be able to work with the certificates without > tools, extracting bits and pieces of them (e.g. keys) without having to > resort to e.g. openssl x509/pkcs12 > > -- > Tony Arcieri > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- - Pieter Hintjens CEO of iMatix.com Founder of ZeroMQ community blog: http://hintjens.com _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
