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
RSS Feed