You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I have a CA certificate with non-empty permitted_subtrees, webpki always performs a check of DirectoryName, even if the permitted_subtrees doesn't contain any DirectoryName. Due to that, you are basically required to put a DirectoryName constraint if you want it to be non-empty. In other words, webpki (wrongly) rejects this chain (order is entity cert followed by CA cert):
As the DirectoryName comparison is implemented as an equality check in webpki, you are required to constrain the DirectoryName to precisely that value for all sub-CAs. With this in mind, I was able to come up with a working certificate chain, but I think it's too restrictive.
Note that openssl also assumes a different format for the restrictions, i.e. one nesting layer of SEQUENCE more shallow. I think that this is a violation of the format specified in RFC 5280 and, will file a bug in the openssl tracker after more research. Edit: this is another bug in webpki which assumes explicit tagging, but the spec wants implicit tagging: #135
Back to this bug. The RFC is admittedly a bit vague on the question. Quoting RFC 5280:
Restrictions apply to the subject distinguished name and apply to
subject alternative names. Restrictions apply only when the
specified name form is present. If no name of the type is in the
certificate, the certificate is acceptable.
Note the second sentence. It doesn't specify which name form, the one in the CA's restriction list or the name form of the entity cert. Reading the third sentence makes you believe they only mean the name form in the entity cert. If you interpret the second sentence to apply to the CA's list as well as the certificate's list, you can conclude that if the CA's list doesn't contain any DirectoryName restriction, then no restrictions apply to the entity cert regarding its DirectoryName.
I think the core of this bug is the check_presented_id_conforms_to_constraints_in_subtree function in src/name.rs.
I suggest only setting has_permitted_subtrees_mismatch to true if there has been a match in the type, but a mismatch in the content. So making the default arm in match (name, base) { still evaluate to something indicating a mismatch, but one that doesn't set has_permitted_subtrees_mismatch later.
There were two bugs. webpki didn't:
1. read the X.509 Name Constraints field in its entirety, nor
2. check the certificate subject against the constraints correctly
(1) is a simple fix, (2) requires reading the Common Name from the
certificate.
Closesbriansmith#20, briansmith#134.
If I have a CA certificate with non-empty
permitted_subtrees
, webpki always performs a check ofDirectoryName
, even if thepermitted_subtrees
doesn't contain anyDirectoryName
. Due to that, you are basically required to put aDirectoryName
constraint if you want it to be non-empty. In other words, webpki (wrongly) rejects this chain (order is entity cert followed by CA cert):As the
DirectoryName
comparison is implemented as an equality check in webpki, you are required to constrain theDirectoryName
to precisely that value for all sub-CAs. With this in mind, I was able to come up with a working certificate chain, but I think it's too restrictive.Note that openssl isn't as restrictive and doesn't require a DirectoryName to be present. For example, it is just fine with this chain:
Note that openssl also assumes a different format for the restrictions, i.e. one nesting layer of
SEQUENCE
more shallow.I think that this is a violation of the format specified in RFC 5280 and, will file a bug in the openssl tracker after more research.Edit: this is another bug in webpki which assumes explicit tagging, but the spec wants implicit tagging: #135Back to this bug. The RFC is admittedly a bit vague on the question. Quoting RFC 5280:
Note the second sentence. It doesn't specify which name form, the one in the CA's restriction list or the name form of the entity cert. Reading the third sentence makes you believe they only mean the name form in the entity cert. If you interpret the second sentence to apply to the CA's list as well as the certificate's list, you can conclude that if the CA's list doesn't contain any
DirectoryName
restriction, then no restrictions apply to the entity cert regarding itsDirectoryName
.I think the core of this bug is the
check_presented_id_conforms_to_constraints_in_subtree
function insrc/name.rs
.I suggest only setting
has_permitted_subtrees_mismatch
to true if there has been a match in the type, but a mismatch in the content. So making the default arm inmatch (name, base) {
still evaluate to something indicating a mismatch, but one that doesn't sethas_permitted_subtrees_mismatch
later.Related, but more general than this bug: #20
The text was updated successfully, but these errors were encountered: