Second crlDP is not used if first is unavailable
Open, WishlistPublic

Description

I've tested with 2.0.22 and a recent master build and both fail with "No CRL Known"

My certificate (attached) has an ldap crlDP which is currently unavailable. The
http alternative is available.

To reproduce the problem:
export GNUPGHOME=$(mktemp -d)
gpgsm --import aheinecke-chain.pem
gpgsm -e -r aheinecke@intevation.de

First run (including marking the root as trusted):

gpgsm: NOTE: THIS IS A DEVELOPMENT VERSION!
gpgsm: It is only intended for test purposes and should NOT be
gpgsm: used in a production environment or with production keys!
gpgsm: certificate #0B/CN=Email CA 2013,O=Intevation GmbH,C=DE
gpgsm: the status of the certificate is unknown
gpgsm: certificate #04/CN=Root CA 2010,O=Intevation GmbH,C=DE
gpgsm: the status of the certificate is unknown
gpgsm: root certificate is not marked trusted
gpgsm: fingerprint=11:B9:1B:31:EE:09:E0:84:4D:25:4E:58:7A:65:CE:51:84:F3:6B:70
gpgsm: root certificate has now been marked as trusted
gpgsm: certificate #00/CN=Root CA 2010,O=Intevation GmbH,C=DE
gpgsm: checking the CRL failed: Configuration error
gpgsm: can't encrypt to 'aheinecke@intevation.de': Configuration error

Second run:
gpgsm -e -r aheinecke@intevation.de
gpgsm: NOTE: THIS IS A DEVELOPMENT VERSION!
gpgsm: It is only intended for test purposes and should NOT be
gpgsm: used in a production environment or with production keys!
gpgsm: certificate #0B/CN=Email CA 2013,O=Intevation GmbH,C=DE
gpgsm: the status of the certificate is unknown
gpgsm: certificate #04/CN=Root CA 2010,O=Intevation GmbH,C=DE
gpgsm: the status of the certificate is unknown
gpgsm: can't encrypt to 'aheinecke@intevation.de': No CRL known

Details

Version
master

aheinecke set Version to master.Mar 31 2016, 11:20 AM
aheinecke added projects: dirmngr, Bug Report.
aheinecke assigned this task to werner.May 6 2016, 6:59 PM
aheinecke added a subscriber: werner.

Ah, the world of S/MIME related RFCs,.. Fun.

From RFC 5280 4.2.1.13. CRL Distribution Points:
If the DistributionPointName contains multiple values, each name
describes a different mechanism to obtain the same CRL. For example,
the same CRL could be available for retrieval through both LDAP and
HTTP.

So the short Answer is. Intevation's certificate is bad. If we want to mark that
our Certificate Revocation lists are Redundant then we should have used a list
in the crlDP and not multiple crlDPs. This GnuPG would handle correctly.

Before I noticed beforementioned bit I've tried to fix it in GnuPG. And I think
it might be an improval as the same section also says:

If the DistributionPoint omits the reasons field, the CRL MUST
include revocation information for all reasons. This profile
RECOMMENDS against segmenting CRLs by reason code. When a conforming
CA includes a cRLDistributionPoints extension in a certificate, it
MUST include at least one DistributionPoint that points to a CRL that
covers the certificate for all reasons.

So If we have one such list we don't have to fetch all crlDP's and error out if
one can't be obtained.

I've attached a patch for that but I can fully understand If you don't think
this should be applied as the current behavior is mature and conforms to the RFC
already. In that case you can resolve this as "nobug".

aheinecke removed werner as the assignee of this task.May 6 2016, 7:16 PM

Ah nevermind. I think myself that this is nobug and current behavior is correct.
There is a mechanism for the redundant setup that we want to have already and we
need to use it instead of doing something undefined.

aheinecke closed this task as Resolved.May 6 2016, 7:16 PM
aheinecke claimed this task.
aheinecke added a project: Not A Bug.
aheinecke reopened this task as Open.Sep 12 2019, 2:12 PM
aheinecke lowered the priority of this task from Normal to Wishlist.
aheinecke edited projects, added Feature Request, g10code; removed Not A Bug, Bug Report.

To implement / test the "not literally RFC compliant but in practice better" behavior let us call this now a wish and feature request as there are certificates in the wild other then intevation's and customers in large institutions run into that.

Ah nevermind. I think myself that this is nobug and current behavior is correct.

To summarize my thoughts on this: The RFC has a Mechanism for both AND and OR with regards to CRL's. But even OpenSSL does not support creating certificates with the OR mechanism. At least according to the CA Guy from Intevation back in 2016.

My argument was that the AND mechanism was senseless because it also said that each CRL should be complete. But as there was an OR Mechanism defined in the RFC (and already implemented in dirmngr) I thought that it would also be bad to redefine the AND mechanism as an additional OR Mechanism.