Re: [ihe-hpd-implementors:376] Digest for ihe-hpd-implementors@googlegroups.com - 2 updates in 1 topic

14 views
Skip to first unread message

Peter Bachman

unread,
Apr 8, 2015, 1:44:10 PM4/8/15
to Digest recipients
I think Matt is correct in saying the use case for Certificate Discovery was constructed in the way that it was, but that was not intended to be a limitation but an implementation that would always work for Direct. The pros and cons of LDAP and DNS were widely discussed and whether Direct was trying to rule out the common desktop software capable of doing LDAP and not DNS certificate lookup. In fact that was exactly what they were doing although the Applicability Statement contradicts this. This is very different from a developer versus user perspective. As a developer I don't especially care, they both can handle the information but there is the issue that it's very large data to put in the DNS and has to be converted from base 64. Also ICANN is not going to be that helpful in this regard.

The fact that COTS doesn't do this is because it's not the regular way to do it not that it can't be done. The practical effect was to suddenly ditch the SMTP using S/MIME which did end to end encryption to a different security model using edge protocols where the data was exposed at the HISP.

That forced the HISPs to have BAA with signed with their customers to assign liability if they breached the information.

For provider directory there is a much richer set of selectors and thus can bind a certificate to the subject of the certificate and the rest of the attributes follow.

Once you get to a subject alternative name you no longer have that binding that's what's bound in the certificate, what is certified and the email address is not the only value that can go there.

On the Directory side the user certificate can be associated an entry and if one has done the c=, st= o=, ou=, with a valid DN that is unique and scaled to the US realm, the problem is solved, but requires a coordinated solution and as John has said, other countries have been able to pull this off.

The definition of Direct address as an endpoint to a service is a different idea to aid the sender with knowing what services are available and the values.




On Wed, Apr 8, 2015 at 5:09 AM <ihe-hpd-im...@googlegroups.com> wrote:
Peter Bachman <pbspamfi...@gmail.com>: Apr 07 07:10AM -0400

While the comments I have seen are true, there are concepts and history
that are not understood very well and others that are developmental. The
fact that one can store a certificate in the DNS is true, but there were a
lot of discussions on whether it made any practical sense. In fact in
practical testing I found operational HISPs that had both valid and invalid
certificates in the DNS.
 
That is because there is very weak binding between a domain name and
identity. Anyone can stick a certificate in the DNS and claim that belongs
to a specific organization as a point of contact. Also the decision was
made not to sign the Domain name with digital signatures as a requirement
using DNS security (DNSSEC)
 
Then to further break the security model the Direct transport model qua
endpoints with *.* possible connections as it was originally designed
became SMTP between HISPs only as a business, not standards or protocol
specification model based on applicability statement one (AS1).
 
We now know why that happened and it has nothing to do with the standards
or the complications in adopting a specific schema like HPD or HPD plus.
 
Bear in mind that organizations like NASA and the Nuclear Labs and NATO had
been sending encrypted email using certificates just fine since 1996 using
existing schema attributes so when Direct embraced DNS and seemed about to
reject LDAP entirely a compromise was brokered to use either since I would
not accept DNS only.
 
Along at the same time came the idea of broadening the concept of a defined
service endpoint in the schema in which Direct would be one possibility.
 
Now to the larger picture since it gets muddy when talking about specific
schema attributes. In the development of the standards, in which I played a
role in defining how LDAPv3 stores binary objects like certificates,
historically if you don't understand the history of X.500 and X.509 plus
RFC 5280 plus the ISO description of a provider directory prior to HPD
which dates back to 1988 why you put the information in 3 places has no
context.
 
First of all one has to understand LDAP as it is defined.
 
Then one has to understand how LDAP is defined by IETF and not Direct and
certainly not Direct Trust, or the redefinition of what we did in S&I by
modular specifications which ran with ONC's encouragement as a circa 2000
novel approach with extending LDAP with federation between databases using
LDIF repurposed as DSML using XML to work between those databases. That was
never part of the S&I Provider Directory IG or discussed so of course the
code forked. What was discussed was accommodating some of Direct's
participants who had specific implementations using DNS.
 
