CRL-based Certificate Revocation Feature Not working in Java RI 2.0

[GoogleCodeExporter]

The Java RI (2.0) appears to ignore the revocation and delivers the mail anyhow.
I was under the impression the Java RI met the Applicability Statement 
requirement by implementing revocation via CRL (Certificate Revocation List). 
Below outlines how I got here.

What I do to to get the test case setup
---------------------------------------

1. Setup two Direct (Java RI 2.0) servers on separate domains.
2. Use a Certificate Authority Configuration that supports revocation via CRL.
3. Revoke a certificate and ensure the corresponding CRL URI is updated.

What is the expected output? What do you see instead?

I would expect for the James log to not send the message because the 
certificate has been revoked.  Instead the message is delivered despite the 
revocation. The URL for the CRL is embedded in the public certificate.

Version/OS?
-----------

Java RI version 2.0.  
James 2.3. 
Ubuntu 12.04 LTS 64-bit

Additional Information
----------------------

If this capability exists in the RI, then it is not enabled by default.

Are there instructions for making this work?

Below is the output for the contents of the revoked certificate and the 
corresponding CRL.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 276 (0x114)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=MD, L=Gaithersburg, O=NIST, CN=microphr.com/emailAddress=microphr.com
        Validity
            Not Before: May 19 14:57:03 2013 GMT
            Not After : May 19 14:57:03 2014 GMT
        Subject: C=US, ST=MD, L=Gaithersburg, O=NIS, CN=revoked@direct.microphr.com/emailAddress=revoked@direct.microphr.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d3:92:b2:e1:0c:b8:41:76:ac:b0:22:b2:a7:32:
                    93:84:15:95:6a:6f:ee:bb:55:e6:b4:67:7b:21:86:
                    e7:a2:e9:fe:56:bb:17:64:78:e2:6a:d8:32:ca:ec:
                    d4:0c:1a:80:78:19:a3:e6:72:57:2a:7d:5a:2d:08:
                    a6:16:a3:6b:56:5c:81:a0:49:c9:4a:6b:13:c5:39:
                    a8:99:55:64:dc:ac:67:c5:6e:77:92:47:9d:9d:aa:
                    52:e3:a6:35:62:38:8c:a1:72:b1:8e:83:72:5c:46:
                    a6:90:52:e0:db:14:4f:88:87:f8:6e:70:4f:29:33:
                    58:3d:2d:5b:cd:1d:93:03:3e:2d:24:d2:97:86:79:
                    27:fc:d1:b1:c7:b7:0f:04:d7:99:0f:ce:c8:d7:cc:
                    55:81:2a:04:3f:ba:f6:9a:5b:4d:66:e3:78:76:62:
                    cf:61:5a:6c:ca:6f:1f:b4:a6:8e:f1:dc:72:ac:33:
                    7d:7b:3d:91:94:11:da:f4:4b:a4:66:1f:be:3d:61:
                    55:59:ea:71:d2:d9:fa:af:4e:26:b7:a9:93:a6:73:
                    66:81:75:da:1e:c6:08:3b:c6:84:c4:97:3b:3c:bc:
                    24:07:2c:75:36:9a:a2:c9:4c:4c:41:76:a5:ca:0a:
                    91:9d:e1:bc:a6:c5:02:4a:29:9b:50:da:0c:e0:92:
                    4a:fd
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Subject Alternative Name: 
                email:revoked@direct.microphr.com
            X509v3 Subject Key Identifier: 
                77:ED:C5:F8:D0:EF:76:6E:B8:4D:99:CF:DA:1E:89:AC:04:C2:64:47
            X509v3 Authority Key Identifier: 
                keyid:60:F7:AB:38:A8:9C:24:8F:CF:00:05:56:A0:D0:D6:FE:6E:12:A4:9C
                DirName:/C=US/ST=West Virginia/L=Williamsburg/O=Directca.org (Videntity, Inc.) - For Testing Only/CN=ca.directca.org/emailAddress=directca@videntity.com
                serial:01:0F

            Netscape CA Revocation Url: 
                http://ca.directca.org/crl/direct-ca-crl.pem
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://ca.directca.org/crl/direct-ca-crl.pem

                Full Name:
                  URI:http://rcsp.directca.org/0114.json

            Authority Information Access: 
                CA Issuers - URI:http://pubcerts.directca.org/x5c/0114-x5c.json

    Signature Algorithm: sha256WithRSAEncryption
         79:db:96:cf:e5:12:27:2c:cf:ba:c5:88:3c:da:d2:d7:14:88:
         2d:af:4d:f5:93:e6:02:fe:05:f7:f4:b3:44:f2:03:8b:0a:51:
         39:3a:b6:ec:e1:24:25:73:8a:49:5f:06:b2:f0:e9:ee:6f:59:
         1d:0b:eb:29:6d:02:35:63:12:21:1e:47:41:4d:2c:d4:94:5e:
         f5:8e:e3:ab:92:db:ef:53:a7:a5:b0:5a:56:ee:4a:8a:ab:cb:
         83:60:58:f5:c4:5b:6d:5a:2b:81:68:fa:58:f5:81:2f:a9:cd:
         9e:c3:fa:51:4b:46:be:b6:02:ef:01:66:27:19:f0:27:7a:2e:
         4b:31:73:49:96:b0:70:3e:2d:6d:16:b7:b9:df:0f:d8:c0:37:
         50:c3:51:76:86:eb:ae:51:fe:cc:92:75:54:30:92:af:5e:88:
         cd:9b:61:93:9f:06:92:85:cc:53:cb:25:7e:34:c5:ec:44:2b:
         71:c5:1f:6b:af:15:1c:2d:ad:2a:77:95:7b:07:17:d8:a2:41:
         25:ab:a8:28:68:a4:ee:d1:ba:2a:ba:52:ed:cf:78:cf:92:3b:
         88:cb:38:99:64:7d:c7:3e:9e:05:11:47:ef:96:7b:9e:a3:0a:
         39:93:15:7a:d2:e0:ce:2f:fb:79:f0:bb:2c:e8:63:75:1f:95:
         f3:8f:8d:d3

