microtan / nhin-d

Automatically exported from code.google.com/p/nhin-d
0 stars 0 forks source link

Broken Certificate/Path still delivers messages in Java RI v 2.0 #212

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The Java RI (2.0) appears to not walk the certificate path back to the root CA. 
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 whereby the CA certificate and the 
Direct Trust Anchor are NOT the same certificate. Do this for both domains.  
3. The CA public certificate is left not installed/ not-discoverable by the RI.
4. Both domains exchange trust anchors

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 chain cannot be verified.  Instead the message is delivered 
despite the fact the RI cannot access the CA's public certificate and therefore 
unable to verify the certificate path back to to the root.

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?

All the Best,

Alan Viars

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

GoogleCodeExporter commented 9 years ago
Hello Alan, 
I'm assuming for this discussion that your Trust Anchor is an intermediate CA. 
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 trust anchor itself is not part of the complete path, nor are 
any superior CA certs such as for a CA that issued the trust anchor. There is 
no requirement in 5280 to verify back to the root, only back to the Trust 
Anchor. So it seems to me that the RI behaves as expected.
Luis Maas
EMR Direct

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

GoogleCodeExporter commented 9 years ago
Hello Luis:

After looking at this carefully it does seem that RFC 5280 does not require the 
root CA to be part of the certificate path to be validated. (RFC 3280, not used 
by Direct, does have this stipulation.)

So this means that the Applicability Statement allows for personal health 
information (PHI) to be transmitted even if the CA does not exist and/or cannot 
be verified... something that would produce at least a warning in a similar 
browser scenario.
Seems like a pretty serious security issue to me.

My personal opinion is that the Applicability Statement should explicitly 
require tracing back to the root CA, because otherwise personal health 
information will be moving using untrusted/unverified certificates.

Best,

Alan Viars

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

GoogleCodeExporter commented 9 years ago
Alan, this is not an issue if you make it a policy to use only Trust Anchors 
that are actually trustworthy. Hence the comment in Applicability Statement 
4.2.1: "The mechanism by which ... trust anchors are selected and maintained is 
a critical matter of policy that is not defined in this document." 

See also my additional comments for Issue 211.

Luis

Original comment by lcmaas3 on 20 May 2013 at 4:01

GoogleCodeExporter commented 9 years ago
Luis:

I predict that folks will continue to use self-signed certificates in 
production.

It just makes sense to me (my opinion only) that it would behave like a browser 
behave.  The current situations means people can deploy the Direct in a less 
than ideal security apparatus. POP and SMTP are also clear text out of the box, 
but that's another issue.

I'm just trying to understand what works and what doesn't. I understand the 
Java RI is just an RI and only a starting point, but it seems many commercial 
solutions are based on it. In my opinion, these current state is not a good 
security posture for a system designed to transmit PHI. 

Alan

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

GoogleCodeExporter commented 9 years ago
Not trying to throw stones here....just looking to make things better moving 
forward.

-Alan

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

GoogleCodeExporter commented 9 years ago
This issue should be closed.  The Java RI meets the AS "Applicability 
Statement" in this case because there is no requirement in the AS for a Direct 
implementation to certify Root CA's certificate.

Alan Viars
@aviars

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

GoogleCodeExporter commented 9 years ago
Closing

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