Then if you understand what and why X.500 and the relationship to X.509
versions 1 to version 3 in relation to certain attributes in the
certificates then there should be an aha moment where it's obvious how that
works to remove any confusion and what role HPD or HPD+ plays and what
makes sense when asking questions about national requirements. As one
delves deeper it becomes evident that one is dealing with an alternative
structure, not wrong per se, just tailored to suit the interests of
database vendors and the EHRs that use those databases instead of the
Internet standards (which are defined by loose consensus and running code)
combined with ISO standards. That said, and I think Karen will back me up
on this. IHE does not write "standards" Neither did S&I, however the mod
spec group does not feel they operate under those constraints when they
repurposed DSML, or did Direct when they went across the grain to use an
obscure RFC to justify putting certificates in the DNS for business rather
than technical reasons.
 
 
 
 
 
"Moehrke, John (GE Healthcare)" <John.M...@med.ge.com>: Apr 07 01:01PM

Peter,
 

 
I can confirm that all you said is true.. The history of Direct is very ugly. I did what I could at the time to get them to use standards, however the deciding factor was always “first to code”. No matter how much I pointed at ‘already working systems’ they were not “code” checked into the Direct reference repository. So, the decisions that look silly now, were made by one coder when they decided to implement something and checked working code in. Unfortunately today the momentum still rules the day. There is no ‘fixing’ Direct, there is only waiting until it dies because a better solution fills the need.
 

 
Many of the issues you point out are indeed documented as known issues in the Direct wiki. Many of them on the Security Risks page…
 

 
You leave us all on the edge of our seats waiting for that ‘aha moment’... I know what my understanding is, however if we all have different aha moments then we don’t have agreement. What is your conclusion?
 

 
John
 

 
From: ihe-hpd-im...@googlegroups.com [mailto:ihe-hpd-im...@googlegroups.com] On Behalf Of Peter Bachman
Sent: Tuesday, April 07, 2015 6:11 AM
To: ihe-hpd-im...@googlegroups.com
Subject: Re: [ihe-hpd-implementors:374] Digest for ihe-hpd-im...@googlegroups.com - 1 update in 1 topic
 

 
While the comments I have seen are true, there are concepts and history that are not understood very well and others that are developmental. The fact that one can store a certificate in the DNS is true, but there were a lot of discussions on whether it made any practical sense. In fact in practical testing I found operational HISPs that had both valid and invalid certificates in the DNS.
 

 
That is because there is very weak binding between a domain name and identity. Anyone can stick a certificate in the DNS and claim that belongs to a specific organization as a point of contact. Also the decision was made not to sign the Domain name with digital signatures as a requirement using DNS security (DNSSEC)
 

 
Then to further break the security model the Direct transport model qua endpoints with *.* possible connections as it was originally designed became SMTP between HISPs only as a business, not standards or protocol specification model based on applicability statement one (AS1).
 

 
We now know why that happened and it has nothing to do with the standards or the complications in adopting a specific schema like HPD or HPD plus.
 

 
Bear in mind that organizations like NASA and the Nuclear Labs and NATO had been sending encrypted email using certificates just fine since 1996 using existing schema attributes so when Direct embraced DNS and seemed about to reject LDAP entirely a compromise was brokered to use either since I would not accept DNS only.
 

 
Along at the same time came the idea of broadening the concept of a defined service endpoint in the schema in which Direct would be one possibility.
 

 
Now to the larger picture since it gets muddy when talking about specific schema attributes. In the development of the standards, in which I played a role in defining how LDAPv3 stores binary objects like certificates, historically if you don't understand the history of X.500 and X.509 plus RFC 5280 plus the ISO description of a provider directory prior to HPD which dates back to 1988 why you put the information in 3 places has no context.
 

 
First of all one has to understand LDAP as it is defined.
 

 
Then one has to understand how LDAP is defined by IETF and not Direct and certainly not Direct Trust, or the redefinition of what we did in S&I by modular specifications which ran with ONC's encouragement as a circa 2000 novel approach with extending LDAP with federation between databases using LDIF repurposed as DSML using XML to work between those databases. That was never part of the S&I Provider Directory IG or discussed so of course the code forked. What was discussed was accommodating some of Direct's participants who had specific implementations using DNS.
 

 
Then if you understand what and why X.500 and the relationship to X.509 versions 1 to version 3 in relation to certain attributes in the certificates then there should be an aha moment where it's obvious how that works to remove any confusion and what role HPD or HPD+ plays and what makes sense when asking questions about national requirements. As one delves deeper it becomes evident that one is dealing with an alternative structure, not wrong per se, just tailored to suit the interests of database vendors and the EHRs that use those databases instead of the Internet standards (which are defined by loose consensus and running code) combined with ISO standards. That said, and I think Karen will back me up on this. IHE does not write "standards" Neither did S&I, however the mod spec group does not feel they operate under those constraints when they repurposed DSML, or did Direct when they went across the grain to use an obscure RFC to justify putting certificates in the DNS for business rather than technical reasons.
 

 

 

 

 
 
