Subject: Re: [pkix] I-D Action:draft-ietf-pkix-certimage-06.txt

From: "Pope, Nick" <[email-masked]>
Date: Tue, 2 Mar 2010 13:16:26 -0000

Denis,

I disagree with what you say except with regards to the privacy implications
of dataURLs which warrants mention in the Security Considerations section.

Defining some new OIDs for DNs will only further add yet another choice to
the multiplicity of ways certificates can be interpreted.  It is very
unlikely that the number of existing implementations are going to adopt any
new DN forms.  Further fragmenting the solutions available is not what
standards should be doing.

The certimage provides a means for the CA to give relying parties and
signers a common way of visually representing a certificate in a consistent
and human understandable form.  It provides a way of extending existing CA
services without disrupting the existing usage of the DN.

If a CA's customers require their certified identity in a multi-lingual form
then they can request a certificate including all the necessary language
forms.

I see no need to place any further standardised requirements on the use of
languages.  The CA knows its users needs much better than us.  If a system
has multi-lingual support then it can make use of the language tag as
appropriate.

There is a potential threat that the visual representation and the DN data
is different if the CA acts in an non-trustworthy manner.  However, if there
CA is vulnerable to attack or misuse then there are other much greater risks
than this.

I do not think that the certimage standard should place any further
requirements on the use of 

      - Certificate Context
      - Certificate Issuer
      - Certificate Subject

The CA is best placed to identify the most appropriate use for the context
in which the certificate is being used.

I agree that the dataURL can have some privacy issues, particularly for
personal certificates used in the public domain.  This may warrant some
words in the Security Considerations section about the need to take steps to
avoid collection of personal identity information from repositories of
CertImage files holding information about natural persons (e.g. using URLs
with random elements which are sparsely populated)..

I do believe that the security advantages of this specification, in making
certificates more understandable to human users, far outweigh the risks.

Nick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Denis Pinkas
Sent: 02 March 2010 12:03
To: pkix
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-certimage-06.txt

One of the main arguments to explain the motivations behind this draft is to
complain 
about the "lack of well defined semantics for critical identity attributes".

In order to solve this complain, there is a much simpler solution 
which takes far less data in a certificate: simply define some additional
OIDs 
for the construction of a DN to make it more descriptive. In this way 
there cannot be any mismatch between the data representation and the visual 
representation and a different visual representation may be done for any
language 
supported by the relying party.

The major problem with the proposed solution is that human beings may be
able 
to interpret the visual representation ... only if they understand English.
See the example: "Civic Registration Number", "Country of Registration". 

Applications will be unable to understand the visual representation. 
As a consequence, there may be a difference between the data representation
and 
the visual representation. This means that CAs issuing visual
representations 
must be fully trusted not to fool relying parties. However, even if fully
trusted, 
since there is no guidance, nor rules, to make a "good" visual
representation: 
two CAs might choose the same visual representation for different meanings. 

Another problem that is not addressed is the language. On page 6 it can be
seen 
that the LogotypeImageInfo data structure allows the inclusion of a language
element. 
There is not a single explanation in the draft about its use. Suppose a
signer certificate 
is issued in China but used in Spain and in Italy, then how many languages 
should be supported? What would be the size of the certificate supporting
three languages? 
Would three languages be enough?

The use of new OIDs for constructing a DN does not have this kind of
problems, 
since these new OIDs would be locally interpreted in any language.

This draft mentions three different purposes as indicated on page 3:

1) identify a web service. Today, the only way to make sure to be connected 
to the right web server is to check the URI when in HTTPS mode. Is the
intent
to provide a new functionality by clicking once or more to get an image? 
How many end users will really do one or more clicks?

2) identify a signer. This seems the main motivation of the draft. 
As said above, using additional OIDs for constructing a DN solves the
problem much more nicely.

3) locally select the appropriate certificate, e.g. when a certificate store
contains 
several certificates for a user. In this case, a signer simply needs to know
who the issuer is. 
In many cases, the issuer will be different whether the certificate is
usable for private use 
or professional use. Otherwise looking at the DN will allow the signer
making the difference 
since at least, for professional use, there will be either an organization
component or 
an organization unit component with the name of a company or an organization
the signer belongs to. 
It is also important to note that in some cases the signer will sign
off-line. Hence the use 
of the data URL scheme which minimizes the size of the image does not apply.
Storing the image 
in the certificate will lead to store very large certificates in smart cards
where space is limited. 
As the example, the size of the image sent as an exemple converted into png
is 56 Kbytes: 
such an image cannot fit into a smart card. This is not a valid approach.

Other comments

On page 5 there is a MUST condition: 

