potential use of openPGP in openEHR

Technical (archive)
1

An initial suggestion (currently in the Release 1.0.1 candidate drafts) is that openPGP should be used in openEHR for generating digests and signatures. openPGP is defined at http://www.ietf.org/rfc/rfc2440.txt and a lot of other information can be found at http://www.pgpi.org/ , http://www.gnupg.org/ .

My proposal is that the openPGP message specification makes sense for defining signature and hash values in openEHR because openPGP fully defines the result string ("message"), and allows for a wide choice of algorithms. It is also nice in that the result can be a single string, and is self-describing - i.e. decoding software can just read the string to find out what algorithms were used, and apply them. ASCII armoring and radix-64 encoding mean that "safe" strings can be generated.

However, we also have to be mindful of how it can be implemented in all major OSs and languages. Gnu GPG is one approach, but I don't have any direct experience of it.

Currently, hashing and signing are completely optional in openEHR (probably they will always be). But I believe we need to support them clearly in the openEHR architecture for those users that do want them. I also believe that we need to specify an open standard for hashing and signing and related security things.

Lastly, the use of such security algorithms interacts with the notion of key certication and a PKI. My understanding is that openPGP does not force users into any particular model of key management (even if the PGP distributed model might be easiest to itegrate). Do others have experience with openPGP within a PKI?

- thomas beale

2

We have been using Gnu GPG to sign and encrypt clinical reports (HTML and
PDF files) before storing them on a central repository. The reports
integrity is checked each time someone asks to see a report. Our hospital
repository has more than 1.500.000 reports.

Hope this information helps.

3

However, we also have to be mindful of how it can be implemented in all major OSs and languages. Gnu GPG is one approach, but I don’t have any direct experience of it.

As far as I understood, the current Italian law on digital documents puts PGP/GPG on the weak side of digital signatures, following european directives. You have strong signatures when you have a certification infrastructure, where certification authorities fulfill some legal constraints. PGP/GPG is more on a social certification method.
It is not matter of technicaal security, which is the same. Weak signature can be of legal value, but depends on the judge if used against someone. Strong signature has legal value. All this, more or less: it is difficult to understand laws language.
This ends up in the need of using other methods for legally valid EHR, and I do not think is wise to be tied to a specific system (better to choose just a format for signature, if there is the need for that).

Regards,

Vincenzo

4

Vincenzo Della Mea wrote:

However, we also have to be mindful of how it can be implemented in all major OSs and languages. Gnu GPG is one approach, but I don't have any direct experience of it.

As far as I understood, the current Italian law on digital documents puts PGP/GPG on the weak side of digital signatures, following european directives. You have strong signatures when you have a certification infrastructure, where certification authorities fulfill some legal constraints. PGP/GPG is more on a social certification method.

I think this is true if PGP is specified as the certification infrastructure. We are not trying to do that here - just use the openPGP message specification to define the format of signature strings etc in openEHR data. I don't think openEHR should be specifying anything in terms of certificates, PKI, certainly not at this stage of the game.

It is not matter of technicaal security, which is the same. Weak signature can be of legal value, but depends on the judge if used against someone. Strong signature has legal value. All this, more or less: it is difficult to understand laws language.
This ends up in the need of using other methods for legally valid EHR, and I do not think is wise to be tied to a specific system (better to choose just a format for signature, if there is the need for that).

but if we say that openEHR data can only be signed if the user has a public key certificate, then we immediately limit the use of signing (and hashing) to environments where certificate servers and processes etc exist.

Let me pose the question another way:

* what standard or other open specification can openEHR point to that accurately specifies the format of digital digests and signatures of EHR data? It has to be something avalable to everyone, and implementable (preferably already implemented)?

- thomas beale

5

Thomas Beale wrote:

>>* what standard or other open specification can openEHR point to that accurately specifies the format of digital digests and signatures of EHR data? It has to be something avalable to everyone, and implementable (preferably already implemented)?<<

openPGP seems a reasonable place to start. I have also had some experience with the GPG implementation, and have found it useful, versatile and usable, but...

Vincenzo Della Mea wrote:

However, we also have to be mindful of how it can be implemented in all major OSs and languages. Gnu GPG is one approach, but I don't have any direct experience of it.

As far as I understood, the current Italian law on digital documents puts PGP/GPG on the weak side of digital signatures, following european directives. You have strong signatures when you have a certification infrastructure, where certification authorities fulfill some legal constraints. PGP/GPG is more on a social certification method.

Thomas Beale wrote:

>>I think this is true if PGP is specified as the certification infrastructure. We are not trying to do that here - just use the openPGP message specification to define the format of signature strings etc in openEHR data. I don't think openEHR should be specifying anything in terms of certificates, PKI, certainly not at this stage of the game.<<

