Closed GoogleCodeExporter closed 8 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
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
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
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
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
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
Closing
Original comment by gm2...@cerner.com
on 25 Jun 2013 at 2:05
Original issue reported on code.google.com by
Alan.C.V...@gmail.com
on 19 May 2013 at 6:09