On 18/11/2016 02:43, Brian Smith wrote:
Ryan Sleevi <r...@sleevi.com> wrote:
On Thu, Nov 17, 2016 at 3:12 PM, Nick Lamb <tialara...@gmail.com> wrote:
There's a recurring pattern in most of the examples. A technical
counter-measure would be possible, therefore you suppose it's OK to
screw-up and the counter-measure saves us. I believe this is the wrong
attitude. These counter-measures are defence in depth. We need this defence
because people will screw up, but that doesn't make screwing up OK.
I think there's an even more telling pattern in Brian's examples -
they're all looking in the past. That is, the technical mitigations
only exist because of the ability of UAs to change to implement those
mitigations, and the only reason those mitigations exist is because
UAs could leverage the CA/B Forum to prevent issues.
That is, imagine if this was 4 years ago, and TCSCs were the vogue,
and as a result, most major sites had 5 year 1024-bit certificates.
The browser wants the lock to signify something - that there's some
reasonable assurance of confidentiality, integrity, and authenticity.
Yet neither 5 year certs nor 1024-bit certificates met that bar.
The fundamental problem is that web browsers accept certificates with
validity periods that are years long. If you want to have the agility to
fix things with an N month turnaround, reject certificates that are valid
for more than N months.
In fact, since TCSCs that use name constraints as the technical constraints
basically do not exist, you could even start enforcing even stricter
enforcement than other certificates. For example, externally-operated name
constrained intermediates could be limited to 12 months of validity even if
other certificates aren't so restricted. Just make sure you actually
enforce it in the browser.
If you have a better plan for getting people to actually issue TCSCs of the
name constrained variety, let's hear it.
(Please ignore the fanatics trying to shout down any attempt to get
privacy working in the real world).
A reasonable thing would be the following, as already *required* by the
basic certificate specs (x509 etc.):
- The effective end date of any cert is the smaller of the end dates
of all certificates in the currently considered chain (which may
differ depending on configuration etc.) That provides the needed
deadlines without additional rules.
The following polices and technical measures would encourage use of
name constraints:
- End entity name constrained 3rd party intermediary CA certificates
must be validated to EV standards and confer green bar etc. with the
green bar related owner information displayed being that of the
end-entity name constrained intermediary, not the lower certificates.
They must *also* be EKU restricted as either of the categories
accepted for end entity certs.
This means that for browser/mailprog user security, the certificates
issued by those constrained CAs would be no worse than the security
from protocols that generate temporary public keys on the fly, such
as TLS ciphers with PFS (DHE, ECDHE etc.).
- TLD/public suffix constrained name constrained 3rd party
intermediary CA certificates remain subject to the full set of BR
requirements, but are allowed to be subject to national legislative
requirements such as SM ciphers in China or special practices in
Belgium.
- Future acceptance of national CA roots into the root program
could/should be conditional on those CA roots being name restricted
to their particular country. For multi-TLD countries (US has .us,
.gov, .mil and .edu, CN has .cn, .hk etc., DK has .dk, .gl and .fo,
etc.) name constraints allowing that set of alternatives or a subset
would be accepted.
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