On Friday, April 3, 2015, <ihe-hpd-im...@googlegroups.com> wrote:
 
 
<https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/ihe-hpd-implementors/topics> ihe-hpd-im...@googlegroups.com
 
<https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> Google Groups
 
<https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview>
 
Topic digest
<https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/ihe-hpd-implementors/topics> View all topics
 
· [ihe-hpd-implementors:369] Attribute for the Direct address - 1 Update
 
<http://groups.google.com/group/ihe-hpd-implementors/t/16b4d4b4e600f87a?utm_source=digest&utm_medium=email> [ihe-hpd-implementors:369] Attribute for the Direct address
 
 
matthew...@esacinc.com <javascript:_e(%7B%7D,'cvml','matthew...@esacinc.com');> : Apr 02 12:45PM -0700
 
Hello. I worked on the PDTI project (link to the github project above),
which understood the hpdServiceAdress to be the place where a Direct
address would go. In fact, any electronic service address would go in
there, whether it is a Direct address, a CONNECT endpoint, or anything
else. That is why it is a URI. The mail attribute for individual
provider/HPDProvider is an artifact of the LDAP underpinnings of the data
model (it comes from the LDAP InetOrgPerson and how the HPDProvider was
built up from existing LDAP objects) and was not intended to hold the
Direct address. Both Organizations (aka HPDOrganization) and Individuals
(HPDProvider) can own Direct addresses (as noted above) and the
HPDElectronicService object holds that information, and this is why both of
those provider objects point to any number of HPDElectronicService objects.

The Certificate Discovery IG was also mentioned. The Direct Cert Discovery
process is completely separate from getting certificates and endpoint
information in HPD. In Cert Discovery, one must already know the direct
address to which they wish to send information. Direct Cert Discovery was
designed to be a process by which one could find a public key certificate
by knowing ONLY the Direct address, and not other demographic information

HTH, Matt
 
Back to top
 
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/ihe-hpd-implementors/join> group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to ihe-hpd-implemen...@googlegroups.com <javascript:_e(%7B%7D,'cvml','ihe-hpd-implementors%2Bunsu...@googlegroups.com');> .
 
--
You received this message because you are subscribed to the Google Groups "ihe-hpd-implementors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-hpd-implemen...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to ihe-hpd-implemen...@googlegroups.com.

Peter Bachman

