Visual Electronic Identities
The only open standard for an electronic Identification instrument is X.509 and the Internet profile of this standard, RFC 5280
While we have standardised some pretty impressive mathematic techniques to obtain the verified X.509 certificate we still lack the tools to display its content to a human user. No matter if I have the verified certificate of the signer of the software I’m about to install, or the owner of the website I just agreed to pay. I still can’t see who they really are.
Standard Certificate UI tools are not even close to provide any meaningful data for an uneducated user.
A major reason for this is that identification attributes contained in the certificate is labelled using standard attributes that lack necessary semantics. For example, the “Country” attribute (represented by “C = US” in the example above) is used to express a country associated with the subject, but there is no way to know what that means. Is this the country of citizenship, country of residence, country or establishment? Other attributes like SERIALNUMBER may range from containing a device serial number, a drivers license number, membership ID to a national civic registration code.
Another major reason is that there is no way for a generic UI application to know what ID attributes that are intended for machine processing and which attributes that are intended to be displayed to humans. The attributes suitable for display in a UI is often a subset of all ID attributes.
RFC 3709, published 2004 was a huge step closer to a solution by standardising a way to include logotypes in a certificate. Many efforts, though not sufficient to reach the masses, has been undertaken to implement this standard but also RFC 3709 has its shortcomings.
In its current form it provides a good framework to build on, but it leave too many unspecified choices to the UI module. RFC 3709 provide a way to associate a certificate with graphical logotypes of a common brand (the community logo), the issuer logo and the subject organisation logo. It still leaves the problem to adequately and accurately label and select the identity attributes suitable for visual representation of the eID.
A very simple solution to this problem could be to use the solution framework of RFC 3709, not only to associate logotypes, but to associate a complete and scaleable visual representation of the complete certificate, with localised labels, attribute values, logotypes, background image and colours as well as various colour schemes. One possible standard format for such visual representation of the certificate could be PDF, which itself is available as a standard. The visual representation of the certificate does not have to be stored in the certificate. Using the technique of RFC 3709, it could be provided as externally stored data where the certificate only contains a URI to the location of the image file together with a hash of the image file.
Through this solution to the problem, a standard UI application could simply download the visual representation of the certificate, validate it through the hash in the certificate and then display it to the user.
The security threat introduced here is that you are providing the CA with a chance to act dishonestly by providing conflicting data in text form and in visual form. A certificate could pass visual inspection looking at the visual image file and then be allowed to be used for automatic processing using the text based ID attributes, which now happens to represent a totally different entity.
There are two arguments against this threat.
The final advantage is that this methodology could allow localisation. If sufficient conventions are specified, e.g. in the naming of image files, it would be possible to provide choices, localised for different languages. For a Swedish eID, clients that use Swedish language settings in the local environment would download and show the Swedish version of the language file, while clients localised to other languages would download the English (default) version.
To accomplish this as a standardised methodology, only minor amendments to RFC 3709 are required.
While we have standardised some pretty impressive mathematic techniques to obtain the verified X.509 certificate we still lack the tools to display its content to a human user. No matter if I have the verified certificate of the signer of the software I’m about to install, or the owner of the website I just agreed to pay. I still can’t see who they really are.
Standard Certificate UI tools are not even close to provide any meaningful data for an uneducated user.
A major reason for this is that identification attributes contained in the certificate is labelled using standard attributes that lack necessary semantics. For example, the “Country” attribute (represented by “C = US” in the example above) is used to express a country associated with the subject, but there is no way to know what that means. Is this the country of citizenship, country of residence, country or establishment? Other attributes like SERIALNUMBER may range from containing a device serial number, a drivers license number, membership ID to a national civic registration code.
Another major reason is that there is no way for a generic UI application to know what ID attributes that are intended for machine processing and which attributes that are intended to be displayed to humans. The attributes suitable for display in a UI is often a subset of all ID attributes.
RFC 3709, published 2004 was a huge step closer to a solution by standardising a way to include logotypes in a certificate. Many efforts, though not sufficient to reach the masses, has been undertaken to implement this standard but also RFC 3709 has its shortcomings.
In its current form it provides a good framework to build on, but it leave too many unspecified choices to the UI module. RFC 3709 provide a way to associate a certificate with graphical logotypes of a common brand (the community logo), the issuer logo and the subject organisation logo. It still leaves the problem to adequately and accurately label and select the identity attributes suitable for visual representation of the eID.
A very simple solution to this problem could be to use the solution framework of RFC 3709, not only to associate logotypes, but to associate a complete and scaleable visual representation of the complete certificate, with localised labels, attribute values, logotypes, background image and colours as well as various colour schemes. One possible standard format for such visual representation of the certificate could be PDF, which itself is available as a standard. The visual representation of the certificate does not have to be stored in the certificate. Using the technique of RFC 3709, it could be provided as externally stored data where the certificate only contains a URI to the location of the image file together with a hash of the image file.
Through this solution to the problem, a standard UI application could simply download the visual representation of the certificate, validate it through the hash in the certificate and then display it to the user.
The security threat introduced here is that you are providing the CA with a chance to act dishonestly by providing conflicting data in text form and in visual form. A certificate could pass visual inspection looking at the visual image file and then be allowed to be used for automatic processing using the text based ID attributes, which now happens to represent a totally different entity.
There are two arguments against this threat.
- As a necessary security measure, only trusted CAs that qualifies as adequately trusted to provide separate visual information will be allowed to certify such data.
- Even if a trusted CA have the power to act dishonestly, which hardly is anything new, it can’t get away with it. Its crime will be signed and recorded for everyone to see.
The final advantage is that this methodology could allow localisation. If sufficient conventions are specified, e.g. in the naming of image files, it would be possible to provide choices, localised for different languages. For a Swedish eID, clients that use Swedish language settings in the local environment would download and show the Swedish version of the language file, while clients localised to other languages would download the English (default) version.
To accomplish this as a standardised methodology, only minor amendments to RFC 3709 are required.