On Thu, Jul 6, 2017 at 10:57 AM, Gervase Markham <[email protected]> wrote:
> On 05/07/17 18:08, Ryan Sleevi wrote:
> > That is, the difference between, say:
> > "label": "Verisign/RSA Secure Server CA"
> > And
> > CKA_LABEL "Verisign/RSA Secure Server CA"
>
> Not much, but you've picked the clearest part of certdata.txt to compare
> :-)
>
Sure - because you haven't given much of a sense for what human readability
means. That is, whether or not \104\143 is more or less readable than 68:8F
(hex) or aI8= (base64) or NCHQ==== (base32), as an example.
The presumption here seems to be "format that I'm familiar with", but
that's a fairly subjective read. We already have machine-readability, and
we've established that tool-generation is strongly preferred (both for
correctness and consistency), so human-writability does not seem like it's
agreed upon goal. So where does human-readability factor in, and does it
make more sense to derive human-readability from the existing
machine-readability?
>
> > It isn't, because JSON can't.
>
> As Rob notes, you can basically have them in all but name.
>
I don't think that really holds, but I'm surprised to see no one pointing
it out yet.
For example, there is a meaningful difference between
# This is the CA with serial abcd
CKA_LABEL UTF8 "Verisign/RSA Secure Server CA"
# This is the hash 00:ab:cd:ef
CKA_CERT_SHA1_HASH MULTILINE_OCTAL
\104\143\305\061\327\314\301\000\147\224\141\053\266\126\323\277
\202\127\204\157
END
If you wanted to express that in JSON, using Rob's bit, you'd end up with
{
"label": "VeriSign/RSA Secure Server CA",
"comment": "This is the CA with serial abcd"
},
{
"sha1_hash": "\x00\xab\xcd\xed",
"comment": "This is the hash 00:ab:cd:ef"
}
Except that wouldn't be a valid JSON string (or at least, not all
expressible byte sequences are, as they'd result in invalid unicode
sequences), so you'd have to do a further transformation, such as base64
decoding (or de-hexing), which means its once again less human-maintainable.
I suspect we're at the risk of ratholing here, but the lack of JSON
comments is a well-known limitation that continually negatively affects
those who pursue JSON schemas, so we should not be so quick to brush away
what is frequently a maintenance compliant.
> > Would you see it being as independent, or subservient to Firefox? If you
> > saw it as independent, then you would presumably need to ensure that -
> like
> > today - Firefox-specific needs, like EV or trust restrictions, did not
> > creep into the general code.
>
> I don't think that follows. EV trustworthiness is a property of the root
> store. The root program makes those decisions, and it's entirely
> appropriate that they be encoded in root program releases. We also make
> decisions on "trust restrictions", so I'm not sure why you call that a
> "Firefox-specific need".
>
EV trustworthiness is an aspect of the application code - in this case, a
Web browser with UI surface being exposed. Do you believe EV makes sense
for, say, a utility like cURL or wget? Or for an application like PHP? Does
the EV issuance status of a CA affect something like Thunderbird?
Or consider other stores - like Chrome - in which EV-SSL status is granted
not solely by the presence of policy, but the associated Certificate
Transparency information. One cannot equivalently determine EV status
solely based on a policy status - it's more than that.
> > Of course, it seems like your argument is you want to express the Firefox
> > behaviors either directly in NSS (as some trust restrictions are, via
> code)
> > or via some external, shared metafile, which wouldn't be relevant to
> > non-Firefox consumers.
>
> Perhaps this is the disconnect. Several non-Firefox consumers have said
> they are very interested in an encoding of the root program's partial
> trust decisions.
>
Could you recall where this happened? It doesn't seem from this thread,
beyond Kai's remarks, but perhaps you're evaluating against the previous
threads?
No, because they could consume whatever copy of the upstream file
> Firefox had imported.
>
> I don't expect "Mozilla's root store's trust view" and "Trusted by
> Firefox" ever to diverge, apart from due to time skew, and perhaps
> occasionally due to unencodeable restrictions.
>
But they already do, regularly. Compare Firefox ESR with Firefox Beta with
Firefox stable, and then compare that with NSS releases (and different OS
distributions of those releases). There is already an inherent divergence.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