unread,
Apr 8, 2015, 6:41:30 PM4/8/15
to Digest recipients
As a tl:dr followup, as a participant in the process that had already a working version based on the specifications (as voted on for consensus for Direct on the Wiki), as well as a alternative to Direct Trust in which I was a participant, but where there was no approach in which they could manage membership because of the HISP methodologies,  I was very interested to see the process outline on the JAMIA paper documented below.  It fails to acknowledge how the logical process described in terms of standards maturity could be and was  manipulated, (not exactly actually controversial but I was listening to your meetings in recordings where consensus was not reached).  There's actually fundamental disagreement on some major points which were identified in 2004 when ONC was enabled and were subsequently not resolved. The usual suspects, Dixie, John Halamka, etc.  wrote this.


On the face of it the paper as an intellectual exercise of software maturity to fulfill the legal requirements of the standards committee per the enabling legislation, it makes sense, but nothing like this ever really took place either for NWHIN or Direct from my experience since 2008.

That includes a great deal of complex technical requirements which I am sure the participants understand, but didn't see a solution to make it happen vis a vis Provider Directory enough to form a consensus. 

David Kibbe testified that he didn't think a provider directory was necessary for Direct, and during the Direct Boot Camp that David and I  both attended, as well as some of the people on this list, the number one most wanted feature for Direct was voted to be provider directory! Subsequently Direct Trust is investigating this and will likely come up with their own version that will pick out another obscure technology like LDIF using XML to exchange data. Those who are in the know regarding this, and have followed the entire process, know this goes back to the beginning of standards discussions regarding provider directory (which everybody agrees is a good thing) in which a fixed idea emerged out of MA that databases should be the logical connecting methodology as opposed to directories that already exist that could be joined together using LDAP. So the insistence to use DNS for certificates that match providers and all the arguments provided simply had to be sorted out. That's why we agreed to use both. 

To have Mod Spec rewrite the provider directory  architecture (and feel free to argue your approach as I am mine) was entirely out of scope for S&I, but supported by ONC. ONC rapidly began to bleed political capital when legislators found out the game they were playing. But HHS was clearly in a BIND (lol) to claim they were protecting patient security and data integrity, while at the same time exposing that same data with a solution at the business layer as opposed to a technical solution. Since some of those requirements are classified (not all of them) its only recently that we have the "return of the backdoor" policy position into the argument, but without a real risk analysis of what would happen if medical data was actually securely encrypted in transit over the network, not available to be decoded. This is where the IETF has taken a leadership position along with the other forms of Internet governance. In an odd turn of events, the Internet will be more secure than the Direct HISP model. Might take a while.

We don't have the equivalent of an ICANN for Directory because that was the agreement we did for E-Gov way back when, not to put it through the legal controversy over what authority in the root nameservers constitutes,  That is causing DNS to collapse under it's own greed. That and a few million dollars can buy your own TLD from an ever expanding list. In short the DNS means nothing, but it's still a useful service and you can keep renewing. OTOH, the ANSI organization registration for reference is here:


It costs about 2.5 K $, and the renewal fees for your registration. None. In perpetuity. Plus you get your own OID like HL7 has that lets you do all sorts of useful things. So far, most people choose the DNS. Then they try to apply security through certificates, which don't required the Directory, but if you have the Directory, you get a great deal of added value since they mesh so well together. And then you don't need to be a member of Direct Trust because as Farzad liked to put it, "It all just works" using the existing system. Even SSL certificates for web sites are going to be offered at zero cost soon through the EFF and partners. In short, while the Medical HIT community insists that they don't understand encryption in any depth and has to have a separate trust network that uses medical bits instead of internet packets, the Internet is moving towards ubiquitious encryption for everyone at low to no cost without having it managed by a service provider who have already demonstrated their vulnerabilities to crypto political pressure.

Nor as they were throwing around ideas in these standards meetings like "lets put all the structured data in Google" (yes that actually happened). Certainly interesting and worthwhile discussions, but for developers who need to write working software, the constraints are much more pragmatic to narrow down the solutions that can work.

