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??). There is also
ambiguity/non-standardization around how EKU trust settings are
propagated/enforced.
If you wanted to record this information, I believe that PKCS #12 is the
right format for the job. PKCS #12 is convoluted and a lot of people
hate it for good reasons, but PKCS #12 allows you to transmit arbitrary
attributes alongside certificates, private keys, and other crypto
objects. Thus if you want to annotate a certificate with a friendly name
(alias) or a special key identifier, there are interoperable ways to do
that. The complicated part then becomes what trust settings are
interoperable, not the particular packaging format involved.
draft-josefsson-pkix-textual prohibits header annotations inside the
textual format, because they are not interoperable. (This is a departure
from PEM [RFC1421], which is based on e-mail messages, which allows for
headers prior to the base64-encoded body.) Other non-pkix-textual
formats, such as the OpenSSH Public Key File Format [RFC4716], make
extensive use of headers.
On that point, that was another reason why I did not include RSA PRIVATE
KEY. For the command:
openssl genrsa -aes256 2048
You get:
Generating RSA private key, 2048 bit long modulus
...........+++
..................................................+++
e is 65537 (0x10001)
Enter pass phrase:
Verifying - Enter pass phrase:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,5CD4A83156BC97F69CD537D5A2AC1B53
k1QsZFahAmPsiiZUNy4q4njus3QYEtwBmCuGb1Q1d6mpqtLiokv+hdDwk9i/POtV
...
-----END RSA PRIVATE KEY-----
...this is (basically) RFC 1421 PEM format, which is not the same as
pkix-textual.
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.
I put "certificate" in quotes above because the implementation should
not expose the root product "certificate" or the subordinate
"certificates" on the wire (as might be done with TLS or CMS/S/MIME).
They are not supposed to be real "certificates" but rather just a way to
reuse most of the validation code.
Sean
_______________________________________________
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