" When present the Certificate Image MUST represent a complete visual
representation of the 
certificate ... that the issuer subjectively defines as relevant at least
the following 
three aspects of the certificate:

      - Certificate Context
      - Certificate Issuer
      - Certificate Subject".

Since this is subjective, interpretations will be necessarily different. 

What is relevant for case 3) above is not relevant for case 1) above.

The image MUST contain ALL the elements which makes a SINGLE representation
and will lead 
to very large images. This is not acceptable.

If, as indicated, this becomes is the only visual representation, the
application will not 
allow anymore the end-user to see the real content of a certificate. This is
not acceptable.

Page 6. The use of the OPTIONAL language element is not explained. If used,
what should it contain? 
How should a relying party use this field, if it is present?

Page 7. The use of the dataURL scheme leads to privacy considerations which
are not addressed in the draft.
Usually, certificates for human beings are not published on the Internet but
are communicated 
at the will of the certificate owner.

Since the URL of the dataURL scheme will be accessible over the Internet,
some people might try 
to guess these URLs and retrieve the certificate images. This is not a major
problem for web servers, 
but it is for human beings. The security considerations section is silent
about this concern.

Page 8. The note of page 8 is the following:

   Note: Implementations need to be cautious about the the size of
         images included in a certificate in order to ensure that the
         size of the certificate does not prevent the certificate to be
         used as intended.

It does not solve the issue. It also hides the fact that multiple images
would be needed 
in different languages and for different purposes (e.g. case 3 would need a
much smaller 
image than case 2) which makes the problem even worse.

Nowhere the document is saying that CAs MUST verify that the certimage
matches 
with the content of the certificate.

Since CAs will add semantics to the content of the certificate, there is no
guarantee 
that the semantics added by one CA will be comparable with the semantics of
another CA.

For all these reasons, I am not in favor for going ahead with this draft.

Denis

Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email [email-masked].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited".

---

From: "Bajaj, Siddharth" <[email-masked]>
Date: Tue, 9 Mar 2010 20:10:30 -0800

Hi Denis,

The way PKI technology and systems are designed; the
clients/users/relying parties need to trust the Issuing CA, Root CA and
the organizations behind those CAs. Even today, the semantics of the
data that is included in the certificate is completely up to the Issuing
CA. And for that matter whether and how the data is verified. 

The semantics of the information included in the certificate is
typically spelled out in the CP/CPS documents and if the CA is not
responsible and does not do a good job of operating per what it claims
in the CP/CPS documents then they risk their reputation and business. I
see this as no different. We are only enabling the syntax to enable CAs
to include the certificate image in the certificates.

The semantics of the certificate image will be spelt out by the CAs in
the individual CP/CPS documents or it is possible that a consortium or
an organization can specify requirements for a group of CAs, for e.g.
the EV guidelines by the CA/Browser Forum. 

As I mentioned in my previous email on this topic, VeriSign has been
implementing certificate UX that include similar 'card-like' visual
metaphors for X.509 certificates for over 10 years. This particular
draft/RFC will help provide us with a building block to enable the next
generation PKI UX based on open standards. 

Thanks,

Siddharth

---

Siddharth Bajaj

Principal Engineer, 

VeriSign Labs.

[email-masked]

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pope, Nick
Sent: Tuesday, March 02, 2010 5:16 AM
To: [email-masked]'; pkix
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-certimage-06.txt

Denis,

I disagree with what you say except with regards to the privacy
implications of dataURLs which warrants mention in the Security
Considerations section.

Defining some new OIDs for DNs will only further add yet another choice
to the multiplicity of ways certificates can be interpreted.  It is very
unlikely that the number of existing implementations are going to adopt
any new DN forms.  Further fragmenting the solutions available is not
what standards should be doing.

The certimage provides a means for the CA to give relying parties and
signers a common way of visually representing a certificate in a
consistent and human understandable form.  It provides a way of
extending existing CA services without disrupting the existing usage of
the DN.

If a CA's customers require their certified identity in a multi-lingual
form then they can request a certificate including all the necessary
language forms.

I see no need to place any further standardised requirements on the use
of languages.  The CA knows its users needs much better than us.  If a
system has multi-lingual support then it can make use of the language
tag as appropriate.

There is a potential threat that the visual representation and the DN
data is different if the CA acts in an non-trustworthy manner.  However,
if there CA is vulnerable to attack or misuse then there are other much
greater risks than this.

      - Certificate Context
      - Certificate Issuer
      - Certificate Subject

The CA is best placed to identify the most appropriate use for the
context in which the certificate is being used.

