Page MenuHome GnuPG
Create Task
Maniphest T2300

Second crlDP is not used if first is unavailable
Closed, ResolvedPublic
Actions

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

Related Objects

Event Timeline

• aheinecke added a subscriber: • aheinecke.Mar 31 2016, 11:20 AM

799_aheinecke-chain.pem7 KBDownload

• 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 added a comment.May 6 2016, 6:59 PM

D364: 829_0001-Dirmngr-Treat-multiple-crlDPs-as-redundancies.patch

• 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.

• aheinecke added a comment.Sep 12 2019, 2:20 PM
In T2300#90092, @aheinecke wrote:

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.

• aheinecke reassigned this task from • aheinecke to • werner.Sep 19 2022, 4:35 PM

I think 289fbc550d18a7f9b26c794a2409ba820811f6b3 implemented this wish from 2016 :) @werner please read the full report and then close it as fixed if you agree. I find it a bit funny that we both came independently to the same conclusion, that it should be handled differently even if the standard says otherwise. Because the behavior from the standard does not make sense and is in contradiction to other parts where it says that each CRL must contain all revocations.

• aheinecke added a comment.Sep 19 2022, 4:43 PM

For what it is worth, I think that my patch is more standard compliant then yours because it checks if there is a partial CRL.

• werner added a comment.Sep 19 2022, 8:22 PM

What is a partial CRL; I have never seen that and IIRC the specification for that was not complete.

• werner closed this task as Resolved.Sep 19 2022, 8:25 PM