Initial try

[Jay Kline]

Hey guys- this software product looks like it could be a huge help for
me. Im trying to get it running, but am having some difficultly
understanding what all I need to do. I installed the debian package
for pathfinderd and pathfinder-utils, set up the config to point at my
directory of root CAs (2 of them). We have 10 or so intermediate
CAs. When I use pathverify to check a certificate issued by one of
the intermediate CA's, it ends with this message:

PathFinder<Info>: Attempting to get signer.
Path Validator<Info>: Encountered error (No urls to download object
needed to perform validation) during path discovery. Aborting.
Error while validating path (No urls to download object needed to
perform validation)

Im not sure exactly what object its trying to get here. I can see it
downloaded the intermediate cert and CRLs, and the root CA crls, so
whats missing?

[William Lachance]

Hi Jay,

It's sounds like you're on the right track, and the only issue is a
small error in your configuration or a bug in pathfinder. :)

Any chance you could post the complete log of path verify with verbosity
set to the max (i.e. -vvvv)? I could speculate, but it's probably easier
just to see what's going on directly.
--
William Lachance <wrl...@gmail.com>

[Jay Kline]

William Lachance wrote:
> Hi Jay,
>
> It's sounds like you're on the right track, and the only issue is a
> small error in your configuration or a bug in pathfinder. :)
>
> Any chance you could post the complete log of path verify with verbosity
> set to the max (i.e. -vvvv)? I could speculate, but it's probably easier
> just to see what's going on directly.
>

Sure thing. Ive attached the output of the command with -vvvvv set, and
snipped out most of the download logging (about 550K worth), and
modified my cert CN in the log (to at least pretend to have some privacy).

Something to keep in mind, I cannot modify any of the infrastructure out
there- so if one of the servers is giving a poor response, I really need
to work around it. But Im guessing you can figure that out from the logs.

Thanks,

Jay

[Patrick Patterson]

Hi Jay:

Could you also send your pathfinder config file?

Also, if you could, could you send the certificate that you are trying to validate?

Thanks.

Patrick.

