dirmngr does not attempt PEM encoded CRLs
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	paulm
	Jun 6 2008, 12:07 PM

Description

I have a CA certificate with a CRL DP. This CRL DP contains an HTTP URI that
points to a PEM-encoded CRL. The problem is reproduceable when I attempt to
use this certificate (e.g., to sign a document).

When attempting to use my CA-issued certificate, gpgsm calls dirmngr to verify
the validity of the certificate. This, in turn, triggers dirmngr to download
the (PEM-encoded) CRL, which it then cannot parse.

I have downloaded and verified the CRL using openssl, so I don't believe this
is a CA problem.

This may be a problem with libksba: the error message suggests that
ksba_crl_parse() is unable to process the CRL. (I've added this as a dirmngr
bug as I don't know the libksba API well enough to say who's at fault here)

I've copied the dialogue from dirmngr below:

dirmngr[1822]: trusted certificate
`/home/paul/.gnupg/trusted-certs/CERN-Root.crt' loaded
dirmngr[1822]: SHA1 fingerprint =
DA:D8:7F:63:95:90:A1:E4:D4:1D:B9:48:3D:F4:C3:5C:FC:6B:BF:A3
dirmngr[1822]: name = #7DC0D599138C0D824B2E68E21B947122/CN=CERN Root
CA,DC=cern,DC=ch
dirmngr[1822]: trusted certificate
`/home/paul/.gnupg/trusted-certs/eScience-Root.crt' loaded
dirmngr[1822]: SHA1 fingerprint =
A1:39:B0:F3:04:6C:0B:F9:F5:0A:1B:33:00:06:4F:83:6B:7D:4F:3E
dirmngr[1822]: name = #00/CN=UK e-Science
Root,OU=Authority,O=eScienceRoot,C=UK
dirmngr[1822]: trusted certificate
`/home/paul/.gnupg/trusted-certs/GridKa.crt' loaded
dirmngr[1822]: SHA1 fingerprint =
E4:87:18:8B:14:1C:1E:7A:87:AB:40:2E:A1:05:7C:20:D3:AD:73:1F
dirmngr[1822]: name = #13C6/CN=GridKa-CA,O=GermanGrid,C=DE
dirmngr[1822]: permanently loaded certificates: 3
dirmngr[1822]: runtime cached certificates: 0
dirmngr[1822.0] DBG: -> # Home: ~/.gnupg
dirmngr[1822.0] DBG: -> # Config: /home/paul/.gnupg/dirmngr.conf
dirmngr[1822.0] DBG: -> OK Dirmngr 1.0.1 at your service
dirmngr[1822.0] DBG: <- OPTION audit-events=1
dirmngr[1822.0] DBG: -> ERR 167772334 Unknown option <Dirmngr>
gpgsm: DBG: connection to dirmngr established
dirmngr[1822.0] DBG: <- ISVALID EB65014BDE67BCFC860D49F05A46BAA0716715C5.13C6
dirmngr[1822]: no CRL available for issuer id
EB65014BDE67BCFC860D49F05A46BAA0716715C5
dirmngr[1822.0] DBG: -> INQUIRE SENDCERT
dirmngr[1822.0] DBG: <- [ 44 20 30 82 05 2d 30 82 04 15 a0 03 ...(986 bytes
skipped) ]
dirmngr[1822.0] DBG: <- [ 44 20 16 24 68 74 74 70 3a 2f 2f 67 ...(365 bytes
skipped) ]
dirmngr[1822.0] DBG: <- END
dirmngr[1822]: ksba_crl_parse failed: Invalid CRL object
dirmngr[1822]: crl_parse_insert failed: Invalid CRL object
dirmngr[1822]: crl_cache_insert via DP failed: Invalid CRL object

Cheers,

Paul.

Details

Version: 1.0.1-3

Event Timeline

paulm added projects: dirmngr, Bug Report.Jun 6 2008, 12:07 PM

paulm set Version to 1.0.1-3.

paulm added a subscriber: paulm.

Libksba does only take binary data; thus it is indeed a dirmngr problem.

I have not yet seen a PEM encoded CRL and frankly I think it is a pretty bad
idea to encode them this way. CRLs may get very long and require a lot of
bandwidth, PEM encoding blows them up by 33%.

Can you send me the URL from the DP for testing?

Hi Werner,

Thanks for the speedy reply.

On Friday 06 June 2008 13:00:38 Werner Koch via BTS wrote:

I have not yet seen a PEM encoded CRL and frankly I think it is a pretty
bad idea to encode them this way. CRLs may get very long and require a lot
of bandwidth, PEM encoding blows them up by 33%.

Oh, OK. I'll pass the comment on to the CA.