..............and the CRL looks like this:

Certificate Revocation List (CRL):
        Version 1 (0x0)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: /C=US/ST=West Virginia/L=Williamsburg/O=Directca.org (Videntity, Inc.) - For Testing Only/CN=ca.directca.org/emailAddress=directca@videntity.com
        Last Update: May 19 15:38:31 2013 GMT
        Next Update: May 20 15:38:31 2013 GMT
Revoked Certificates:
    Serial Number: 0111
        Revocation Date: May 19 14:46:54 2013 GMT
    Serial Number: 0113
        Revocation Date: May 19 15:21:21 2013 GMT
    Serial Number: 0114
        Revocation Date: May 19 15:38:13 2013 GMT
    Serial Number: 0116
        Revocation Date: May 19 15:22:54 2013 GMT
    Signature Algorithm: sha256WithRSAEncryption
         33:bf:96:a5:0e:49:3d:68:14:04:5e:ce:22:a8:ef:28:da:d3:
         22:b8:03:89:be:66:ae:6c:9b:cd:c5:2a:18:c6:b9:a4:65:53:
         fb:46:e5:f0:76:4a:75:83:f9:ec:08:d4:0e:6b:57:59:76:84:
         30:a1:b4:98:1c:ef:51:6e:6a:e3:af:ec:1d:68:e3:67:b2:b8:
         f7:09:b4:0e:c0:f0:40:65:63:05:07:25:bb:b7:e9:b4:ea:4c:
         40:e3:bd:5c:47:21:c4:22:43:31:51:7a:c3:fc:d6:ff:f4:c8:
         34:64:9b:92:a2:71:fd:66:7d:11:ec:3f:15:a4:21:6f:fc:67:
         0f:0d:fc:74:d3:00:22:ef:86:6d:f8:02:04:2a:a7:27:27:68:
         15:7e:00:66:c6:2e:60:f7:bd:95:17:d2:49:d3:9a:74:96:c5:
         6d:d6:8e:20:21:36:79:72:d4:e8:2a:a3:0d:3e:b6:e9:66:1a:
         a9:02:54:ed:53:7b:3c:e4:a7:1c:9b:85:01:fc:ac:04:02:4f:
         52:8d:da:cb:20:db:90:8b:b5:38:fe:bb:9b:6d:73:ca:d4:c0:
         d3:ca:41:1c:d7:86:7a:1d:1e:a1:5b:4a:aa:da:8b:37:2c:9b:
         db:e6:03:66:c3:65:a3:73:f0:f4:c9:06:b6:e8:d6:34:29:96:
         83:40:c5:d6:c5:ff:f2:68:bd:45:07:d8:05:b0:06:36:7b:67:
         d6:90:b3:5a:83:f9:61:ed:70:ba:f9:7c:22:94:72:a4:a4:22:
         fe:23:90:1a:41:be:81:3e:0c:94:66:5a:2b:37:6b:1f:18:a6:
         80:49:ae:60:9b:a0:01:29:c5:d4:ed:49:6f:45:14:59:a4:80:
         ee:24:84:c5:b2:f5:c9:21:c1:ba:99:33:e3:5d:35:3a:45:4f:
         be:0e:d9:ef:5f:df:e3:9e:8f:f3:0a:9f:d4:b0:e9:5d:f7:ed:
         c3:c0:15:00:7a:da:11:5a:b3:32:21:14:a9:d3:98:6a:08:f9:
         85:2d:7f:1d:94:e7:a8:b1:68:bb:ad:13:32:90:af:2f:44:10:
         4f:8a:7e:b2:e6:5a:a8:9f:7f:bd:85:77:95:28:19:c4:c6:65:
         bc:85:9e:5e:9c:45:f4:35:4c:9a:bb:4f:42:5d:a9:9c:6b:9e:
         ec:09:6d:78:0f:e2:dc:29:cc:42:0a:f8:16:9b:33:4e:68:fa:
         5a:cb:f5:80:24:a8:b6:97:33:ab:4d:22:07:17:5a:6d:5f:b9:
         a6:f0:43:0f:ef:e3:a9:9d:f4:f7:72:f2:8e:54:55:2d:88:d0:
         37:fc:cc:54:af:cf:86:4b:56:ef:d0:37:ae:9f:d3:2a:c9:51:
         50:ea:55:84:92:f2:c8:4e