WvX509Store<*5>: Loading store from directory /etc/krb5/CERTS.
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CA-11.crt into store (ski: 53:22:DF:BC:C6:18:33:83:89:C2:AD:AE:26:4E:44:F7:24:0E:15:BB).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CA-12.crt into store (ski: AA:97:45:80:89:01:D2:BE:2C:98:07:72:1C:58:D3:EB:BF:CB:8E:68).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CA-13.crt into store (ski: 64:64:43:25:A4:6C:E7:0D:22:1D:65:AC:C0:E4:75:37:CC:04:DA:DA).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CA-14.crt into store (ski: E1:55:BD:E7:4B:E7:9C:C8:27:E4:BB:B5:17:B8:66:50:A4:52:F3:39).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CA-15.crt into store (ski: 68:80:11:78:19:0D:EE:ED:F3:65:49:8E:00:22:EC:52:8E:BA:04:CE).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CA-16.crt into store (ski: 50:6B:CE:58:B9:C0:FB:6A:23:0B:0A:C9:8F:41:9E:9C:05:62:E7:69).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CA-17.crt into store (ski: 9D:D5:F7:A5:B6:4C:61:C2:A2:12:6D:7B:F2:74:EA:7C:76:24:25:3B).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CA-18.crt into store (ski: 32:A1:C9:09:AB:5E:7F:17:79:4A:2A:14:EE:FD:62:7C:A1:01:E5:B9).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_CA-10.crt into store (ski: 35:27:1A:30:8C:1E:4D:A6:60:7B:B7:2D:3A:46:2E:4B:A9:2F:2B:30).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_CA-3.crt into store (ski: 07:E1:41:C6:81:0B:61:48:34:8F:4A:7C:32:8A:70:7B:52:00:F8:33).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_CA-4.crt into store (ski: 15:A2:A3:35:DE:71:32:35:2F:BF:F1:FD:E7:55:D1:9F:D8:F6:2A:5F).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_CA-5.crt into store (ski: AF:CA:84:6B:F3:CA:E1:EA:FF:88:F4:A3:49:A5:38:D0:AA:34:AC:A9).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_CA-6.crt into store (ski: 31:71:87:1F:F0:21:90:7A:FF:C4:63:33:41:C3:F9:86:AF:37:BE:C9).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_CA-7.crt into store (ski: 02:C5:1F:43:11:73:60:32:37:3E:E6:47:86:29:DE:21:B6:72:66:23).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_CA-8.crt into store (ski: 99:45:C7:10:F8:B6:90:19:29:23:D9:3C:7F:41:59:75:82:9D:0E:DA).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_CA-9.crt into store (ski: 7E:70:56:29:D7:90:1A:17:D6:BC:5C:65:D3:CD:47:5D:1D:CE:10:B7).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_CAC_CA.crt into store (ski: A7:22:39:30:7B:50:3C:51:B0:9F:07:0E:C9:A7:0D:01:1E:CE:CB:CF).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_CAC_EMAIL_CA.crt into store (ski: CD:24:39:A6:0B:49:1D:DB:E3:E5:F8:0C:6E:0A:04:63:B2:09:6D:B8).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_EMAIL_CA-10.crt into store (ski: 6F:37:23:A4:D3:20:EB:F4:0C:3F:60:9F:79:4C:0B:72:10:D2:3C:97).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_EMAIL_CA-3.crt into store (ski: EC:13:5B:BC:21:8C:66:9B:0A:8B:7F:07:5F:25:B0:14:F9:10:F5:9B).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_EMAIL_CA-4.crt into store (ski: D5:B6:23:C9:45:82:39:96:44:E8:18:09:A7:D6:8A:61:FD:8C:65:C4).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_EMAIL_CA-5.crt into store (ski: FC:10:FA:B9:6A:61:2E:4F:B3:D7:74:C6:28:1E:69:E0:2F:CE:54:E8).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_EMAIL_CA-6.crt into store (ski: E8:AB:23:35:7A:5B:20:5A:14:29:F5:4A:C9:F0:96:16:80:38:62:B6).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_EMAIL_CA-7.crt into store (ski: 5F:B7:8D:95:96:8A:58:68:0F:8D:D8:E1:5C:7B:C6:E7:76:D1:A1:59).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_EMAIL_CA-8.crt into store (ski: 88:67:29:78:A3:B6:13:1C:70:17:7F:42:93:28:92:14:70:96:73:E5).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_CLASS_3_EMAIL_CA-9.crt into store (ski: AA:D2:53:ED:BF:3E:E0:F4:16:B4:32:D5:DE:44:2A:DA:25:62:97:BF).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_EMAIL_CA-11.crt into store (ski: 53:15:03:45:EE:74:A1:34:5D:6C:86:AF:72:66:81:6F:E9:AD:7F:12).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_EMAIL_CA-12.crt into store (ski: D5:C3:29:8C:A0:77:DC:1C:28:08:4E:77:4F:FF:E9:13:11:63:41:33).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_EMAIL_CA-13.crt into store (ski: A1:18:E6:0A:90:82:0F:FC:BB:D6:87:89:2C:56:C5:F7:CF:68:C7:3D).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_EMAIL_CA-14.crt into store (ski: 07:AD:F7:C7:EA:E0:A8:72:BC:09:EA:C1:4C:8C:18:08:8C:00:DD:5E).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_EMAIL_CA-15.crt into store (ski: 95:B5:8C:78:AB:9D:56:33:3C:F4:48:A3:9C:58:ED:B1:64:8A:8A:9E).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_EMAIL_CA-16.crt into store (ski: 47:93:C7:A3:23:3C:B4:31:EE:CC:42:7C:DD:68:13:CB:01:9A:8F:2D).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_EMAIL_CA-17.crt into store (ski: 26:24:46:AB:7C:65:55:52:4F:2C:8E:5B:37:A0:1D:F2:11:4C:8B:20).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DOD_EMAIL_CA-18.crt into store (ski: C5:4D:F6:66:55:5A:49:5D:D7:3D:F5:3C:88:82:CF:06:9A:C9:10:A4).
WvX509Store<Warn>: WARNING: Tried to add certificate from file /etc/krb5/CERTS/dod_ocsp_ss.crt, but loaded certificate has no ski!
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DoD_PKI_Med_Root_CA.crt into store (ski: C5:59:D2:CE:F1:98:95:50:66:A8:6D:DE:32:4B:D6:61:35:E2:46:B3).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/DST_IECA-2.crt into store (ski: 0E:13:6C:82:A0:47:92:25:C4:D4:54:CA:11:B2:B8:E8:FB:F6:94:00).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/ECA_Root_CA.crt into store (ski: F6:B8:04:27:0E:56:16:D9:B9:63:D9:FD:A1:54:65:41:A0:08:48:2F).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/Med_CA-1.crt into store (ski: 66:50:1D:01:2B:5C:F4:C7:C7:31:41:A7:3F:80:3C:B4:06:C5:D1:BD).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/Med_CA-2.crt into store (ski: 09:BC:11:2B:3B:65:79:47:D6:73:63:DC:07:37:69:16:34:CF:35:85).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/Med_Email_CA-1.crt into store (ski: F2:23:BB:52:26:1A:14:BA:09:72:7D:70:D2:5E:E6:78:3C:68:15:FC).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/Med_Email_CA-2.crt into store (ski: B9:F3:8E:04:97:C0:2D:E2:35:1D:50:88:06:F1:B1:5A:58:DA:F7:58).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/ORC_ECA.crt into store (ski: AC:F7:4B:B6:D6:D2:36:69:F3:BB:A2:03:67:97:19:87:33:65:2E:A5).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/ORC_IECA.crt into store (ski: F8:DD:BA:62:8B:7F:AC:3E:AC:38:DC:20:15:29:C1:79:C6:6E:00:75).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/VeriSign_Client_External_Certification_Authority.crt into store (ski: 0D:C0:D8:3D:BF:FB:65:93:C8:37:66:26:E2:8A:12:5F:BB:C2:80:F5).
WvX509Store<*5>: Loaded certificate from file /etc/krb5/CERTS/VeriSign_IECA.crt into store (ski: 97:31:BE:E8:67:C8:4F:54:83:27:3C:4B:88:3E:10:16:64:44:A3:99).
HTTP Pool<*1>: Pool initializing.
PathFinder<Info>: Checked certificate. Seems to be ok.
PathFinder<Info>: Certificate (/C=US/O=U.S. Government/OU=DoD/OU=PKI/OU=CONTRACTOR/CN=KLINE.JAY.XXXXXXXX) we just got has an issuer (/C=US/O=U.S. Government/OU=DoD/OU=PKI/CN=DOD CA-15). We continue building the path.
X509 Path<*5>: Prepending cert /C=US/O=U.S. Government/OU=DoD/OU=PKI/OU=CONTRACTOR/CN=KLINE.JAY.XXXXXXXX to path.
PathFinder<Info>: Attempting to get CRL.
PathFinder<Info>: 2 urls to choose from.
Pathfinder Download<*5>: Downloading.
HTTP Pool<*4>: Adding a new url to pool: 'http://crl.disa.mil/getcrl?DOD%20CA-15'

