On 31/08/2017 21:49, Ryan Sleevi wrote:
On Thu, Aug 31, 2017 at 8:18 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Would it be beneficial to Mozilla in particular and the larger PKI
community in general if the following was added to implementations:
Hi Jakob,
This was rather extensively discussed in the IETF during the production of
the nameConstraints extension - whether to fail open or fail closed, if you
will, with unrecognzied name types.
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.
The existing RFCs document the behaviour that is implemented by clients, so
no, it would not be wise to repurpose this behaviour in a contradictory way
- that would go against the mission of ensuring an interoperable Web based
on shared standards.
The approach to change the semantic meaning of extensions in such a way is
to define a new such extension - which may have the same encoding, but have
the semantic processing restrictions you mentioned. One way that could be
done in an interoperable way is to ensure both the 'legacy' nameConstraints
extension (to handle the existing Web PKI) and the 'new'
nameConstraintsVersion2 extension (poorly named, but with the same ASN.1
production and different semantic meaning for processing) be required for a
certificate to be considered 'constrained'.
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.
Such a document would ideally go through the IETF, but COULD be incubated
in an appropriate venue (such as WICG) to allow iterative and flexible
development.
That would indeed be the point.
However, the implementation isn't quite as 'simple' as you describe, and so
would require more work. For example, one flaw would be that unless such a
constrained certificate specified a Directory Name constraint, then every
certificate issued would be a violation of the name constraint unless it
was a fully empty subject ( see https://no-subject.badssl.com/ to
understand the compatibility issues this causes; particularly, try it on
macOS). So more work is needed.
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.
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).
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.
But that general concern - of being able to extend new name types and not
necessarily have the CA be able to issue for them - has been discussed in
the past. The original idea was that as new name types are introduced that
have semantic meaning for applications, you would revoke the existing cert
and reissue a new one (with new constraints) using the same Subject/Key, as
that would ensure a continuity of validity for situations where you did
want to restrict the naming scheme. So, technically, there are options for
CAs today :)
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.
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