This is what happens when you don't listen to your customers. HHS is not the customer, nor are the medical providers who are paying the bills for the software. The true customer is the patient/citizen and the cost comes out of the 18% of GDP that is currently being skimmed.  Since CMS is burnt for a big chunk of this, they are driving for certain requirements in regards to improving the integrity of the information. 

In 2004 when the ONC was created in the mold of a Health Tsar, to coordinate these things, the RFI had already been returned with one very specific takeaway to HHS.  That was "put this stuff on the Internet, and network it to make it accessible and lower costs"

Fine. 

As a result, the medical IT community did everything in its power to make that not happen because they felt that would result in a loss of power, and in some cases profits, but the value of transparency in the overall system, has been a very difficult path as they have attempted, and sometimes succeeded in not having to deal with the same pressures that faced the music industry for example. 

Think about MP3 for a minute, and who brought it out for the public.

Then consider that since Edison there were countless turf wars who controlled music, and films, and the distribution, radio, movie theaters, and the entire supply chain regarding Intellectual Property leading up to the payola scandals of the 1950's. Then things went digital.

 "And by the way, which ones Pink?" 

These are all things that have riled policy makers causing them to rethink their core ideas. 

All of a sudden supply chain takes on a new meaning. Interactivity, one of the keys to lowering health care costs, takes on a new meaning because it's already part of a highly customer focused commercial side of the Internet that feeds on itself in terms of innovation like a worm ouroboros. It's the fun of using Google, you never know when they will simply decide to dump something that didn't work out like they thought, and try something new.

But you and I know who wrote the code for Direct, and how that subsequently affected the any to any encryption paradigm by taking a detour to Web Services for the patient. That clearly satisfied the View part, but not the download and transmit part that allowed people to use the smart end devices (as opposed to hosted services)  to do analytics. No, it all had to happen via API to a cloud service (even that is still somewhat advanced and developmental) or just interacting with a Portal. 