PathFinder<Info>: Attempting to get signer.

PathFinder<Info>: 1 urls to choose from.
Pathfinder Download<*5>: Downloading.
HTTP Pool<*4>: Adding a new url to pool: 'http://crl.disa.mil/getsign?DOD%20CA-15'
HTTP Pool<*4>: Checking dns for 'crl.disa.mil'
HTTP Pool<*4>: Checking dns for 'crl.disa.mil'
HTTP Pool<*4>: Checking dns for 'crl.disa.mil'
HTTP Pool<*4>: Selecting true because of 'http://crl.disa.mil/getcrl?DOD%20CA-15'
HTTP Pool<*4>: Checking dns for 'crl.disa.mil'
HTTP Pool<*4>: Selecting true because of 'http://crl.disa.mil/getsign?DOD%20CA-15'
HTTP 214.21.15.23:80<*1>: Opening server connection.
HTTP 214.21.15.23:80<*4>: Adding a new url: 'http://crl.disa.mil/getcrl?DOD%20CA-15'
HTTP 214.21.15.23:80<*1>: Request #1: http://crl.disa.mil/wvhttp-pipeline-check-should-not-exist/
HTTP 214.21.15.23:80<*1>: Request #2: http://crl.disa.mil/getcrl?DOD%20CA-15
HTTP 214.21.15.23:80<*4>: Adding a new url: 'http://crl.disa.mil/getsign?DOD%20CA-15'
HTTP 214.21.15.23:80<*1>: Request #3: http://crl.disa.mil/getsign?DOD%20CA-15
HTTP 214.21.15.23:80<*1>: close called
HTTP 214.21.15.23:80<*1>: Pipelining is broken on this server (2)!  Disabling.
HTTP 214.21.15.23:80<*1>: close called
HTTP 214.21.15.23:80<*1>: URL 'http://crl.disa.mil/wvhttp-pipeline-check-should-not-exist/' is FAILED (104 (Connection reset by peer))
HTTP 214.21.15.23:80<*1>: close done
HTTP 214.21.15.23:80<*1>: URL 'http://crl.disa.mil/wvhttp-pipeline-check-should-not-exist/' is FAILED (104 (Connection reset by peer))
HTTP 214.21.15.23:80<*1>: close done
HTTP 214.21.15.23:80<*1>: close called
HTTP 214.21.15.23:80<*1>: URL 'http://crl.disa.mil/wvhttp-pipeline-check-should-not-exist/' is FAILED (104 (Connection reset by peer))
HTTP 214.21.15.23:80<*1>: close done
HTTP Pool<*1>: Unconnecting stream to 214.21.15.23:80.
HTTP 214.21.15.23:80<*2>: Deleting.
HTTP 214.21.15.23:80<*1>: Error was: Connection reset by peer
HTTP 214.21.15.23:80<*1>: close called
HTTP 214.21.15.23:80<*1>: URL 'http://crl.disa.mil/wvhttp-pipeline-check-should-not-exist/' is FAILED (104 (Connection reset by peer))
HTTP 214.21.15.23:80<*1>: close done
HTTP 214.21.15.23:80<*1>: Opening server connection.
HTTP 214.21.15.23:80<*4>: Adding a new url: 'http://crl.disa.mil/getcrl?DOD%20CA-15'
HTTP 214.21.15.23:80<*1>: Request #1: http://crl.disa.mil/getcrl?DOD%20CA-15
HTTP 214.21.15.23:80<*4>: Adding a new url: 'http://crl.disa.mil/getsign?DOD%20CA-15'
HTTP 214.21.15.23:80<*4>: Header: 'HTTP/1.1 200 OK'
HTTP 214.21.15.23:80<*4>: Header: 'Server: Netscape-Enterprise/6.2 RHAT'
HTTP 214.21.15.23:80<*4>: Header: 'Date: Thu, 10 Jul 2008 18:15:11 GMT'
HTTP 214.21.15.23:80<*4>: Header: 'Accept-ranges: bytes'
HTTP 214.21.15.23:80<*4>: Header: 'Last-modified: Thu, 10 Jul 2008 04:32:00 GMT'
HTTP 214.21.15.23:80<*4>: Header: 'Etag: C6EF9A475279991F12F701CDBD2957B4F08D246'
HTTP 214.21.15.23:80<*4>: Header: 'Expires: Thu, 17 Jul 2008 04:32:00 GMT'
HTTP 214.21.15.23:80<*4>: Header: 'Cache-control: max-age=97200,public,no-transform,must-revalidate'
HTTP 214.21.15.23:80<*4>: Header: 'Content-length: 6076453'
HTTP 214.21.15.23:80<*4>: Header: 'Content-type: application/pkix-crl'
HTTP 214.21.15.23:80<*4>: Header: 'Content-disposition: attachment; filename=DODCA_15.crl'
HTTP 214.21.15.23:80<*4>: Header: 'Connection: keep-alive'
HTTP 214.21.15.23:80<*4>: Header: ''
HTTP 214.21.15.23:80<*4>: Starting data: 6076453 (enc=2)
HTTP 214.21.15.23:80<*5>: Read 568 bytes (6075885 bytes left).
HTTP 214.21.15.23:80<*5>: Read 1024 bytes (1621 bytes left).
<snip>
HTTP 214.21.15.23:80<*5>: Read 344 bytes (1277 bytes left).
HTTP 214.21.15.23:80<*5>: Read 1024 bytes (253 bytes left).
HTTP 214.21.15.23:80<*5>: Read 253 bytes (0 bytes left).
HTTP 214.21.15.23:80<*1>: Done URL: http://crl.disa.mil/getcrl?DOD%20CA-15
HTTP 214.21.15.23:80<*1>: Request #2: http://crl.disa.mil/getsign?DOD%20CA-15
PathFinder<Info>: Got CRL with mimetype (nil).
X509 CRL<*5>: Decoding CRL from DER format.
HTTP 214.21.15.23:80<*4>: Removing an url: 'http://crl.disa.mil/getcrl?DOD%20CA-15'
HTTP 214.21.15.23:80<*4>: Header: 'HTTP/1.1 200 OK'
HTTP 214.21.15.23:80<*4>: Header: 'Server: Netscape-Enterprise/6.2 RHAT'
HTTP 214.21.15.23:80<*4>: Header: 'Date: Thu, 10 Jul 2008 18:15:35 GMT'
HTTP 214.21.15.23:80<*4>: Header: 'Accept-ranges: bytes'
HTTP 214.21.15.23:80<*4>: Header: 'Last-modified: Wed, 14 Jun 2006 15:22:16 GMT'
HTTP 214.21.15.23:80<*4>: Header: 'Etag: D80A1B23037545ADE0A0B36791EBDF6F7D1E81D8'
HTTP 214.21.15.23:80<*4>: Header: 'Expires: Wed, 13 Jun 2012 23:00:00 GMT'
HTTP 214.21.15.23:80<*4>: Header: 'Cache-control: max-age=97200,public,no-transform,must-revalidate'
HTTP 214.21.15.23:80<*4>: Header: 'Content-length: 1072'
HTTP 214.21.15.23:80<*4>: Header: 'Content-type: application/pkix-cert'
HTTP 214.21.15.23:80<*4>: Header: 'Content-disposition: attachment; filename=DODCA_15.cer'
HTTP 214.21.15.23:80<*4>: Header: 'Connection: keep-alive'
HTTP 214.21.15.23:80<*4>: Header: ''
HTTP 214.21.15.23:80<*4>: Starting data: 1072 (enc=2)
HTTP 214.21.15.23:80<*5>: Read 569 bytes (503 bytes left).
HTTP 214.21.15.23:80<*5>: Read 503 bytes (0 bytes left).
HTTP 214.21.15.23:80<*1>: Done URL: http://crl.disa.mil/getsign?DOD%20CA-15
PathFinder<Info>: Got certificate with mimetype (nil).
PathFinder<Info>: Checked certificate. Seems to be ok.
PathFinder<Info>: Certificate (/C=US/O=U.S. Government/OU=DoD/OU=PKI/CN=DOD CA-15) we just got has an issuer (/C=US/O=U.S. Government/OU=DoD/OU=PKI/CN=DoD Root CA 2). We continue building the path.
X509 Path<*5>: Prepending cert /C=US/O=U.S. Government/OU=DoD/OU=PKI/CN=DOD CA-15 to path.
PathFinder<Info>: Attempting to get CRL.
PathFinder<Info>: 2 urls to choose from.
Pathfinder Download<*5>: Downloading.
HTTP Pool<*4>: Adding a new url to pool: 'http://crl.gds.disa.mil/getcrl?DoD%20Root%20CA%202'

