On 07/09/2017 21:00, Ryan Sleevi wrote:
On Thu, Sep 7, 2017 at 1:20 PM, Jakob Bohm via dev-security-policy <
[email protected]> wrote:
All but one of your suggestions would require the revocation of existing
SubCA certificates, essentially invalidating all existing uses of
certificates issued by those SubCAs (Each certificate holder would need
to obtain and install at least a new SubCA cert, possibly a complete new
end cert).
This is not at all an accurate representation of what it would require, but
I'm not sure it's worth pointing out the code to you, since I think the
broader conversation is whether or not that's a bad thing. While you're
presupposing it's objectively bad, you haven't demonstrated that it's an
unreasonable requirement.
What "code" are you talking about? Surely not computer code, because
then there must be something buried in your posts that I haven't
spotted.
Then there is your suggestion of requiring technically constrained
SubCAs (that were constrained under a previous set of relevant name
types) could survive by subjecting themselves to the massive overhead of
satisfying the requirements for an unconstrained SubCA (audits, dual
user authentication, specially secured server facilities, geographic
redundancy, etc.), where as a constrained SubCA they could operate under
normal enterprise internal security rules.
Yup.
What do you mean "Yup"?
Could you suggest an alternative solution that does not impose such
significant costs?
Why? You're moving a goalpost as it suits, and that's not a productive line
of discussion. To the point that there are multiple ways to address this
problem is established. That there are paths forward that avoid radically
breaking backwards compatibility is also established.
The goalposts have not moved at all.
When you failed to understand the goals outlined in the first two and
last paragraphs of my initial short post, I listed the two purposes
explicitly in my post dated 2017-09-01 06:07 UTC (As "primary problem"
and "secondary problem").
For clarity, I consider redistributing a modified SubCA certificate to
existing certificate holders in order to meet new compliance rules as an
additional compliance requirement.
What you haven't stated, but which is clear from your replies, is you view
these costs to exceed the cost of breaking backwards compatibility. That's
certainly a viewpoint you can take, and I respect your view, but you
haven't advanced any arguments to support that, and merely stated it as
factual.
I hope we can agree there are multiple ways to address the introduction of
new nametypes. These different approaches have different tradeoffs for them
- revocation, auditing, new functionality, breaking old functionality - and
I've presented this multitude in the hopes of demonstrating to you that
jumping to a solution which notably runs counter to Mozilla's Principles
isn't necessary - there are alternatives.
You have failed to list any (non-accidental) old functionality broken by
my original suggestion (with appropriate bug fixes such as the one for
the Subject distinguished name).
So far I have seen you suggest the following approaches:
- Revoke existing, previously accepted, SubCA certificates.
- Replace and reissue existing SubCA certificates with new ones with a
changed value of the name constraints extension, revoking the previous
SubCA certificate.
- Introduce a new extension that would have to be added to previously
issued SubCA certificates, requiring replace, reissue and revoke, but
only once rather than each time the requirements change within the
SubCA lifetime.
- Convert existing, previously accepted, SubCA operations to much
higher standards not applicable to their intended use, only to their
(unintentional) acceptance as valid for a different name type.
My suggestion was a 5th way:
- Applications that add new names types (or resurrect old forgotten
ones) should consider name constrained SubCAs that don't mention the
new name type as not trusted for the new name type. Ditto for
root programs that adjust their TCSC definitions to encompass new
name types.
There is also a 6th way, which I considered too dangerous:
- Root programs could grandfather as TCSC existing SubCAs (issued
before a cutoff date) that met an older definition of TCSC, without
actually making the associated certificate validation code check
for the resulting loophole.
You may still wish to view a solution that breaks backwards compatibility
favorably, and it's unlikely I can convince you otherwise. But I can
highlight for those on the list that alternatives do exist, and your
solution has notable costs - costs that, in many cases, are deemed
unacceptably high.
I explicitly stated in my first post that the changed design would need
to be checked against the corpus of known public CAs to make sure
nothing actually in use is broken. Perhaps the design should also be
checked against previously popular "user guides" and scripts for setting
up private/enterprise CAs not chaining to public CAs.
Such checking against real world usage rather than theoretical counter-
examples is a normal part of designing backwards compatible changes.
You seem to be ignoring my actual arguments and arguing only against
specific words and phrases.
Hopefully, you can see from above that I haven't done so at all, but in
fact been explaining to you why your proposal is unacceptably costly. It
may be simply you disagree.
And you have yet to list a cost that isn't "it breaks compatibility with
the wording of an old document" and hypotheticals. (Not counting the
Subject distinguished name bug in my initial post).
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
