On 31/08/2017 22:26, Ryan Sleevi wrote:
On Thu, Aug 31, 2017 at 4:13 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I am aware that this was the original specification. However like many
other parts of PKIX it may not be as good in 20/20 hindsight.
Agreed. But in general, in order to maintain interoperability, there's a
process for building consensus, and repurposing extensions as you propose
is generally detrimental to that :)
But sometimes necessary.
Moving the information to a new extension would basically just bloat
certificates with more redundant data to be sent in every certificate
based protocol exchange. But changing the original decision in a
backwards compatible manner may still be a good idea, either as a
"stricter security policy" or (better, if it works well in controlled
tests) as part of an update RFC for the IETF standard that specified the
original semantics.
I can understand your perspective, but I must disagree with you that it's
"backwards compatible". It isn't - it's a meaningful semantic change that
breaks interoperability.
I meant backwards compatible and interoperable with the actual real
world CAs (as opposed to all the CAs that could be built under the old
standard). Compare to how the standard was changed from DNS name in the
CN element to DNS name exclusively in the SAN extension, but hopefully
with less transition time needed.
At the least, that's something that bears documentation and consensus -
that is, don't "embrace, extend, extinguish" - if you will.
Of cause.
Yes, it means that technically constrained sub-CA certificates may be
'bloated' in order to ensure the desired degree of security. That's a
trade-off for the compromises necessary to avoid audits. That's not,
however, an intrinsic argument against the process, or a suggestion it
cannot be deployed.
Avoiding audit failures is a legal, not a technical need. Anything that
would only fail audits could be fixed by changing audit requirements, if
the organizations setting those (such a Mozilla and CAB/F) desires.
The interaction between a nameConstraints extension not specifying
directorynames and the directoryname in the Subject field would be an area
needing careful specification, based on compatibility and historic concerns.
Yes. Which would not be appropriate for m.d.s.p (for reasons of both
consensus and intellectual property). That is a concern for some members,
and is why organizations like W3C and groups such as WICG exist :)
Ok, I was simply hoping informal discussion in a place like m.d.s.p.
would be a better place to initial evaluate such an idea before starting
up the whole standardization process.
A first order approximation would be that the absence of directory name
constraints in a non-empty nameconstraints extension would not prohibit the
(mandatory) inclusion of a directory name as the Subject Name of a
certificate (but would still block its inclusion as a SAN).
It does, as proposed, so your proposal is not 'backwards compatible'
anymore :)
Well since its only a property of an interpretation of my own first
draft wording, this is simply a fix of the proposal long before
implementation.
A second order approximation could apply certain non-directory-name
constraint semantics to certain directory name elements. For example
an "emailAddress" directory name field could be subject to the
constraints for rfc822name absent explicitly contradictory directory
name constraints. An official specification would have to enumerate
these situations explicitly.
Indeed.
However in practice, such a replacement of (relying part redistributed)
SubCA certificates would be at least as difficult as simply switching to
a new SubCA. Either solution would be unlikely to make subscribers stop
distributing the old SubCA cert with their existing non-expired end
cert, but changing to a new SubCA would at least prevent accidental
reuse of the expired/revoked SubCA cert with new end certs.
They are not relying party distributed. They're subscriber distributed. And
as the Subscriber has a direct or transitive relationship with the Issuer,
that's not unreasonable.
Sorry, typo.
I agree that it's an error prone process, and I agree that changing the
name (and not just the key) is an ideal scenario to transition. However,
unless you revoke the old certificate, it's unconstrained. And if you
revoke the old certificate, then everything it's issued is no longer valid,
unless you reissue for the same name and key with new constraints. Which is
why folks thought it was a good idea at the time.
Alternatively, one could choose a definition of "unconstrained" which
doesn't require impracticable revocations of real world certificates
that were considered fully constrained under previous definitions.
This is the motivation for my proposal that browsers etc. wanting to
require additional "all ban" naming constraints might instead interpret
the absence of information as an indication that the SubCA certificate
is to be interpreted as if the newly considered name type was
nonexistent (and thus not permitted).
I'm not trying to defend the ideas as good - the idea of making
nameConstraints a whitelist, rather than a blacklist, has been something
bandied about for the better part of a decade. However, it's a mistake we
have to live with, and if we want to correct it, it means specifying
something new, and in a way that is interoperable, both with the old and
others. I tried to give you a suggestion on how to do so, should you feel
motivated to pursue it.
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