So rather than do the logical thing which other  countries (did that didn't have the money to waste), we engaged in what Markle's Shirky and Diamond, (and to some extent the RAND corporation), called "Magical Thinking" regarding the cost savings power of the  MU1 EHR that was off the charts so to speak on the Gartner hype cycle enough to push the needle on quality measures and outcomes. 

What we did that was smart, was we didn't spend billions on consultants to design the system, after the UK NHS scandal that tanked CSC, and we instead used consultants in a more  intelligent way with a lot of community feedback. 

But from an architectural perspective the current thinking entirely surfaced in healthcare.gov, it's failure, and subsequent fixes.

And by 2014 when it was supposed to be wrapped up, it wasn't  due to conflicting requirements. So all of a sudden it's "we can't send this over an insecure network", but that's the basic point, you have to. The network has be deemed insecure as a given and one has to apply the technology that assumes it is insecure, and fix it.

The above JAMIA paper makes that clear at the outset that the medical community wants to build it's own national standards, for medical data, but ignores the fact they failed to really make that happen and that represents the crux of the problem.  There is no point in Dixie talking about SHA-1 versus SHA-2 being required for vendors because the reality on the ground is far more advanced. I spoke with NSF security experts who had been testing SHA-3 implementations on line, and they were getting SHA-3 signed content from attackers using a version of the standard that had not even been standardized. So while I am confident that the CAs and NIST can develop good infrastructure there are huge gaps like what we experienced with OpenSSL that are developmental because of these highly sophisticated attacks. Literally it was only one day that Heartbleed was made public before a VPN was penetrated by a Chinese AP team, and accessed the internal sever using SQL injection out of XKCD using admin credentials resulting in the breach of millions of records at CHS. The patch was installed that same day.

There is no encryption standard that is "healthcare specific", (certainly you have written about those that are acceptable)  there is just a series of mathematical techniques in which encryption can be proven to be work. There is no medical version of TCP-IP version 4 or version 6, there is no medical version of the Internet. 

But there are existing standards widely used which do fit the paper's model. And that's what should have and could have happened back in 2004 and did in other countries that  don't have different U.S. specific requirements that involve a heavy political calculus.

I would challenge anyone to find a widespread example of UDDI for web services except used by the original Connect model. I think the Direct Project learned from that example, to specify  a protocol that the Internet did not actually for that purpose, (DNS) but could use within a closed user group of HISPs that wanted to develop a business layer monopoly. I don't think there was an emergency to punt to Direct Trust, because I attended that meeting and presented my case, but there definitely was a policy level failure around the concepts floated by the HHS Policy group of nationally  verified entities. Be that as it may, the requirement still exists, and can be done.

Without addressing the potential of FHIR to update this all to the current API economy (which really would not have been possible back in 2004), there was a great deal of potential to improve the security of encryption on the Internet and we really didn't understand at the IETF level how broken it really was.  Now we do, and it's being fixed. I would say there are other paradigms dearly held by the standards committees, that don't really correspond to the "on the ground truth" which developers must face. But with MU3 requirements the developers will have to satisfy those requirements. 

And this is an area that is undergoing vast improvement. Fraunhofer just announced an all encompassing encryption initiative aimed at overcoming the barriers of individual use by making it easier to use. That means not sending your messages to a third party (in this case a HISP), who encrypts the message for you using Direct Applicability Statement to another HISP. While they don't come out and say they are using a national focused X.500/LDAP Directory, the integration with EID (which is a component of the PKI model)  makes me pretty much guess that's what they will use since they plan on using existing technology. What they are not saying is we need a way to Federate existing  LDAP Directories, which of course is a more attractive option to the vendors on this list that sell that product. Of course, you could also sell a product that references the X.500 model, since that was the intent of TC-215 in 1988 when they came up with the idea, the subsequent descriptions in: 







On Wed, Apr 8, 2015 at 1:44 PM, Peter Bachman <pbspamfi...@gmail.com> wrote:
I think Matt is correct in saying the use case for Certificate Discovery was constructed in the way that it was, but that was not intended to be a limitation but an implementation that would always work for Direct. The pros and cons of LDAP and DNS were widely discussed and whether Direct was trying to rule out the common desktop software capable of doing LDAP and not DNS certificate lookup. In fact that was exactly what they were doing although the Applicability Statement contradicts this. This is very different from a developer versus user perspective. As a developer I don't especially care, they both can handle the information but there is the issue that it's very large data to put in the DNS and has to be converted from base 64. Also ICANN is not going to be that helpful in this regard.

The fact that COTS doesn't do this is because it's not the regular way to do it not that it can't be done. The practical effect was to suddenly ditch the SMTP using S/MIME which did end to end encryption to a different security model using edge protocols where the data was exposed at the HISP.

That forced the HISPs to have BAA with signed with their customers to assign liability if they breached the information.

For provider directory there is a much richer set of selectors and thus can bind a certificate to the subject of the certificate and the rest of the attributes follow.

Once you get to a subject alternative name you no longer have that binding that's what's bound in the certificate, what is certified and the email address is not the only value that can go there.

On the Directory side the user certificate can be associated an entry and if one has done the c=, st= o=, ou=, with a valid DN that is unique and scaled to the US realm, the problem is solved, but requires a coordinated solution and as John has said, other countries have been able to pull this off.

The definition of Direct address as an endpoint to a service is a different idea to aid the sender with knowing what services are available and the values.
On Wed, Apr 8, 2015 at 5:09 AM <ihe-hpd-im...@googlegroups.com> wrote:
To unsubscribe from this group and stop receiving emails from it send an email to ihe-hpd-implementors+unsub...@googlegroups.com <javascript:_e(%7B%7D,'cvml','ihe-hpd-implementors%2Bunsu...@googlegroups.com');> .
 
--
You received this message because you are subscribed to the Google Groups "ihe-hpd-implementors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-hpd-implementors+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to ihe-hpd-implementors+unsub...@googlegroups.com.

Reply all
Reply to author
Forward
0 new messages