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

From: Russ Housley <[email-masked]>
Date: Tue, 05 May 2009 09:03:17 -0400

Paul:

We clearly disagree.  I still believe that logotypes are needed to 
make useful user interfaces.  We have not seen logotypes take off in 
the marketplece, and I am hoping that the use of a single image 
instead of multiple images will remove an impediment.

Russ

At 07:01 PM 4/30/2009, Paul Hoffman wrote:

>At 12:31 AM +0200 5/1/09, Stefan Santesson wrote:
> >On 09-04-30 7:42 PM, "Paul Hoffman" <[email-masked]> wrote:
> > > - Note that only one person has supported the idea, even 
> obliquely, since the
> >> request was posted.
> >>
> >
> >First of all that is a premature assessment. Very little time has passed so
> >far.
>
>That is for the co-chairs to decide. Hopefully, you have recused 
>yourself from this decision.
>
> >Secondly you are wrong. This draft is supported also by the editors. That
> >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.
>
> > > - 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.
>
>We disagree, strongly.
>
> >One of the problems with
> >just providing logotypes with 3709 is that the solution is incomplete. The
> >certificate image offers a complete solution.
>
>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
> >easy solution.
>
>We disagree, strongly.
>
> > > 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.
> >>
> >
> >I don't understand the problem.
>
>Clearly.
>
> >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.
>
>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.
>
> > > - 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.
>
>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?
>
> > > - "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.
> > >
> >
> >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.
>
>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
> >an alternative solution.
>
>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: "Anders Rundgren" <[email-masked]>
Date: Tue, 5 May 2009 19:17:26 +0200

The *motive* is definitely good and worth pursuing.

What's less suitable is the idea of *publishing* an end-user's credential
selection images.  I would like to see some samples applied to eID or VISA
certificates.

Anders

----- Original Message ----- 
From: "Russ Housley" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 05, 2009 15:03
Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt

Paul:

Russ

---

From: Roberto Opazo <[email-masked]>
Date: Wed, 6 May 2009 12:59:30 -0400

Stefan

I also suport the idea of specifying 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].

I see two points here:

* RFC 3709 is already done, so we should choose between completing it
with support for a whole certificate image or revoking it. It’s easer
and consistent to complete the job.

* As a certificate provider, I think it’s very obvious the reason why
RFC 3709 has not been adopted, but that’s not the point jet. The
standard needs some browser support before any CA start using it.

Best regards,

Roberto Opazo

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 07 May 2009 12:17:31 +0200

Roberto,

I agree with what you say but would like to add one thing regarding
application support.

It used to be that the browsers were the critical application for showing
logotypes or a certificate image. However that has changed slightly.

EU member states continue to invest considerable resources to provide
services in electronic form, supported by national endorsed ID certificates,
supported by EU commission activities. The services directive, the action
plan for harmonizing e-signatuires and e-identification, the STORK project,
the PEPPOL project are some significant examples.

It is very common for these national infrastructures to provide a small
client software which provides the UI for authentication and signing.

This makes it possible to use a certificate image to support these services
regardless of browser support.

I have also talked to several providers of services and CAs in addition to
representatives from the EU commission and EU projects who are seriously
interested in using this feature regardless of the browsers.

I wouldn't be surprised to see browsers follow once they see the value in
local UI deployments.

/Stefan

On 09-05-06 5:59 PM, "Roberto Opazo" <[email-masked]> wrote:

> with support for a whole certificate image or revoking it. It¹s easer
> * As a certificate provider, I think it¹s very obvious the reason why
> RFC 3709 has not been adopted, but that¹s not the point jet. The

---

From: "Santoni Adriano" <[email-masked]>
Date: Thu, 7 May 2009 13:37:35 +0200

Stefan,

are you aware, to date, of any real world "certificate image" to look at as a good example of how a cert image should look? 

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Stefan Santesson
Inviato: giovedì 7 maggio 2009 12.18
A: Roberto Opazo
Cc: Paul Hoffman; Russ Housley; [email-masked]
Oggetto: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt

Roberto,

I agree with what you say but would like to add one thing regarding application support.

It used to be that the browsers were the critical application for showing logotypes or a certificate image. However that has changed slightly.

EU member states continue to invest considerable resources to provide services in electronic form, supported by national endorsed ID certificates, supported by EU commission activities. The services directive, the action plan for harmonizing e-signatuires and e-identification, the STORK project, the PEPPOL project are some significant examples.

It is very common for these national infrastructures to provide a small client software which provides the UI for authentication and signing.

This makes it possible to use a certificate image to support these services regardless of browser support.

I have also talked to several providers of services and CAs in addition to representatives from the EU commission and EU projects who are seriously interested in using this feature regardless of the browsers.

I wouldn't be surprised to see browsers follow once they see the value in local UI deployments.

/Stefan

On 09-05-06 5:59 PM, "Roberto Opazo" <[email-masked]> wrote:

>> What's less suitable is the idea of *publishing* an end-user's 
>> credential selection images.  I would like to see some samples 
>> applied to eID or VISA certificates.
>> 
>> Anders
>> 
>>>> 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.
>>> 
>>>> 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.
>>> 
>>> We disagree, strongly.
>>> 
>>>>> 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
>>>> 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.
>>> 
>>>>> 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
>>>> 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.
>>>> 
>>>> - 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
>>>> I would understand your violent disagreement more Paul, if you 
>>>> could offer an alternative solution.
>>>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 07 May 2009 13:57:13 +0200

The draft was published a few weeks ago so I don't know of any real world
implementations.

The certificate image may contain any mix of text and graphics.
It may for example look very similar to the ID in your wallet.

/Stefan

On 09-05-07 1:37 PM, "Santoni Adriano" <[email-masked]> wrote:

> 
> Stefan,
> 
> are you aware, to date, of any real world "certificate image" to look at as a
> good example of how a cert image should look?
> 
> Adriano
> 
> 
> EU member states continue to invest considerable resources to provide services
> in electronic form, supported by national endorsed ID certificates, supported
> by EU commission activities. The services directive, the action plan for
> harmonizing e-signatuires and e-identification, the STORK project, the PEPPOL
> project are some significant examples.
> 
> It is very common for these national infrastructures to provide a small client
> software which provides the UI for authentication and signing.
>

---

From: "Thomas Hardjono" <[email-masked]>
Date: Mon, 11 May 2009 09:59:21 -0400

Stefan, PKIX-folks,

I'd like to voice my support for this draft. Having worked for a large CA
for over 5 years and seeing such a low adoption rate for client-side certs,
I think anything to help the cause of cert adoption is worth pursuing. If
RFC3709/logotypes has had thin adoption, then perhaps its time to try this
approach.

/thomas/

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Stefan Santesson
> Sent: Thursday, May 07, 2009 7:57 AM
> To: Santoni Adriano
> Cc: [email-masked]
> Subject: Re: draft-santesson-pkix-certimage-00.txt: any example to date?
> 
> 
> > Da: [email-masked] [mailto:[email-masked]]
> Per
> > conto di Stefan Santesson
> services
> >>>>> - Decide where to place the logotypes on the screen relative to
> the
> >>>>> text