On Fri, May 12, 2017 at 07:50:46PM +0200, Jakob Bohm via dev-security-policy
wrote:
> On 12/05/2017 10:06, Kurt Roeckx wrote:
> > From past discussion on the OpenSSL list, I understand that we want to
> > support a trust store that supports all such kind of attributes. Some
> > things like for what it's trusted are currently supported by using an
> > X509_AUX structure instead of an X509 structure but then OpenSSL is the
> > only thing that can read it, so this isn't really used.
> >
> > What we need is a format that can be used by all libraries. It probably
> > needs to be extensible. It should probably support both all certificates
> > in 1 file and all in separate files.
> >
>
> Could something be derived from / based on the ASN.1 format apparently
> used by Microsoft in it's root store, with OpenSSL/Mozilla OIDs added
> for things that have no Microsoft notation yet.
>
> Another starting point (if not the same) could be the "trusted
> certificate" format that some openssl commands can generate.
That would be the X509_AUX. It's a combination of a normal X509
followed by an X509_CERT_AUX that looks like:
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)
As far as I know, openssl supports reading such files as either
just a plain X509 ignoring everything after it or as an X509_AUX.
Other libraries don't.
> Ideally in the future, code support for a new restriction type can be
> implemented (in both NSS and other libraries) before the community
> decision to enforce that restriction against a given CA comes into
> effect. For example, some time has already passed since Google
> proposed their set of Symantec restrictions, but the trigger has not
> been pulled yet on any of those.
>
> Just for clarity, could you confirm that the current (1.0.2 / 1.1.0)
> OpenSSL verifiers do not check if issuing CA has a conflicting EKU list?
It only checks it when you tell it to check for a purpose, in
which case it checks that all certificates can be used for that
purpose. But I guess most applications don't use that.
Kurt
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