PathFinder<Info>: Attempting to get signer.
Path Validator<Info>: Encountered error (No urls to download object needed to perform validation) during path discovery. Aborting.
Error while validating path (No urls to download object needed to perform validation)

X509 CRL<*5>: Deleting.

--
Personal Mail from Patrick Patterson
No company affiliation

[William Lachance]

On Sat, 2008-07-12 at 20:47 -0700, Patrick Patterson wrote:

> Hi Jay:
>
> Could you also send your pathfinder config file?
>
> Also, if you could, could you send the certificate that you are trying
> to validate?

Jay and I did a bit of debugging over irc the other day. It turns out
that the problem is that some of the certificates in his chain were
lacking AIA information (an CRLs lacking AKI info).

We also turned up some more problems/ideas that I'll try to get him to
redirect to the list so we can discuss them further.
--
William Lachance <wrl...@gmail.com>

[Patrick Patterson]

Ah, OK

If Jay wants to contact me directly, he can as well, as this sounds like it may be a bigger issue with DoD vs. FBCA certificate profiles (Pathfinder was designed to allow PDVal with CertiPath/FBCA profile certificates, and if we need to support other profiles, I'd like to see what they would be, and then we can make the right design decisions on the best ways to support them).

Patrick.

[Jay Kline]

Sorry for the long delay in getting back to this issue, I was out
traveling.

First, the "bridges" section wants the certs to be in pkcs7 format,
which is kind of annoying for us, so I changed it to load from a
directory. Ideally the left-hand-side of the config should actually be
looked at to indicate if pkcs7 or directories are used. I wasnt able to
grasp the uniconf stuff at first try to fix it properly.

Anyway, the older DoD CAs do not have AIA info at all, though the newer
ones do. However, I had configured pathfinder to have the intermediate
CAs to be in the "bridges" section, with the root CAs in "Trusted
directories", so it should have been able to build the path with the
given information. If I added the root CAs into the "bridges" it did
build the path. So I fixed that too.

Pathfinder would then download the CRL, the CRL checks out ok itself,
but pathfinder wont use because the intermediate CA's CRLs have no AKI.
Interestingly, the root CA's CRLs do. Any thoughts on how to deal with
this situation?

Doing a --skip-crl-check still downloads the CRL, but it wont use it.
This is a problem, because our CRLs average about 250000 entries (6Mb or
so), so it is a significant delay.

Also, while downloading things, it seems it always tries to get
httl://<server>/wvhttp-pipeline-check-should-not-exist/ for some reason.
This seems unnecessary, but I wasnt able to track down why/where that
was happening.

Thats about as far as I got. Really, downloading CRLs is not practical
for us, the size of the CRLs is too large. Im going to poke at OCSP
support at some point, as that would be vastly superior for our needs.
My C++ is rusty, but after dabbling in the source some, it started to
come back.

If you would like, I can provide more info about the DoD PKI structure,
at least from my own experiences with it.

Jay

[Patrick Patterson]

Hi Jay:

On Wed, Jul 23, 2008 at 1:46 PM, Jay Kline <slush...@gmail.com> wrote:

Sorry for the long delay in getting back to this issue, I was out
traveling.

Well, thanks for sticking with us :)
 

