Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt

From: Stefan Santesson <[email-masked]>
Date: Sat, 25 Apr 2009 09:41:56 +0200

All,

The first certificate image draft is now posted after an initial design
process.

http://tools.ietf.org/html/draft-santesson-pkix-certimage-00

This issue was presented at the IETF meeting in San Francisco. See minutes
at: http://tools.ietf.org/wg/pkix/minutes

Input to the initial design process, especially regarding image formats,
have been received from CA and browser vendors

As author I would like to request the PKIX WG to accept this as PKIX work
item.

/Stefan

On 09-04-24 12:30 AM, "[email-masked]" <[email-masked]>
wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> Title  : Internet X.509 Public Key Infrastructure: Certificate Image
> Author(s) : S. Santesson, R. Housley, S. Bajaj, L. Rosenthol
> Filename : draft-santesson-pkix-certimage-00.txt
> Pages  : 10
> Date  : 2009-4-21
> 
>    This document specifies a method to bind a visual representation of a
>    certificate in the form of a certificate image to a [RFC5280] public
>    key certificate by defining a new otherLogos image type according to
>    [RFC3709].
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-santesson-pkix-certimage-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 25 Apr 2009 17:44:14 +0200

I do in no way object to this as an IETF WG item, however, I would like
to point out that there is another work-in-progress that fulfills about the
same objectives, albeit in a rather different way.

This work-item is coined KeyGen2, and started as a universal credential
provisioning and management protocol, but recently morphed into something
which could be described as a unified credential solution for consumers with
USB sticks and mobile phones as the primary target containers.

Anyway, in KeyGen2 logotypes are linked to credentials not through
certificate extensions, but through an image "payload" during the
provisioning phase, which can be securely tied to the certificate.  Is there
any advantage with this one may wonder?  Maybe nothing earth-shattering,
but it does relieve CAs from *publishing* gazillions of personalized images.

The only disadvantage I can see is that the scheme is incompatible with
space-limited, single-issuer smart-cards but these are [IMHO] not that
interesting for this purpose since they typically already have a logotype
or something similar printed on the surface while the multi-issuer schemes
imposed by mobile phones really need logotypes.  In KeyGen2 the size
and type of a logotype is negotiated during the issuance phase.  This
negotiation also includes thumbprint versions to be used in credential
selection and management dialogs.

A preliminary version is currently available for testing on:
http://keycenter.webpki.org

Anders Rundgren

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Apr 2009 10:42:18 -0700

>As author I would like to request the PKIX WG to accept this as PKIX work

I think this is a terrible idea as a WG item, and even as an individual submission.

As a WG item:

- Note that only one person has supported the idea, even obliquely, since the request was posted.

- Given the extremely thin adoption of RFC 3709, it is inappropriate for the WG to take on a major extension to that RFC.

As an individual submission:

- This proposes that compliant PKIX validators need to include at least one complex image-display mechanism.  These mechanisms have been error-prone in the past, sometimes leading to the execution of arbitrary code on the host system. Forcing, or even suggesting, this be deployed as part of PKIX seems needlessly dangerous for very little value.

- The rationale from the introduction of the document for showing pictures instead of words is wrong. If you want to fix the words the user sees, fix the words, don't pretend that a picture it is sorta-kinda based on the current words but not really will lead to better security.

- "The previous RFC failed so now we want to extend it to make it more complicated" just sounds silly for a standard. The fact that it has been done in the IETF before doesn't mean we should make the same mistake again.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 01 May 2009 00:31:19 +0200

Paul,

> - Note that only one person has supported the idea, even obliquely, since the

First of all that is a premature assessment. Very little time has passed so
far.

Secondly you are wrong. This draft is supported also by the editors. That
makes it five. Only one person so far has voiced against.

> - Given the extremely thin adoption of RFC 3709, it is inappropriate for the
> WG to take on a major extension to that RFC.
> 

Thin adoption of RFC 3709 is not a problem at all. One of the problems with
just providing logotypes with 3709 is that the solution is incomplete. The
certificate image offers a complete solution.

The problem is important and need a solution. Building on RFC 3709 offers an
easy solution.

> - This proposes that compliant PKIX validators need to include at least one
> complex image-display mechanism.  These mechanisms have been error-prone in
> the past, sometimes leading to the execution of arbitrary code on the host
> system. Forcing, or even suggesting, this be deployed as part of PKIX seems
> needlessly dangerous for very little value.
> 

I don't understand the problem. We are talking about having the option to
display a signed image from a trusted source. As if that would be a lot more
dangerous than displaying images in your browser from untrusted sources.

> - The rationale from the introduction of the document for showing pictures
> instead of words is wrong. If you want to fix the words the user sees, fix the
> words, don't pretend that a picture it is sorta-kinda based on the current
> words but not really will lead to better security.
> 

I don't have to pretend. We have at least 3 image formats that is very well
suited to display a mix of text and graphics. The feature achieved is
usability more than security. To the extent security can benefit from a more
user friendly UI, this is also providing better security.

> - "The previous RFC failed so now we want to extend it to make it more
> complicated" just sounds silly for a standard. The fact that it has been done
> in the IETF before doesn't mean we should make the same mistake again.
> 
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 

Not at all. It is the total opposite. Just adding logotypes didn't make the
task to provide a understandable UI easy enough. So we need to make the
solution easier and complete.

