On 12/19/2014 5:47 AM, Daniel Kahn Gillmor wrote:
On 12/18/2014 04:42 AM, Kurt Roeckx wrote:
On Wed, Dec 17, 2014 at 08:34:52PM +0100, Erwann Abalea wrote:
Le 17/12/2014 20:17, Viktor Dukhovni a écrit :
On Wed, Dec 17, 2014 at 10:56:34AM -0800, Sean Leonard wrote:
For reference for the group (in case you didn't take a look at the draft),
the draft documents the following labels:
CERTIFICATE
...
Perhaps also "TRUSTED CERTIFICATE"?
crypto/pem/pem.h:#define PEM_STRING_X509_TRUSTED "TRUSTED
CERTIFICATE"
It's specific to OpenSSL.
And it would be useful if it wasn't.
It might be useful, but getting the semantics right of what "TRUSTED
CERTIFICATE" actually means is a non-trivial task. I'm not convinced
that OpenSSL's interpretation of it is particularly useful in many
common contexts.
Does OpenSSL have documented someplace exactly what it means to have a
"TRUSTED CERTIFICATE"?
For example, say we're talking about a certificate that i am willing to
accept for the peer foo.example. If i mark it TRUSTED and it has
another SubjectAltName of bar.example, will OpenSSL subsequently accept
it for bar.example as well?
I actually wrote something up in an e-mail to the IESG a few days
ago.........
The headers that OpenSSL recognizes in various portions include those
found in:
/crypto/pem/pem.h
[SNIP]
There is also a "TRUSTED CERTIFICATE" label that OpenSSL uses...I
believe this is a vendor-specific extension but now that I am spelunking
through the source code I see that it could be abused. Relevant source
code/comments say:
https://www.openssl.org/docs/apps/x509.html
A*trusted certificate*is an ordinary certificate which has several
additional pieces of information attached to it such as the permitted
and prohibited uses of the certificate and an "alias".
Normally when a certificate is being verified at least one certificate
must be "trusted". By default a trusted certificate must be stored
locally and must be a root CA: any certificate chain ending in this CA
is then usable for any purpose.
Trust settings currently are only used with a root CA. They allow a
finer control over the purposes the root CA can be used for. For example
a CA may be trusted for SSL client but not SSL server use.
See the description of the*verify*utility for more information on the
meaning of trust settings.
Future versions of OpenSSL will recognize trust settings on any
certificate: not just root CAs.
*) Extensive changes to support certificate auxiliary information.
This involves the use of X509_CERT_AUX structure and X509_AUX
functions. An X509_AUX function such as PEM_read_X509_AUX()
can still read in a certificate file in the usual way but it
will also read in any additional "auxiliary information". By
doing things this way a fair degree of compatibility can be
retained: existing certificates can have this information added
using the new 'x509' options.
Current auxiliary information includes an "alias" and some trust
settings. The trust settings will ultimately be used in enhanced
certificate chain verification routines: currently a certificate
can only be trusted if it is self signed and then it is trusted
for all purposes.
[Steve Henson]
/* X509_CERT_AUX routines. These are used to encode additional
* user modifiable data about a certificate. This data is
* appended to the X509 encoding when the *_X509_AUX routines
* are used. This means that the "traditional" X509 routines
* will simply ignore the extra data.
*/
ASN1_SEQUENCE(X509_CERT_AUX) = {
ASN1_SEQUENCE_OF_OPT(X509_CERT_AUX, trust, ASN1_OBJECT),
ASN1_IMP_SEQUENCE_OF_OPT(X509_CERT_AUX, reject, ASN1_OBJECT, 0),
ASN1_OPT(X509_CERT_AUX, alias, ASN1_UTF8STRING),
ASN1_OPT(X509_CERT_AUX, keyid, ASN1_OCTET_STRING),
ASN1_IMP_SEQUENCE_OF_OPT(X509_CERT_AUX, other, X509_ALGOR, 1)
} ASN1_SEQUENCE_END(X509_CERT_AUX)
_______________________________________________
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