First, the "bridges" section wants the certs to be in pkcs7 format,
which is kind of annoying for us, so I changed it to load from a
directory. Ideally the left-hand-side of the config should actually be
looked at to indicate if pkcs7 or directories are used.  I wasnt able to
grasp the uniconf stuff at first try to fix it properly.

Ok - I'll file a bug to handle something other than a PKCS#7 bundle - would:

[bridges]
pkcs7 = XX:XX:XX:...
dir/0/location = /some/directory/location
dir/0/fingerprint = XX:XX:XX:...

be OK (Uniconf actually stores information in a tree, and natively uses slashes for content, we just use "INI" style files for convenience - it saves typing:

/bridges/pkcs7=XX:XX:XX:...
/bridges/dir/0/location=/some/directory/location
/bridges/dir/0/fingerprint=YY:YY:YY:...
 

Anyway, the older DoD CAs do not have AIA info at all, though the newer
ones do. However, I had configured pathfinder to have the intermediate
CAs to be in the "bridges" section, with the root CAs in "Trusted
directories", so it should have been able to build the path with the
given information. If I added the root CAs into the "bridges" it did
build the path. So I fixed that too.

We will take a look at how that works, and get back to you.

Pathfinder would then download the CRL, the CRL checks out ok itself,
but pathfinder wont use because the intermediate CA's CRLs have no AKI.
Interestingly, the root CA's CRLs do. Any thoughts on how to deal with
this situation?

 

Yes - we will fix the code to implement the RFC5280 compliant CRL association code.
 

Doing a --skip-crl-check still downloads the CRL, but it wont use it.
This is a problem, because our CRLs average about 250000 entries (6Mb or
so), so it is a significant delay.

Ok - that one we'll fix immediately - I'm just checking internally to see how long it would be to fix this :)

