Le 21/12/2014 21:39, Sean Leonard a écrit :
On 12/21/2014 8:33 AM, Kurt Roeckx wrote:
On Sat, Dec 20, 2014 at 02:29:44PM +0000, Dr. Stephen Henson wrote:
On Fri, Dec 19, 2014, Sean Leonard wrote:
On Dec 19, 2014, at 11:35 AM, Kurt Roeckx <k...@roeckx.be> wrote:
On Fri, Dec 19, 2014 at 03:05:32PM +0000, Viktor Dukhovni wrote:
On Fri, Dec 19, 2014 at 08:47:55AM -0500, Daniel Kahn Gillmor wrote:
Does OpenSSL have documented someplace exactly what it means to
have a
"TRUSTED CERTIFICATE"?
It is a certificate + auxiliary data which specifies a friendly name
plus a set of EKUs.
Mozilla provides a list of root certificates and that includes at
least the trust settings for that certificate.
What exactly is the Mozilla (NSS) format? How does it differ from
the OpenSSL format?
The last time I checked NSS stored the trust data in a database
(Berkeley DB)
and the trust attributes could be accessed via PKCS#11. I'm not
aware of any
way to export the certificates to a file which retains the trust
settings.
I'm not aware of any standard for trust settings. There certainly
wasn't
one when this was added to OpenSSL.
The source is actually a text file you can see here:
https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/builtins/certdata.txt
As far as I know they turn the file into a database, not the other
way around.
Ok.
Overall I am not convinced that trust settings are the proper subject
of interchange between different products. There is a standard
validation algorithm (RFC 5280, etc.); however, the algorithm is
super-complicated and very few people implement all of its
permutations, especially things related to the esoteric name types and
name constraints (who implements directory name constraints, for
example??).
OpenSSL implements it, so does Microsoft. I don't know if NSS::libpkix
implements it, I'm sure NSS:pkix (its recent successor) doesn't. Apple
doesn't know about NameConstraints. I don't know about GnuTLS, but I
doubt it does.
There is also ambiguity/non-standardization around how EKU trust
settings are propagated/enforced.
This is a step first taken by Microsoft for public CAs, recently adopted
by Mozilla. It's completely non standard.
The function offered by this "EKU constraints" logic is normally offered
by the CertificatePolicies extension, but:
- it was only used to distinguish EV TLS certs from the rest
- it's very hard to make it work in practice when considering a lot of
public CAs and different usages
[...]
Another way to do it would be for a product to have one
product-specific root "certificate", which then has subordinate
"certificates" that have all of the RFC 5280-compliant constraints
applied to them and that are used as cross-certificates for the actual
root CA certificates. Thus if you wanted to restrict Acme Corp's certs
to *.acme.com and the Government of the People's Republic of China's
certificates to *.cn (DNS) and *@*.cn (e-mail), you would create a
master root OpenSSL product "certificate", and issue subordinate CA
certs to the "real" roots.
Something like this?
NameConstraints {
permittedSubTrees {
{ base.dNSName: "cn" },
{ base.emailAddress: "cn" },
{ base.emailAddress: ".cn" }
}
}
It doesn't restrict IP addresses, it also doesn't address restrictions
on the type of certificate use (CP/EKU/...).
_______________________________________________
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
