On Mon, 2017-07-03 at 15:12 +0100, Gervase Markham wrote:
>
> > I think the new format should be as complete as possible, including both
> > trust
> > and distrust information, including EV and description of rules for partial
> > distrust.
>
> I agree, as long as we can stay away from defining a format of arbitrary
> complexity.
I agree the complexity shouldn't be part of the format. It might be sufficient
to have an identifier for the type of restriction, which is described elsewhere,
plus a flexible list of {name,value} pairs for parameters.
> > Regarding the question how we create new entries for certdata.txt today, we
> > currently use the NSS tool "addbuiltin". It takes a certificate as input,
> > and
> > can create both positive trust or distrust lines in the current file format,
> > that we simply appended to the certdata.txt file.
>
> Ah, OK. So you would not be against the idea of using a tool to maintain
> the list in the future?
Do you have a particular kind of tool in mind?
I'd prefer a simple open source tool that operates on files, which can be used
from a command line, with a free license, e.g. MPL2.
> > Regarding which file format should be used for the new master trust list.
> > Unless
> > we want to change the way how NSS works, it will probably be helpful to
> > continue
> > to use the certdata.txt file format, even if it's just used as an
> > intermediate
> > in a double conversion.
>
> I certainly think we should continue to maintain the store in that
> format. The question is whether that format is the canonical format, or
> a derivative format. My feeling was that if we want to be able to add
> these new forms of restriction, EV status and so on, we should define a
> new format. Ryan seems to think we may be able to do this within the
> existing certdata.txt format.
I don't have a strong preference.
I agree that it should be possible to extend the existing certdata.txt file
format. For meta level items that NSS cannot consume yet, we could define new
identifiers that NSS ignores (or might potentially process at a later time).
However, the certdata.txt file format was built specifically around the needs of
NSS, and we currently have the flexibility to change it in any way we want to.
Also it's based on the idea that the file elements will rather directly
converted into PKCS#11 objects. Other root stores might not use PKCS#11 to store
their list of root CAs at all.
If the intention is to define a file format that is shared with other groups,
who would be the owner of the file format? What if another group needs to
introduce additional fields into the file format, that aren't of interest to
Mozilla or NSS?
Having a more abstract file format could give anyone more flexibility to add
more information, that don't need to be coordinated with others prior to adding
them, and allows consumers to ignore the fields they aren't interested in.
For example, some root store maintainer might invent the golden circle of CA
vouching, which everyone else considers questionable. It might require to store
a flexible list of vouchers for each CA. With JSON it would be trivial to add
another arbitrary length list for that.
So, if the intention is to have a shared file format that everyone can accept,
today and in the future, a more flexible file format seems more appropriate to
me.
> > Instead of requiring everything to be a single file, maybe it could even
> > work to
> > use an archive file (e.g. zip), that contains all information in easily
> > consumable pieces, which would make it unnecessary to serialize and
> > deserialize
> > the certificates while working with the list, and allows maintainers to use
> > tools that work with the certificates directly.
>
> I think that runs the greater risk of people creating systems which just
> trust every certificate in the bundle...
There could be ways to avoid that, for example by using subdirectories, named
like:
- trusted-for-ssl-tls-only
- partially-trusted-for-ssl-tls-only
- trusted-for-email-security-only
- partially-trusted-for-email-security-only
- trusted-for-multiple-uses
- partially-trusted-for-multiple-uses
- distrusted
This is just a thought. If there's too much doubt, I don't mind to stay with the
concept of having a single file that contains serializations of all attributes.
> > With this approach, we could also declare that the master location for this
> > trust list is somewhere outside of NSS (in a separate repository). If we did
> > that, the primary location could simply be its own HG/GIT repository, with
> > all
> > the individual files. Releases of Mozilla trust list could be an archive
> > file
> > that gets published with a checksum file/signature.
>
> We could do this with any approach. Are you interested in the idea of
> making the trust list an independently-maintained item, which is just
> pulled into NSS each time an NSS release is done?
Yes, I had previously suggested this here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1294150
It would make it easier to publish new versions of the root CA list,
independently of software versions.
Converting and copying a snapshot of the root CA list into the repository of a
software project, to make it clear which data set was used by a particular
software release, might sufficiently address the concerns that had been raised
in that bug.
Kai
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
