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

[Roberto Opazo <[e-mail]>]

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

2009/5/5 Anders Rundgren <[e-mail]>:
>
> 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" <[e-mail]>
> To: "Paul Hoffman" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Tuesday, May 05, 2009 15:03
> Subject: Re: I-D ACTION:draft-santesson-pkix-certimage-00.txt
>
>
>
> 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" <[e-mail]> 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
>
>