Original issue reported on code.google.com by Alan.C.V...@gmail.com on 19 May 2013 at 6:00

[GoogleCodeExporter]

Hello Alan, 
As in your post for issue 212, I think your issue here is what constitutes a 
"complete certification path". RFC 5280 section 6 defines this as a chain of 
certificates 1..N where certificate 1 is issued by the trust anchor, and 
certificate N is the cert to be validated. The certificate validation algorithm 
only requires revocation testing for certificates 1..N, and not for the Trust 
Anchor itself or for any superior CA certificates. It follows that the Trust 
Anchors should be chosen and/or distributed accordingly. So it seems to me that 
the RI is processing this correctly. 
Luis Maas
EMR Direct

Original comment by lcmaas3 on 19 May 2013 at 11:17

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Luis:

Perhaps you misunderstood my question.

This question is not about a "complete certificate path", but rather about CRL 
/revocation support.

Best,

Alan Viars

Original comment by Alan.C.V...@gmail.com on 20 May 2013 at 1:39

[GoogleCodeExporter]

Alan, I believe I do understand you fully. Certificate path validation and 
CRL/revocation checking are closely linked. 

The Applicability statement section 4.2 requires that the rules of RFC 5280 
section 6 be followed for certificate path validation; section 6.3 defines the 
rules for revocation status checking, which is part of certification path 
validation. Section 6 is a long and complicated part of the RFC and needs to be 
studied carefully to be fully understood. The key part related to your issue is 
that a Relying Party only needs to check revocation status for the certificates 
in the complete certificate path. As defined clearly in RFC 5280, the Trust 
Anchor is _not_ part of that path, and its revocation status is not checked as 
part of the algorithm. You build a chain up to the Anchor, but the Anchor 
itself is never part of the validation path. Subtle difference, but important. 
Trust Anchors and their revocation information are distributed through some 
other out-of-band trusted mechanism, for example, a trust bundle.

If you wish to add a requirement to check Trust Anchor revocation status, that 
would be a perfectly valid local policy decision, but would not be required by 
RFC 5280 or the Applicability Statement. Understand that doing this would 
require another set of Anchors that would be trusted to validate the CRLs of 
intermediate Trust Anchors, so it is not really that simple.

If your Trust anchor (Intermediate-1) is issued by a root (CA-1), and your CA 
wants to make sure that Relying Parties check the revocation status of 
Intermediate-1, the correct thing to do would be to design your hierarchy such 
that CA-1 can be the Trust Anchor instead of Intermediate-1, then 
Intermediate-1 would be part of the complete certification path and checking 
the revocation status of Intermediate-1 would be required as part of the 
algorithm in RFC 5280 Section 6.

Cheers,
Luis

Original comment by lcmaas3 on 20 May 2013 at 3:53

[GoogleCodeExporter]

I'm just revoking a domain-bound and email-bound certificate and the CRL is in 
the cert, yet the mail still sends.  I have not yet tried revoking the Trust 
Anchor or CA yet.  Still not understanding how this can be for a system 
designed to transmit PHI.

I have this setup.

CA->Trust Anchor->Email bound certificate

They all use use the same CRL URL.  When I revoke the email-bound certificate 
(i.e. the endpoint), the email still sends, when I expect it to fail.

I'm perplexed.

Alan

Original comment by Alan.C.V...@gmail.com on 20 May 2013 at 7:31

[GoogleCodeExporter]

If that is the case you are trying to test, then either your setup is 
nonconforming or you have listed the wrong CRL in your original post, or both. 
My original reply was based on the fact that the CRL was issued by the root 
CA...

Original comment by lcmaas3 on 21 May 2013 at 3:47

[GoogleCodeExporter]

The certificate and the corresponding CRL are in my original post.

the serial for the cert is Serial Number: 276 (0x114) and the the CRL contains 
this matching serial:

  Serial Number: 0114
        Revocation Date: May 19 15:38:13 2013 GMT

The CRL URL is accessible via the web.  my configuration is pretty 
standard....just out of the box...the only modification was to deliver MDNs 
back to the edge.  

The how for revocation is not defined in the applicability statement, but I was 
told that the Java RI meets the Applicability statement via  CRL support. Have 
you ever seen this in action or tried this yourself?

BTW. my CRL is in PEM format, which is the standard way based on my 
understanding.

I'd really like to get to the bottom of this.  If its not implemented or a bug, 
that's fine...I just need to know for sure one way or the other.

Best,

Alan Viars
@aviars

Original comment by Alan.C.V...@gmail.com on 21 May 2013 at 5:21

[GoogleCodeExporter]

CRL issue was due to issuer of CRL.  The RI works as expected and designed.

Original comment by gm2...@cerner.com on 25 Jun 2013 at 2:06

• Changed state: Invalid