Bonjour,
Le 13/08/2014 10:57, John Denker a écrit :
1) There are actually some people who are using v3 nameConstraints.
Not a lot, but some.
There will probably be more coming, thanks to Mozilla+CABForum.
An example can be found in one of the fully-trusted root certificates
that is distributed in the current Ubuntu release, and several previous
releases:
/etc/ssl/certs/Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem
which is a symlink to
/usr/share/ca-certificates/mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt
This one is a root, so this extension shouldn't be taken into account.
This clearly written in RFC5280 section 4.2.1.10, and is implied by the
validation algorithm described in section 6. But let's put that aside.
Let's take a look at it:
openssl x509 -text -noout <
Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt
[snip]
X509v3 Name Constraints:
Permitted:
DNS:.gr
DNS:.eu
DNS:.edu
DNS:.org
email:.gr
email:.eu
email:.edu
email:.org
2) Note the leading "." in each item in the permission list.
a) This seems entirely logical and reasonable to me.
b) All the documentation and examples I've seen on the web assume
the "." should be there. It's not even a topic of discussion.
It is. PKITS doesn't test leading "." in dNSName entries.
RFC5280 describes the semantic of rfc822Name entries in NC with and
without leading "." (2 different behaviours). It does the same with URIs
(again, 2 different behaviours).
Equivalent text for dNSName entries is:
-----RFC5280 extract-----
DNS name restrictions are expressed as host.example.com. Any DNS
name that can be constructed by simply adding zero or more labels to
the left-hand side of the name satisfies the name constraint. For
example, www.host.example.com would satisfy the constraint but
host1.example.com would not.
-----
See? No leading "."
3) Desired behavior: openssl should tolerate the leading "."
Question: Does anybody think the leading "." should be mandatory?
Or should we tolerate it either way????
This extension is a security constraint, so the question isn't "should
we tolerate it?", but "what do the sacred scriptures ask compliant
implementation to do?"
4) Observed behavior: As of openssl-1.0.1i the leading "." is
not tolerated. In particular:
openssl verify -verbose -check_ss_sig -CAfile $CA_NAME-cert.pem
$TARGET-cert.pem
server.example.net-cert.pem: C = US, CN = server.example.net
error 47 at 0 depth lookup:permitted subtree violation
In more detail: I added some debugging printf statements:
==== checking DNS 'www.example.net' against '.example.net' ... result:
47
==== checking DNS 'www.example.net' against 'example.net' ... result: 0
The certs I used to test this can be found at
http://www.av8n.com/openssl/namecon-ca-cert.pem
http://www.av8n.com/openssl/server.example.net-cert.pem
I get a 403 trying to retrieve your example certificates.
If your CA has both ".example.net" and "example.net" in the
permittedSubTrees, and the subscriber cert has "www.example.net", then
OpenSSL is wrong rejecting the certificate, because "www.example.net"
matches at least one of them; it doesn't have to match ALL of them, only
to NOT match any of the entries in excludedSubTrees part.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
