On Fri, Oct 4, 2013 at 12:44 PM, Tony Arcieri <basc...@gmail.com> wrote:
>
> This is a nice start! Some comments:
>
> - Blocks are good. Yay!
> - This looks somewhere in the middle of YAML and TOML/"INI". Would it be
> worthwhile to adopt one of these conventions? Perhaps a subset of YAML?
>
- That said, you have [...] blocks like TOML/"INI" but indentation like
> YAML. I think I kind of like it despite the fact it's a bit of a wacky
> combo ;)
>
The example was just thrown together as a straw-man of possible content.
These days I generally lean towards using JSON as the format unless there's
a good reason to do otherwise. It's simple (enough), ubiquitous, well
defined, and most languages have several off-the-shelf parsers for it. It's
not as pretty as TOML/YAML but, to my mind at least, it's good enough.
> - What is the source of the UUID? Random? Deterministic? I think it would
> be good if certificates had a canonical, "distinguished" form which is
> completely deterministic. Given the same inputs we should arrive at the
> same certificate every time
>
I haven't put a whole lot of thought into this but it seems to me that the
top-level UUID should be a random UUID that ties the cert content to some
"thing" (person, machine, etc). For some applications, the UUID alone would
be sufficient. For others, they may wan to use a DN or a similar
equivalent. Maybe it's not even worth putting in as a required value. Seems
like a good idea off hand but that's suspiciously similar to "it seemed
like a good idea at the time".... so maybe not. I hadn't thought of the
UUID being derived from the content. It's an interesting idea but it would
negate the possiblity of the cert changing metadata over time. Which could
be a good thing depending on what you're shooting for.
> - You have a signatures section. What part of the document actually gets
> signed? Wouldn't it make more sense for the signature to be independent of
> the certificate?
>
I should think the signatures would cover everything in the cert that isn't
in the signatures block itself. They're logically distinct but a cert
without signatures doesn't seem very useful. I can't think of many use
cases for "give me your cert but don't bother providing the means to verify
it".
> What algorithm is used for the signature, and how do you specify that?
> - You have no info about what the public key is. What cipher is it using?
> I think keys should be URIs
>
Good questions. Assuming JSON encoding it could be an object with key-value
fields for each of those parameters. A URI solution sounds cool but I'm not
sure what that'd look like.
> Some other notes on "minimum requirements" for a certificate format, IMO:
>
> - The certificate format should be describable by a Parsing Expression
> Grammar
>
What's the advantage over JSON with a defined order for hashing values
(lexically sorted order comes to mind).
> - Certificate chains must be supported. We should always think of the
> certificate language as being N blocks long
>
Nested JSON objects leap to mind. { "signature":... "parent_signature" : {
"signature"....} }
> - Order of certificates/keys in a chain shouldn't matter
>
> Other general suggestions:
>
> - Private keys should be separate from the certificate but can be combined
> into a chain
> - We need a way to encrypt private keys!
> - Certificates IDs should be content hashes
> - We should sign the Certificate ID
> - We should be able to append the signature to the certificate chain
>
> --
> Tony Arcieri
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
