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

[Paul Hoffman <paul.hoffman@xxxxxxxx>]

At 12:31 AM +0200 5/1/09, Stefan Santesson wrote:
>On 09-04-30 7:42 PM, "Paul Hoffman" <paul.hoffman@xxxxxxxx> 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