On 18/10/2016 14:35, Gervase Markham wrote:
On 17/10/16 16:35, Jakob Bohm wrote:
In the not so distant past, the Mozilla root program was much more
useful due to different behavior:
1. Mozilla managed the root program based on an assumption that relying
parties would use the common standard revocation checking methods
*only* (regular CRLs as present since Netscape created SSL and OCSP).
Now is not the time to re-debate the failings of those methods, but
please don't pretend you don't know why this change was made.
I wasn't in this instance, simply noting the following problem: By
assuming all relying parties run code that implements Mozilla's other
revocation methods (OneCRL, custom notBefore checks etc.), the root
list published by Mozilla becomes less useful for relying parties whose
applications do not.
2. Mozilla managed trust bits and inclusion policies for https,
non-https TLS (e.g. imaps, pops and smtps), e-mail S/MIME, and
generic object/code signing. Again, this was true since the days
when this was the Netscape Navigator trust list.
We still do manage for HTTPS and email. There was never a separate trust
bit for non-https TLS; why is the trust and the requirements for that
different in practice from HTTPS TLS?
While Mozilla officially manages trust bits for e-mail, at least one
key participant in these threads repeatedly argues as if this was not
Non-https TLS is not (and should not be) a separate trust bit from
https, but sometimes the logic applicable to trust policies, BRs etc.
will be slightly different if one doesn't ignore non-https use of TLS.
I have encountered arguments and policies that are valid only for the
specific case of up-to-date-web-browser https.
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