I agree that the dataURL can have some privacy issues, particularly for
personal certificates used in the public domain.  This may warrant some
words in the Security Considerations section about the need to take
steps to avoid collection of personal identity information from
repositories of CertImage files holding information about natural
persons (e.g. using URLs with random elements which are sparsely
populated)..

I do believe that the security advantages of this specification, in
making certificates more understandable to human users, far outweigh the
risks.

Nick

-----Original Message-----

One of the main arguments to explain the motivations behind this draft
is to complain 
about the "lack of well defined semantics for critical identity
attributes". 

In order to solve this complain, there is a much simpler solution 
which takes far less data in a certificate: simply define some
additional OIDs 
for the construction of a DN to make it more descriptive. In this way 
there cannot be any mismatch between the data representation and the
visual 
representation and a different visual representation may be done for any
language 
supported by the relying party.

The major problem with the proposed solution is that human beings may be
able 
to interpret the visual representation ... only if they understand
English.
See the example: "Civic Registration Number", "Country of Registration".

Applications will be unable to understand the visual representation. 
As a consequence, there may be a difference between the data
representation and 
the visual representation. This means that CAs issuing visual
representations 
must be fully trusted not to fool relying parties. However, even if
fully trusted, 
since there is no guidance, nor rules, to make a "good" visual
representation: 
two CAs might choose the same visual representation for different
meanings. 

Another problem that is not addressed is the language. On page 6 it can
be seen 
that the LogotypeImageInfo data structure allows the inclusion of a
language element. 
There is not a single explanation in the draft about its use. Suppose a
signer certificate 
is issued in China but used in Spain and in Italy, then how many
languages 
should be supported? What would be the size of the certificate
supporting three languages? 
Would three languages be enough?

1) identify a web service. Today, the only way to make sure to be
connected 
to the right web server is to check the URI when in HTTPS mode. Is the
intent
to provide a new functionality by clicking once or more to get an image?

3) locally select the appropriate certificate, e.g. when a certificate
store contains 
several certificates for a user. In this case, a signer simply needs to
know who the issuer is. 
In many cases, the issuer will be different whether the certificate is
usable for private use 
or professional use. Otherwise looking at the DN will allow the signer
making the difference 
since at least, for professional use, there will be either an
organization component or 
an organization unit component with the name of a company or an
organization the signer belongs to. 
It is also important to note that in some cases the signer will sign
off-line. Hence the use 
of the data URL scheme which minimizes the size of the image does not
apply. Storing the image 
in the certificate will lead to store very large certificates in smart
cards where space is limited. 
As the example, the size of the image sent as an exemple converted into
png is 56 Kbytes: 
such an image cannot fit into a smart card. This is not a valid
approach.

Other comments

" When present the Certificate Image MUST represent a complete visual
representation of the 
certificate ... that the issuer subjectively defines as relevant at
least the following 
three aspects of the certificate:

      - Certificate Context
      - Certificate Issuer
      - Certificate Subject".

The image MUST contain ALL the elements which makes a SINGLE
representation and will lead 
to very large images. This is not acceptable.

If, as indicated, this becomes is the only visual representation, the
application will not 
allow anymore the end-user to see the real content of a certificate.
This is not acceptable.

Page 6. The use of the OPTIONAL language element is not explained. If
used, what should it contain? 
How should a relying party use this field, if it is present?

Page 7. The use of the dataURL scheme leads to privacy considerations
which are not addressed in the draft.
Usually, certificates for human beings are not published on the Internet
but are communicated 
at the will of the certificate owner.

Since the URL of the dataURL scheme will be accessible over the
Internet, some people might try 
to guess these URLs and retrieve the certificate images. This is not a
major problem for web servers, 
but it is for human beings. The security considerations section is
silent about this concern.

It does not solve the issue. It also hides the fact that multiple images
would be needed 
in different languages and for different purposes (e.g. case 3 would
need a much smaller 
image than case 2) which makes the problem even worse.

Since CAs will add semantics to the content of the certificate, there is
no guarantee 
that the semantics added by one CA will be comparable with the semantics
of another CA.

For all these reasons, I am not in favor for going ahead with this
draft.

Denis

"Thales e-Security Limited is incorporated in England and Wales with
company registration number 2518805. Its registered office is located at
2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr.
Weybridge, Surrey KT15 2NX.

The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access
to it by any other person is unauthorised. If you are not an addressee
or the intended addressee, you must not disclose, copy, circulate or in
any other way use or rely on the information contained in this e-mail.
Such unauthorised use may be unlawful. If you have received this e-mail
in error please delete it (and all copies) from your system, please also
inform us immediately on +44 (0)1844 201800 or email
[email-masked]. Commercial matters detailed or referred
to in this e-mail are subject to a written contract signed for and on
behalf of Thales e-Security Limited".