solution for systemwide CA trust config

Stef Walter stefw at
Thu Jan 3 06:39:26 PST 2013

On 01/02/2013 06:51 PM, Miloslav Trmac wrote:
> Hello,
> Attached is a patch fixing some typos.  You did ask for nitpicking :)

Indeed. Thanks for catching those :)

Applied the patch.

> Two additional comments:
> * > wish to
>   > override or adjust the trust policy that for a given certificate authority
>   > especially when used as an anchor
>   "policy that" seems to be missing something, and I'm not sure what.
>   Or s/that for/for/?

Yup. Fixed.

> * Re: outstanding issues/using ExtendedKeyUsage with no usages:
>   Assuming the RFC 5280 semantics is interpreted correctly everywhere, using
>   this without an explicit "blacklist" bit would technically work.  Still...
>   1) RFC 5280 says
>   > In general, this
>   > extension will appear only in end entity certificates.
>   which is a little risky if we want to use it primarily for CAs.

In addition, it turns out that the ExtKeyUsageSyntax ASN.1 structure
requires at least one OID purpose. Although obviously that one purpose
need not be a known usable purpose, this makes it even more questionable
for blacklisting purposes.

So I agree. The more I work with this it seems that the concept of a
blacklist should be a first order concept over and above the concept of
applying additional policy to anchors (via stapled certificate
extensions), even though the latter can also be used to prevent
successful use of a certificate as an anchor.

>   2) From an UI perspective, there is a conceptual difference between
>   an untrustworthy/blacklisted certificate and a certificate with restricted
>   usage, and displaying the former as the latter might motivate users
>   to "fix" problems by enabling the prohibited usages.  Of course, this is
>   ultimately an UI problem, not a technology design problem.

Yes, that's true. When possible we should model sane concepts all the
way through the stack, rather than having the UI be a leaky abstraction.
So again, this is a point in favor of an explicit blacklist.

>   So... I don't know.  Intuitively I'd prefer a separate blacklist bit.

Me too.

Thanks again.


More information about the p11-glue mailing list