On 07/06/2017 16:43, Nick Lamb wrote:
On Tuesday, 6 June 2017 21:08:54 UTC+1, Ryan Sleevi wrote:
Standards defining organization.
More usually a Standards _Development_ Organization. I wouldn't usually feel
the need to offer this correction but in this context we care a good deal about
the fact that SDOs are where the actual engineering is done, where the
expertise about the particular niche being standardised exists.
Even in the IETF, which is unusual in having some pretty technical people
making its top level decisions, the serious work is mostly done in specialist
working groups, with their products percolating up afterwards. For most
standards bodies the top level stuff is purely politics - at the ITU the
members are (notionally) sovereign nations themselves, same for the UPU, at ISO
they're entire national standards bodies, and so on - utterly unsuitable to the
meat of standards development itself. Most expertise is instead present in
smaller, specialised SDOs in these cases.
Anyway, to Jakob's point it is _extremely_ unlikely that a new piece of
infrastructure will spring into existence fully formed and ready for use in
anger in the Web PKI without enough time for Mozilla, and m.d.s.policy to
evaluate it and if necessary update the relevant policy documents. Much more
likely, in my opinion, is that something half-baked is tried by a CA, and later
realised to have opened an unsuspected hole in security.
Nothing even prevents this policy being updated to permit, for example, trials
of some particular promising new idea that needs testing at scale, although I
think in most cases that won't be necessary. Consider the CRL signing idea,
this can be tested perfectly well without using any trusted CA or subCA keys at
all. A final production version would probably use trusted keys, but you don't
need to start with them to see it work.
Note that I also had a second, related, point: The possibility that such
a new piece of infrastructure was, for other reasons, not endorsed by
Mozilla, but of great interest to one of the other root programs (not
all of which are browser vendors).
Conversely consider the possibility that some other root programs had a
similarly restrictive policy and refused to support the introduction of
CT PreCertificates. This could have stopped a useful improvement that
Mozilla seems to like.
The Golden rule would then imply that Mozilla should not reserve to
itself a power it would not want other root programs to have.
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
dev-security-policy mailing list