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

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 2 Mar 2010 13:03:02 +0100

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

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 02 Mar 2010 14:35:12 +0100

Hi Denis,

Comments in line.

/Stefan

> supported by the relying party.

This does not work as a replacement.

1) It is not backwards compatible. Certificate using systems are coded to
expect certain attributes and the use of attributes are locked into
international and national standards.

2) Many required attributes are national or local attributes that can't be
defined by the IETF

3) Attribute OIDs does not communicate any display metadata that can be used
by a UI. The attribute OID is just numbers and the UI have no way to
translate the OID to a meaningful UI representation.

4) Attribute OIDs can't provide any image information or any other elements
of visual design which is critical to provide a consistent user experience
across platforms.

> See the example: "Civic Registration Number", "Country of Registration".

This is not true. This example is provided in English, but could as well be
provided in French.

> Applications will be unable to understand the visual representation.

True, applications are not intended to process images in any other way than
to simply display them when appropriate.

> must be fully trusted not to fool relying parties.

Yes, which it need to be anyway. The good thing is that the CA will have to
sign the certificate so if it issues conflicting certificates to fool
relying parties, it will pretty soon be out of business.

> However, even if fully trusted,
> There is not a single explanation in the draft about its use.

If you read on the first line, you will see that this structure is defined
in RFC 3709 which contains the discussion of how to represent the same
information under different languages.

> Suppose a signer 
> certificate 

The CA free to choose how many languages it want to support and also which
of the language variants that are provided as embedded or externally stored
images.

Even if a large number of languages are supported, the certificate size can
remain small.

> Would three languages be enough?

That is up to the CAs to decide.

> since these new OIDs would be locally interpreted in any language.

OIDs do not provide any display metadata in any language.

> How many end users will really do one or more clicks?

This is not a substantiated claim. I'm mostly interested to know who the
actual service provider is.

It is up to web browsers, CAs and OS platforms to come up with clever UI
tools and design. It is not the intent of this standard to do UI design.

> As said above, using additional OIDs for constructing a DN solves the problem

As said above, OIDs do not provide any solution to the targeted problem.

> an organization unit component with the name of a company or an organization

Which is defeated by the very example I provided. Public CAs operating on a
national level in EU today provide data in organizational attributes that
has nothing to do with belonging to that organization.
 
> such an image cannot fit into a smart card. This is not a valid approach.

That same image takes 2k in svgz

It's not reasonable to prevent use of images 2010 because they take to much
memory. I'm not sure how old SmartCard technology you are trying to use.

The concept of caching is a great tool for off-line situations  when the
images are provided as external references,

> ³ 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 
>       - Certificate Subject².

True, The key is that it is a complete representation in the sense that it
is meaningful to display on its own. Your ID-card in your wallet also always
looks the same no matter what you use it for. That provides consistency.
Same thing here.

> to very large images. This is not acceptable.

Not at all. The attached example shows that it does not need to be very
complex or large. 

> allow anymore the end-user to see the real content of a certificate. This is

There is nothing in this document that prevents application from allowing
the users to examine the content of the certificate.

> Page 6. The use of the OPTIONAL language element is not explained. If used,

This structure is imported from RFC 3709. It specifies the language used to
present information.

> How should a relying party use this field, if it is present?

A UI would try to match the user's local language preferences by selecting
the image that offers the most suitable language.

> but it is for human beings. The security considerations section is silent

Yes, it makes sense to add a sentence on this issue in the security
considerations section.

> It does not solve the issue.

There is no issue to solve. The CA has a number of options. The most
conservative option is to not store images in the certificate at all.

> It also hides the fact that multiple images would
> be needed 

It does not hide any fact. It simply states that the CA need to be cautious
about size.

> that the semantics added by one CA will be comparable with the semantics of

All information provided by the CA need to be correct. That is in the nature
of being a CA and the reason people will trust it.

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix