Re: [ihe-hpd-implementors:372] Digest for ihe-hpd-implementors@googlegroups.com - 1 update in 1 topic

[Peter Bachman]

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:

ihe-hpd-im...@googlegroups.com

Google Groups

Topic digest
View all topics

• [ihe-hpd-implementors:369] Attribute for the Direct address - 1 Update

[ihe-hpd-implementors:369] Attribute for the Direct address

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 group membership page. To unsubscribe from this group and stop receiving emails from it send an email to ihe-hpd-implemen...@googlegroups.com.

[Moehrke, John (GE Healthcare)]

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

--
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.