Reference Implementation Meeting 2011-01-11
Jump to navigation
Jump to search
Status of Notes: Final
Date: January 11, 2011
Time: 12:00 EST
Attendees:
Beau -
Connect-a-thon debrief:
Went well, 5 HISPs including .NET and Java, Bare Metal for each and then some variations
More focus on outlier and negative case test cases than last time
Didn't quite get through full list on wiki, but made it through several
We did have things like expired certificates, certificate chains, intermediate certificates and chains that were missing pieces of the intermediate certificates
Also a focus on MDNs due to recent discussions of behavior, identified several problems, one was a mock version header on the Java side and some subject tweaks
ID'd 3-4 additional bugs with .NET around intermediate certificates, etc.
Several Java bugs also, MDN issue, and behavior around caching experienced with DNS.
Java DNS server demo on one of Beau's instances -- actually walked through the steps of setting up a DNS server for the certificate, before it was just pulling things from the web service configuration, now good to go with DNS server
Light testing with XD integration -- difficult to test that. Testing was done with XDM and relay testing, more needs to be done, but they did what they could.
Successful event.
Many .NET people are out today
Sri –
File size work - Umesh fixed that, good to go with sending larger files now. Still working on MDN.
Beau –
Umesh's updates - fixed most bugs found at Connect-a-thon, John was working on some setup things, John came back and said he would have very limited resources this week so he wasn't sure he'd get to it, Umesh working on additional tables and settings, etc., Sri working on Bare Metal and documentation things.
Sri –
We are working on console document, not complete yet
Beau –
Will try to get an XP update and see what help can be offered.
Java side, last week was prep for connect-a-thon, bug fixes and updated components, new assembly push-out through the repository
Greg –
Based off of connect-a-thon they're pushing out new assembly components, all the releases except XD for the connect-a-thon, yesterday the only issues were around MDN, agent was the only one with real issues. Agent 1.1.1 pushed out yesterday, latest stock assembly (Milestone 2, M2), updated to Google Code repository, that's the last milestone release he plans on, when we get the other XD pieces in the release that should become version 1.0., other fixes in release will be around DNS caching, having some issues on a couple flavors of UNIX, may be an issue with DNS Java. might have a fix. DNS 1.0.1 would get pushed out with final assembly
Beau –
We've got good documentation on DNS side, want more documentation similar to that of Bare Metal, quick start guide to put out on the wiki
Greg –
Sri asked a question about Bare Metal policies on certificates, from Bare Metal perspective it would be helpful to have documentation about generating root level certificates to get yourself going, one of the items on his side is pushing out documentation about about using CERT gen tool, nothing's been documented about using that tool to get started.
Beau –
That tool has been very helpful and has been updated.
Greg –
Expired certs can be backdated 10 days.
Sri –
In Bare Metal documentation on Java side it said that it's out of scope to cover the policies and certificates. We should add guidance about how to use this document.
Beau –
It was out of scope when the document was written, but now having ability for someone to quickly generate that would be a good idea.
Greg –
It was out of scope because of policy governance.
Sri –
How do we define a Bare Metal? Who is the audience for this document?
Beau –
Good question, originally it was taking an ECQ instance and setting up from scratch with little extra. So it's taking RI without enterprise email server or anything, but in a real world example that won't suffice, we want to encourage the use of email clients, etc.
Greg –
Excellent point. Bare Metal was never intended to be a production disc. There should be a disclaimer: Bare Metal, as is, probably doesn't meet HIPAA.
Arien –
This should be a starting point, not the destination point.
Will Hartung –
Shouldn't there be documentation on how it lacks?
Beau –
Good idea, we should work on that.
Will Hartung –
How it needs to improve for production and/or to meet HIPAA.
Beau –
XD bugs for Java side, no new bugs, but not a whole lot of testing at connect-a-thon, there is still a big list of things on the issue tracker. I will be out rest of this week and next week without resources. Looking for volunteers in this area. Other Java comments? [no]
During Java RI meeting: Discussion on HIPAA compliance last week came to a question of whether we were storing things on the file system in plain text, whether it would satisfy HIPAA or whether it needed to be encrypted in any way, etc. On .NET side it was whether SMTP server stores these as plain text. The James instance on Java side it gets a message and stores in plain text, probably not HIPAA compliant, what's it like on .NET side?
Arien –
I don't believe mail storage is included in .NET implementation. It's just a gateway.
Greg –
They are using Windows 2008 SMTP server as a gateway, but that's not doing storage?
Arien –
It might be doing transient mail storage.
Sri -
It stays there for a while, right?
Will Hartung –
Where does it eventually go for people to recover it via their mail client?
Arien –
It's going to back-end mail server.
Greg –
In .NET Bare Metal what are they using for that particular component?
Arien –
Back-end component is whatever the back end mail server is. Typically it will be Exchange, but it's gateway only.
Greg –
To some extent the Java RI can be looked at the same as if you go to some of the deployment models. Same concept of using James as a processing relay only, in Bare Metal we do package mail server with it, but again that gets back to the disclaimers. It's more of your starting point, not your destination.
Arien –
Most production instances will have just the gateway sitting on the DMT and the actual mail storage is going to be...
Greg –
It might be worth mentioning on the Bare Metal that this is starting, not destination. We should provide links to some of the deployment model docs, or there is a section on potential deployment models in ** book
Beau –
Great idea.
Arien –
Another way to put this is that if you don't have a Chief Security Officer or someone else managing security, infrastructure for HIE, just don't do this. A prerequisite for starting is that you have the processes and infrastructure in place to support secure health transfer.
Beau –
Great point. Other comments?
Greg –
For Arien, policy enforcement at the organizational level, gets back to OID and cross cert signing and some other pieces. Depending on where that goes we can get that into RI sooner or later. Anything to expand?
Arien –
That point was independent of whether you were doing cross-signing, and policy OIDs, that point was simply that the policies that we're pointing to out of the certification authority best practices, needs to include individual and organizational identity insurance. Has recommended to many people who are interested in implementing Direct and who are interested in exchange with VA that the only solution that they have is to get a federal bridge certificate. You cannot be in a common trust store or common trust circle with a federal partner if your certificate isn't a federal bridge certificate. The federal bridge certification authority comes with it cross-signing and OIDs. Critical piece is that at some point people will want to exchange with VA, and unless they get their certs set up just so, it won't work with federal bridge even though the certification is actually correct.
Greg –
Is there anything that needs to be done from the RI side to try to enforce those policies? Assuming that if the VA tried to take a RI they may have to make some tweaks to it anyway for HIPAA compliance, but still be able to take a RI and be able to do some policy enforcement or someone sends a signing certificate if it doesn't meet their policy...
Arien –
I have the opposite concern -- that a valid certificate will be rejected primarily because if your roots of trust aren't looking at the cross-signed roots of trust, you might fail. You may have a federal bridge root of trust and if somebody else is cross-signed with one another you might fail. My second concern is that you may have a certificate that is insufficient for HIE because it's at the remedial level of identity insurance. Worries about false positives and false negatives. Fix is for that is easy: for a given root of trust have a list of policy OIDs that you either rule in or rule out. Easier than cross-signing problem.
Greg –
Is this something we still need to look at for future releases of RI?
Arien –
So many people want to use this with VA that it does end up becoming a hard requirement.
Greg –
Where are we in terms of requirements? Is there a time frame for that?
Arien –
1 pilot involves VA, early to mid-2011 to be in production. Would like to target end of this quarter to meet those requirements. Hard requirements is OID verification. Doesn't know how you operationalize cross-signing and certificate chaining. Requirement on policy OIDs was to have configuration parameters that: require policy OIDs and constrain policy OIDs that are allowed.
Greg –
If that's the requirement, that's not a big deal. Should be handled easily -- it's just a matter of getting the requirements in place. Just needed to know if there are hard requirements, when they're coming, etc.
Arien –
We could reach out to somebody at Verizon for implementation guidance for federal bridge. Hasn't seen documents on implementing federal bridge requirements, but can reach out to them. Will hand contacts to Beau to tackle this.
Beau –
Thanks. Talk to you all next week.
Date: January 11, 2011
Time: 12:00 EST
Attendees:
Notes
Beau -
Connect-a-thon debrief:
Went well, 5 HISPs including .NET and Java, Bare Metal for each and then some variations
More focus on outlier and negative case test cases than last time
Didn't quite get through full list on wiki, but made it through several
We did have things like expired certificates, certificate chains, intermediate certificates and chains that were missing pieces of the intermediate certificates
Also a focus on MDNs due to recent discussions of behavior, identified several problems, one was a mock version header on the Java side and some subject tweaks
ID'd 3-4 additional bugs with .NET around intermediate certificates, etc.
Several Java bugs also, MDN issue, and behavior around caching experienced with DNS.
Java DNS server demo on one of Beau's instances -- actually walked through the steps of setting up a DNS server for the certificate, before it was just pulling things from the web service configuration, now good to go with DNS server
Light testing with XD integration -- difficult to test that. Testing was done with XDM and relay testing, more needs to be done, but they did what they could.
Successful event.
Many .NET people are out today
Sri –
File size work - Umesh fixed that, good to go with sending larger files now. Still working on MDN.
Beau –
Umesh's updates - fixed most bugs found at Connect-a-thon, John was working on some setup things, John came back and said he would have very limited resources this week so he wasn't sure he'd get to it, Umesh working on additional tables and settings, etc., Sri working on Bare Metal and documentation things.
Sri –
We are working on console document, not complete yet
Beau –
Will try to get an XP update and see what help can be offered.
Java side, last week was prep for connect-a-thon, bug fixes and updated components, new assembly push-out through the repository
Greg –
Based off of connect-a-thon they're pushing out new assembly components, all the releases except XD for the connect-a-thon, yesterday the only issues were around MDN, agent was the only one with real issues. Agent 1.1.1 pushed out yesterday, latest stock assembly (Milestone 2, M2), updated to Google Code repository, that's the last milestone release he plans on, when we get the other XD pieces in the release that should become version 1.0., other fixes in release will be around DNS caching, having some issues on a couple flavors of UNIX, may be an issue with DNS Java. might have a fix. DNS 1.0.1 would get pushed out with final assembly
Beau –
We've got good documentation on DNS side, want more documentation similar to that of Bare Metal, quick start guide to put out on the wiki
Greg –
Sri asked a question about Bare Metal policies on certificates, from Bare Metal perspective it would be helpful to have documentation about generating root level certificates to get yourself going, one of the items on his side is pushing out documentation about about using CERT gen tool, nothing's been documented about using that tool to get started.
Beau –
That tool has been very helpful and has been updated.
Greg –
Expired certs can be backdated 10 days.
Sri –
In Bare Metal documentation on Java side it said that it's out of scope to cover the policies and certificates. We should add guidance about how to use this document.
Beau –
It was out of scope when the document was written, but now having ability for someone to quickly generate that would be a good idea.
Greg –
It was out of scope because of policy governance.
Sri –
How do we define a Bare Metal? Who is the audience for this document?
Beau –
Good question, originally it was taking an ECQ instance and setting up from scratch with little extra. So it's taking RI without enterprise email server or anything, but in a real world example that won't suffice, we want to encourage the use of email clients, etc.
Greg –
Excellent point. Bare Metal was never intended to be a production disc. There should be a disclaimer: Bare Metal, as is, probably doesn't meet HIPAA.
Arien –
This should be a starting point, not the destination point.
Will Hartung –
Shouldn't there be documentation on how it lacks?
Beau –
Good idea, we should work on that.
Will Hartung –
How it needs to improve for production and/or to meet HIPAA.
Beau –
XD bugs for Java side, no new bugs, but not a whole lot of testing at connect-a-thon, there is still a big list of things on the issue tracker. I will be out rest of this week and next week without resources. Looking for volunteers in this area. Other Java comments? [no]
During Java RI meeting: Discussion on HIPAA compliance last week came to a question of whether we were storing things on the file system in plain text, whether it would satisfy HIPAA or whether it needed to be encrypted in any way, etc. On .NET side it was whether SMTP server stores these as plain text. The James instance on Java side it gets a message and stores in plain text, probably not HIPAA compliant, what's it like on .NET side?
Arien –
I don't believe mail storage is included in .NET implementation. It's just a gateway.
Greg –
They are using Windows 2008 SMTP server as a gateway, but that's not doing storage?
Arien –
It might be doing transient mail storage.
Sri -
It stays there for a while, right?
Will Hartung –
Where does it eventually go for people to recover it via their mail client?
Arien –
It's going to back-end mail server.
Greg –
In .NET Bare Metal what are they using for that particular component?
Arien –
Back-end component is whatever the back end mail server is. Typically it will be Exchange, but it's gateway only.
Greg –
To some extent the Java RI can be looked at the same as if you go to some of the deployment models. Same concept of using James as a processing relay only, in Bare Metal we do package mail server with it, but again that gets back to the disclaimers. It's more of your starting point, not your destination.
Arien –
Most production instances will have just the gateway sitting on the DMT and the actual mail storage is going to be...
Greg –
It might be worth mentioning on the Bare Metal that this is starting, not destination. We should provide links to some of the deployment model docs, or there is a section on potential deployment models in ** book
Beau –
Great idea.
Arien –
Another way to put this is that if you don't have a Chief Security Officer or someone else managing security, infrastructure for HIE, just don't do this. A prerequisite for starting is that you have the processes and infrastructure in place to support secure health transfer.
Beau –
Great point. Other comments?
Greg –
For Arien, policy enforcement at the organizational level, gets back to OID and cross cert signing and some other pieces. Depending on where that goes we can get that into RI sooner or later. Anything to expand?
Arien –
That point was independent of whether you were doing cross-signing, and policy OIDs, that point was simply that the policies that we're pointing to out of the certification authority best practices, needs to include individual and organizational identity insurance. Has recommended to many people who are interested in implementing Direct and who are interested in exchange with VA that the only solution that they have is to get a federal bridge certificate. You cannot be in a common trust store or common trust circle with a federal partner if your certificate isn't a federal bridge certificate. The federal bridge certification authority comes with it cross-signing and OIDs. Critical piece is that at some point people will want to exchange with VA, and unless they get their certs set up just so, it won't work with federal bridge even though the certification is actually correct.
Greg –
Is there anything that needs to be done from the RI side to try to enforce those policies? Assuming that if the VA tried to take a RI they may have to make some tweaks to it anyway for HIPAA compliance, but still be able to take a RI and be able to do some policy enforcement or someone sends a signing certificate if it doesn't meet their policy...
Arien –
I have the opposite concern -- that a valid certificate will be rejected primarily because if your roots of trust aren't looking at the cross-signed roots of trust, you might fail. You may have a federal bridge root of trust and if somebody else is cross-signed with one another you might fail. My second concern is that you may have a certificate that is insufficient for HIE because it's at the remedial level of identity insurance. Worries about false positives and false negatives. Fix is for that is easy: for a given root of trust have a list of policy OIDs that you either rule in or rule out. Easier than cross-signing problem.
Greg –
Is this something we still need to look at for future releases of RI?
Arien –
So many people want to use this with VA that it does end up becoming a hard requirement.
Greg –
Where are we in terms of requirements? Is there a time frame for that?
Arien –
1 pilot involves VA, early to mid-2011 to be in production. Would like to target end of this quarter to meet those requirements. Hard requirements is OID verification. Doesn't know how you operationalize cross-signing and certificate chaining. Requirement on policy OIDs was to have configuration parameters that: require policy OIDs and constrain policy OIDs that are allowed.
Greg –
If that's the requirement, that's not a big deal. Should be handled easily -- it's just a matter of getting the requirements in place. Just needed to know if there are hard requirements, when they're coming, etc.
Arien –
We could reach out to somebody at Verizon for implementation guidance for federal bridge. Hasn't seen documents on implementing federal bridge requirements, but can reach out to them. Will hand contacts to Beau to tackle this.
Beau –
Thanks. Talk to you all next week.