... I agree with Tom on this point - it would be far too soon to get into these details. I think that we will need to be open minded on the entire area for now, and watch various initiatives - PKI and certification are under a lot of scrutiny from both an engineering and usability perspective in terms of various e-Science projects in the UK within the security space - see http://portal.acm.org/citation.cfm?id=1090417&dl=GUIDE&coll=GUIDE&CFID=15151515&CFTOKEN=6184618 - while this is relevant to grid security in particular, you may agree that there are general issues regarding the use of PKI and so forth within the openEHR context.

With best wishes,

Nathan

6

Thomas Beale wrote:

Let me pose the question another way:

* what standard or other open specification can openEHR point to that
accurately specifies the format of digital digests and signatures of EHR
data? It has to be something avalable to everyone, and implementable
(preferably already implemented)?

Surely one (or more) of the X.509 pkix RFCs covers this? See
http://www.ietf.org/html.charters/pkix-charter.html

Or the very widely used and implemented RSA Labs PKCS "standards" - see
http://en.wikipedia.org/wiki/PKCS

And I dare say that the openSSL library implements whichever one of
these standards is relevant. Sorry, no time to research exactly which
standard you should look at, and its not the sort of information I like
to have hanging around in my cranium (if I can help it).

PGP/GPG is fab but mention it is not "enterprise-friendly" - mention it
in any large corporate setting and the IT people will wrinkle their
noses and claim not to have heard of it or mutter disparaging remarks
about hackers who ought to be in gaol. Whether they would react the same
way to the mere use of a GnuPG signature format is another question, but
if you mention X.509, PKCS or pkix compliance then there will be nods
and smiles all round from the corporate IT guys.

Tim C

7

Tim Churches wrote:

Thomas Beale wrote:
  

Let me pose the question another way:

* what standard or other open specification can openEHR point to that
accurately specifies the format of digital digests and signatures of EHR
data? It has to be something avalable to everyone, and implementable
(preferably already implemented)?
    
Surely one (or more) of the X.509 pkix RFCs covers this? See
http://www.ietf.org/html.charters/pkix-charter.html

Or the very widely used and implemented RSA Labs PKCS "standards" - see
http://en.wikipedia.org/wiki/PKCS
  

we might be discussing at cross purposes here Tim - at the moment, we want to achieve one very simple thing in openEHR: specify (by pointing to some published specification) the contents of digital signatures and hashes as we want to use them in openEHR (which is to say: in a completely orthodox fashion). My main concern is that there be a specification which shows how multiple encryption, hashing, compression etc algorithms can be used together in a reliable way, so that both encoder and decoder are guaranteed to be able to write and read the data, verify digests, authenticate authors and so on. So while there are all these standards for dozen well-known encryption algorithms, another dozen digital signature algorithms, various compression algorithms, etc etc, I believe we need to be able to say how they are all used together. openPGP seems to do a good job of this.

This issue of how to mechanically sign etc is one aspect of a full security infrastructure. Clearly, if there is digital signing with private and public keys, there needs to be key management and certification....all I want to recognise is that we should not (I don't think) solve both issues at once - we should solve them relatively independently - in other words, if all the e-Health programmes decide in 2 years time to go with some particular kind of PKI then we can do it, regardless of what choices we make now for digital signature. If we end up using X.509 certificates, great. But we still need a specification for the actual hashing and signing strings that get created and stored with the data or sent in messages.

It may be that we do need to have the debate about "how does openEHR integrate with PKI etc"; if so, my hope is that we can treat it relatively independently from the more basic subject above, allowing us to at least make the models security-enabled / aware without having to solve the PKI problem first.

And I dare say that the openSSL library implements whichever one of
these standards is relevant. Sorry, no time to research exactly which
standard you should look at, and its not the sort of information I like
to have hanging around in my cranium (if I can help it).

PGP/GPG is fab but mention it is not "enterprise-friendly" - mention it
in any large corporate setting and the IT people will wrinkle their
noses and claim not to have heard of it or mutter disparaging remarks
about hackers who ought to be in gaol. Whether they would react the same
way to the mere use of a GnuPG signature format is another question, but
if you mention X.509, PKCS or pkix compliance then there will be nods
and smiles all round from the corporate IT guys.
  

Sure - but as I have said before I don't believe that using openPGP message format (RFC2440) that we are advocating or pre-supposing any particular key management infrastructure (I am happy to be shown wrong...).

So - openPGP is a straw man option for interoperable signature and hash fields in data (there are only 2 or 3 in the whole reference model). What is the alternative? X.509 doesn't specify the way to sign things...

- thomas

8

Just to add something about the Italian law (maybe only to be sure
that it is too soon to get
into these details).

If you don't use a smartcard to make the signature in Italy, it does
not mean that the signature is not legaly valid: the judge will
decide! For eample, if you have previously signed an agreement that
states that the the signature is valid then the signature could be
valid.

Best
Roberto