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.


Enjoy

Jakob
--
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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to