A UI just using RFC 3709 would have to:
 - Decide where to place the logotypes on the screen relative to the text
 - Decide how to scale the images relative to each other and to the text
 - Come up with display text describing the content of each attribute
 - Decide which naming attributes and other names to display
 - Figure out how to serve the users language preferences with respect to
display text.

A UI using the certificate image in this new draft, can instead do the
following
 - Display the certificate Image

I would call that easier, not more complicated.

I would understand your violent disagreement more Paul, if you could offer
an alternative solution.

/Stefan

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Apr 2009 16:01:00 -0700

>First of all that is a premature assessment. Very little time has passed so

That is for the co-chairs to decide. Hopefully, you have recused yourself from this decision.

>makes it five. Only one person so far has voiced against.

There is a reasonable assumption in the IETF that all the co-authors on a draft support it. The question for WG adoption is whether *others* support the inclusion in the WG.

>Thin adoption of RFC 3709 is not a problem at all.

We disagree, strongly.

>One of the problems with

Which implementers have said "oh, if you only included Postscript, then we would have done 3709"?

>The problem is important and need a solution. Building on RFC 3709 offers an

We disagree, strongly.

>I don't understand the problem.

Clearly.

>We are talking about having the option to

To date, the CAs in the root pile have been trusted to issue certificates that reflect a proper binding between an end entity and a public key. There was some risk of them creating certificates with malicious formatting, but that was considered easy to detect. You are now proposing that those hundred of CAs be automatically trusted to format the art portions of their certificates correctly. That is a very different level of trust.

Even if a CA formats the certificate in a way they think is correct, there is a chance that the named party will have given them information that will cause the display mechanism to crash and possibly execute arbitrary code. That isn't possible today with any sensible ASN.1 parser.

>user friendly UI, this is also providing better security.

This does not explain why you don't try to just fix the problems that you claim are the base for this extension. No one *needs* pictures; they need accurate information about the identified party. That can be done in text, yes?

>I would call that easier, not more complicated.

You come from the assumption that logotypes are actually useful, not just (to use your terms) "user friendly" and based on "usability more than security".

>I would understand your violent disagreement more Paul, if you could offer

I already did that in the last message, but let me try again. If the problem is that the names in certificates are not right, fix them. Specify "display text describing the content of each attribute", "decide which naming attributes and other names to display", and "figure out how to serve the users language preferences with respect to display text". None of that takes graphics, much less more complicated graphics than has already failed.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 01 May 2009 01:56:17 +0200

Paul,

Skipping some..

On 09-05-01 1:01 AM, "Paul Hoffman" <[email-masked]> wrote:

> I already did that in the last message, but let me try again. If the problem
> is that the names in certificates are not right, fix them. Specify "display
> text describing the content of each attribute", "decide which naming
> attributes and other names to display", and "figure out how to serve the users
> language preferences with respect to display text". None of that takes
> graphics, much less more complicated graphics than has already failed.

No you did not, but here you do.

It is indeed an alternative solution to provide display text in all relevant
languages to each attribute in the certificate and in addition to that
define which attributes to display.

It's just a lot more complicated and does not offer the option to include
graphics.

Graphics is indeed not needed, but it can be really useful. Using a
certificate image does not necessarily equals use of graphics. An SVG or
PDF/A can provide pure text.

The client has full control over what it displays. If it doesn't trust the
CA to provide a certificate image, then it will not display it.

Note that this new draft is not doing anything that is not already allowed
through RFC 3709. It just specifies an OID for a new image type.

---

From: Karl Hess <[email-masked]>
Date: Thu, 30 Apr 2009 23:13:33 -0400

On Sat, Apr 25, 2009 at 03:41, Stefan Santesson <[email-masked]> wrote

> As author I would like to request the PKIX WG to accept this as PKIX work

I disagree that this should be a WG item.  I don't feel that it belongs in
the WG.

>
> /Stefan
>
>
>
> On 09-04-24 12:30 AM, "[email-masked]" <[email-masked]
> >
> wrote:
>

---

From: Jacob Dilles <[email-masked]>
Date: Fri, 1 May 2009 00:49:07 -0400

An image format will be necessary eventually; a company logo or  
credential owner ID photo that only appears in a GUI when the  
certificate signature and trust chain are validated is significantly  
more meaningful to 99% of "human" users than any text could ever be.  
The average SSL client, signed PDF viewer, or PA security guard, does  
not have the time, knowledge, or desire to decipher attributes from a  
DN.

The original internet was text based.. It's just a matter of time.

JSD

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 01 May 2009 07:39:01 +0200

On 09-05-01 5:13 AM, "Karl Hess" <[email-masked]> wrote:

> I disagree that this should be a WG item.  I don't feel that it belongs in the
> WG. 

Karl,

Just a clarifying question.

You are not telling me that something is wrong with the proposal, just that
it does not belong in the WG. But given that both RFC 3739 and 3709 are
products of PKIX, how does this NOT belong in this WG?

To clarify:
This WG produced RFC 3709, which specifies an extension where you can
reference images that supports certificate display.
The images already specified in RFC 3709 are:

- Community logo
- Issuer logo
- Subject logo
- Loyalty logo
- Background image

Another RFC from this WG, RFC 3739, defines how to reference 2 other images
to support certificate display.
- Picture of the Subject
- Image of subject¹s handwritten signature

This draft simply defines an OID for one more image type (certificate image)
to be referenced from the RFC 3709 extension.