Also, while downloading things, it seems it always tries to get
httl://<server>/wvhttp-pipeline-check-should-not-exist/ for some reason.
This seems unnecessary, but I wasnt able to track down why/where that
was happening.

Yes - this is in WvStreams, the base library that handles the networking and low level functions - I can't remember why this is in there, but I think that it's so that the URL downloader can tell if it's an HTTP/1.0 or HTTP/1.1 compliant server - for our case it shouldn't matter, and I'll look into how to turn it off.
 

Thats about as far as I got.  Really, downloading CRLs is not practical
for us, the size of the CRLs is too large.  Im going to poke at OCSP
support at some point, as that would be vastly superior for our needs.
My C++ is rusty, but after dabbling in the source some, it started to
come back.

Well, OCSP support is fairly high on our list of "things to add" - and as I've said above, I'll see how soon we could spin a release to at least stop downloading that huge CRL each time.
 

If you would like, I can provide more info about the DoD PKI structure,
at least from my own experiences with it.

Perhaps we could take this part of the discussion off of the list - feel free to mail me at

ppatt...@carillon.ca

and we can discuss further.

Thanks for your patience,

Patrick.
 

Jay

Patrick Patterson wrote:
> Ah, OK
>
> If Jay wants to contact me directly, he can as well, as this sounds
> like it may be a bigger issue with DoD vs. FBCA certificate profiles
> (Pathfinder was designed to allow PDVal with CertiPath/FBCA profile
> certificates, and if we need to support other profiles, I'd like to
> see what they would be, and then we can make the right design
> decisions on the best ways to support them).
>
> Patrick.
>
> On Mon, Jul 14, 2008 at 3:48 PM, William Lachance <wrl...@gmail.com

> <mailto:wrl...@gmail.com>> wrote:
>
>
>     On Sat, 2008-07-12 at 20:47 -0700, Patrick Patterson wrote:
>
>     > Hi Jay:
>     >
>     > Could you also send your pathfinder config file?
>     >
>     > Also, if you could, could you send the certificate that you are
>     trying
>     > to validate?
>
>     Jay and I did a bit of debugging over irc the other day. It turns out
>     that the problem is that some of the certificates in his chain were
>     lacking AIA information (an CRLs lacking AKI info).
>
>     We also turned up some more problems/ideas that I'll try to get him to
>     redirect to the list so we can discuss them further.
>