Right, there is a little bug. However, it needs some analysis before we can fix
it. The chain validation code is not easy to change.

As long as you have other means to revoke root certificates, thwre is no problem
with that option.

Thanks for the information.

Perhaps the API between gpgsm and dirmngr should be extended allowing gpgsm to
specify, when querying whether a certificate is valid, if the certificate has
no CRL DP yet is otherwise valid (hasn't expired) whether it should be
considered valid or not. gpgsm could then switch this "invalid" for normal
certificates (replicating current behaviour), but switch it "on" for CA
certificates. Alternatively, dirmngr behaviour could be altered so
certificates with no CRL DP but or otherwise valid are considered valid,
although there's also the issue of fetching the CRL from an LDAP server.

But, these are just suggestions. I appreciate getting the semantics correct
is difficult and I don't know that much about how the chain of trust is
established, particularly within gpgsm.

PS. the subject for the bug is wrong (sorry): the --import works fine, it's
when trying to use the certificate that there is a problem.

A CRL DP is not required, although today most CAs provide one. For that reason,
dirmngr has a list of ldap servers to use as a fallback. For HTTP this is not
possible because there is no standard on the format for CRL http-URLs

Enabling CRL checks it on a per-CA base is not a good idea because that would
also reduce the security of all other CAs. In most applications (including
GnuPG) all CAs are instantly cross-certified. An attack would work like this:
Mallory gets access to the private key of a CA which does not properly provide
CRLs, he can then issue all kinds of certificates (and he will include a DP to
his own CRL server to make the new certificates "more secure").

Having said this, I suggest that you may either require CRL checks for all CAs
or entirely forget about them (like Web browsers do). I know some companies who
enable CRL checks but that is also by far the hugest problem when trying to send
a mail. I guess they often just send the mail in the plain or resort to OpenPGP
where we have a similar problem, but people usually don't care about it.

I'll tag this as nobug for now.

Hi Werner,

As promised, I've brought this issue up with the manager of the CA involved.

His was aware that the Root cert doesn't have a CDP and that this was the
result of a deliberate decision. His arguments (if I remember them correctly)
were:

a. there's no requirement on a CA's Root certificate to have a CDP; in his
view, it's wrong to considering the Root cert. invalid because of this missing
this optional feature.

b. HTTP-based CDPs are necessarily tied to a DNS name and that
(unfortunately) the CA Root certificate has had a greater longevity than the
CA's web presence (largely due to funding and management decisions).

It's perhaps worth emphasising that the issued (end-user) certificates *do*
have CDPs and that the CA maintains CRLs for both the issued certificate and
for the root certificate itself. The Root and Signing certificates don't have
CDPs.

Some more comment below:

On Friday 06 June 2008 16:36:52 Werner Koch via BTS wrote:

Werner Koch <wk@gnupg.org> added the comment:

A CRL DP is not required, although today most CAs provide one.

This is an interesting point: I believe a CA certificate, whilst still valid,
MAY (in RFC-2119 sense) refrain from including a CDP. To conclude that such a
certificate is always invalid (when building the chain of trust) is, in my
view, wrong.

For that reason, dirmngr has a list of ldap servers to use as a fallback.
For HTTP this is not possible because there is no standard on the format for
CRL http-URLs

True: unless the CA Root (and signing) certificates contains a CDP, there's no
automatic way to obtain the CRL.

Enabling CRL checks it on a per-CA base is not a good idea because that
would also reduce the security of all other CAs.

This may be true, but the man page suggests that it is at least possible:

From gpgsm(1)

[...]

       --disable-trusted-cert-crl-check
		By default the CRL for trusted root certificates are checked
		like for any other certificates. [...] The disable option may be
		used to switch this extra check off.  [...]  A more specific way
		of disabling this check is by adding the "relax" keyword to
		the root CA line of the `trustlist.txt'

I couldn't get this to work: adding "relax" keyword did *not* disable CRL
checking for the specific root certificate.

If allowing a user to disable CRL checking for an individual certificate is
just plain wrong then the "relax" behaviour is correct; however, if so, the
man page is misleading and should be altered so it no longer suggests it is
possible to disable CRL checks for individual (trusted) root certificate.

In most applications (including GnuPG) all CAs are instantly cross-certified.

Sorry, I'm not sure I understand this statement. Does this mean that, if a
trusted CA emitted/signed a CRL that includes revocation entries for
certificates issued by a different CA, gpgsm would accept (and honour) those
"foreign" revocations?

An attack would work like this: Mallory gets access to the private key of a
CA which does not properly provide CRLs, he can then issue all kinds of
certificates (and he will include a DP to his own CRL server to make the new
certificates "more secure").

I afraid I don't follow you here. This attack works whether or not the Root CA
has a CDP. The attack works because PKI critically depends on private keys
being kept inaccessible to everyone except authorised people.

From what I can see, a CDP is *only* effective after (and, indeed, "if") the
theft is discovered. Including a CDP in the Root certificate may allow
everyone to recover faster, but the theft of a Root certificate is such a
devastating event that some disruption is inevitable.

If "cross-certified" means what I guessed above, then requiring all root
certificates include a CDP does not prevent these problems, it merely speeds up
how quickly one can recover once the theft has been discovered.

Having said this, I suggest that you may either require CRL checks for all
CAs or entirely forget about them (like Web browsers do).

My take on this is...

I'd like to enable CRL checks. I think this increases the security of my PKI
setup since, should a certificate be revoked, it the certificate should be
(automatically) considered not valid and any signatures it generates will no
longer be considered valid.

I have (a copy of) the Root and signing certificate of a CA that I strongly
trust (I personally know the guy in charge, who is also highly trusted world-
wide). These certificates do not include a CDP, but this omission is
deliberate. I'm happy with this because I'm pretty sure I'll hear promptly if
the corresponding private key is compromised (in effect, this is a kind of out-
of-band CRL :-) Should this happen, I can remove the certificate from the list
of trusted certs. This isn't an automatic process (which would be better),
but it's OK for me.

I'd like gpgsm to support this configuration as I don't see any security show-
stopper problems with the setup. I'm OK if this isn't gpgsm's default
behaviour and it requires some specific configuration (like the "relax"
keyword).

I know some companies who enable CRL checks but that is also by far the
hugest problem when trying to send a mail. I guess they often just send the
mail in the plain or resort to OpenPGP where we have a similar problem, but
people usually don't care about it.

True, although I thought (Open-)pgp/gpg has key-servers that one can upload
CRLs to, no?

I'll tag this as nobug for now.

Would you reconsider this?

I'm certainly not expecting an immediate fix! But it's a problem that might
benefit from further analysis.

Cheers,

Paul.