Subject: [pkix] WGLC for draft-ietf-pkix-certimage-03

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Dec 2009 13:55:45 -0500

Folks,

I'm initiating WGLC for this document, at the request of the author. 
It has been briefed at the last two IETF meetings and changes have 
been made in response to feedback received from the list.  The WGLC 
will close on December 18.

Thanks,

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Dec 2009 13:53:18 -0800

It is clear from the Security Considerations in this document that the risk of deploying this technology far outweighs the (mostly novelty) value. The WG has not come up with any good mechanisms for reducing the risks posed; therefore, I think this document should be abandoned by the WG.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 2 Dec 2009 17:01:08 -0500

I agree with Paul. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Hoffman
> Sent: Wednesday, December 02, 2009 4:53 PM
> To: [email-masked]
> Subject: Re: [pkix] WGLC for draft-ietf-pkix-certimage-03
> 
> It is clear from the Security Considerations in this document 
> that the risk of deploying this technology far outweighs the 
> (mostly novelty) value. The WG has not come up with any good 
> mechanisms for reducing the risks posed; therefore, I think 
> this document should be abandoned by the WG.
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 03 Dec 2009 15:18:57 +0100

Paul and Santosh,

This is not different in principle from other name forms already allowed in
PKI, or for that matter, what is already allowed by with RFC 3709.
There is nothing that stops a logotype image (e.g. The background image) to
provide the CA with the same potentially harmful ability.

Actually, this text in the security considerations section could as well be
deleted as it is accurately dealt with in RFC 3709, and this draft inherits
the security considerations in RFC 3709.

There is nothing that prevents a trusted CA from issuing certificates
containing fraudulent or conflicting information. This is generally
acceptable because:

1) We have functions through which we can select which CAs we trust and for
what purpose of usage we trust this CA to provide trusted assertions.

2) A CA signing fraudulent and conflicting information will be found out.
The crime is signed and there is no way to deny it. Such CA would go out of
business and get sued.

The benefit of this proposal clearly outweigh the risks:

In certain usages of PKI it is a huge problem that there is no way to
display a certificate in any meaningful way to a human. I challenge you to
show me any application that has been able to produce a functional UI.

It is quite surprising to me how many people (who apparently are not exposed
to this problem) who just dismiss this as a non-existing problem not worth
solving. 

To solve phishing it would be enormously helpful if there was a good way to
see the authenticated identity of the Website owner. EV certs is doing this
to an extent but we could do better. But this is far from the only use case.

The effort to bring electronic signatures to use in the EU has been
revitalized and is now supported by several EU large scale projects, an EU
wide action plan and a standardization mandate initiated by the EU
commission. This represents a huge effort to remove all obstacles for wide
spread use of eSignatures in the EU.

One important area is the work on visible signatures (signatures that makes
sense also from a UI perspective) where the visual representation of the
signer is of great importance, be it a EU citizen of a public service
provider.

Within the diverse deployments of ID infrastructures within the EU, it is
totally impossible for a generic UI to translate present subject name
attributes into a meaningful presentation of Identity.

This is not just a problem with attributes like SERIALNUMBER which is
obviously ambiguous. It is also a problem with attributes like Organization,
which in some cases means "employer" and in other situations means "The RA
this subject has a relationship with", Country which in some cases is the
country of residence and in other cases is the country of affiliation of
some sort. And it goes on and on.

To allow the CA to design and offer a visual representation of a certificate
is not more strange than the natural task for an issuer of any physical
token to design its physical appearance, which possibly could differ from
the content of any chip or the magnetic stripe on the very same card. We
realize this potential for fraudulent issuer behavior, and we find it to be
an acceptable tradeoff rather than forcing all cards to be blank.

The certificate image provides a reasonably simple solution for the UI
designer. Those who want to oppose it should at least provide a reasonable
alternative. 

Because we need one.

/Stefan

On 09-12-02 10:53 PM, "Paul Hoffman" <[email-masked]> wrote:

> It is clear from the Security Considerations in this document that the risk of
> deploying this technology far outweighs the (mostly novelty) value. The WG has
> not come up with any good mechanisms for reducing the risks posed; therefore,
> I think this document should be abandoned by the WG.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 3 Dec 2009 20:20:58 -0500

Stefan,

After reviewing the draft in light of your comment, I withdraw my
objection to the I-D.

However, I do have some comments on what you wrote below.

That is described in-line.

> Behalf Of Stefan Santesson
> Sent: Thursday, December 03, 2009 9:19 AM
> To: Paul Hoffman; [email-masked]
> This is not different in principle from other name forms 
> already allowed in PKI, or for that matter, what is already 
> allowed by with RFC 3709.
> There is nothing that stops a logotype image (e.g. The 
> background image) to provide the CA with the same potentially 
> harmful ability.
> 
> Actually, this text in the security considerations section 
> could as well be deleted as it is accurately dealt with in 
> RFC 3709, and this draft inherits the security considerations 
> in RFC 3709.
> 
> 
> There is nothing that prevents a trusted CA from issuing 
> certificates containing fraudulent or conflicting 
> information. This is generally acceptable because:
> 
> 1) We have functions through which we can select which CAs we 
> trust and for what purpose of usage we trust this CA to 
> provide trusted assertions.
> 
> The crime is signed and there is no way to deny it. Such CA 
> would go out of business and get sued.
> 
> 
> In certain usages of PKI it is a huge problem that there is 
> no way to display a certificate in any meaningful way to a 
> human. I challenge you to show me any application that has 
> been able to produce a functional UI.
> 
> It is quite surprising to me how many people (who apparently 
> are not exposed to this problem) who just dismiss this as a 
> non-existing problem not worth solving. 
> 
> To solve phishing it would be enormously helpful if there was 
> a good way to see the authenticated identity of the Website 
> owner. EV certs is doing this to an extent but we could do 
> better. But this is far from the only use case.
> 
> The effort to bring electronic signatures to use in the EU 
> has been revitalized and is now supported by several EU large 
> scale projects, an EU wide action plan and a standardization 
> mandate initiated by the EU commission. This represents a 
> huge effort to remove all obstacles for wide spread use of 
> eSignatures in the EU.
> 
> One important area is the work on visible signatures 
> (signatures that makes sense also from a UI perspective) 
[Santosh] This could be dangerous.  We dealt with digital signatures and
visual signature (if I understand what you mean) in 1995-96.  You may
want to think about encrypting the signature using ephemeral keys to
protect against misuse.

> where the visual representation of the signer is of great 
> importance, be it a EU citizen of a public service provider.
> 
> Within the diverse deployments of ID infrastructures within 
> the EU, it is totally impossible for a generic UI to 
> translate present subject name attributes into a meaningful 
> presentation of Identity.
> 
> This is not just a problem with attributes like SERIALNUMBER 
> which is obviously ambiguous.
[Santosh] Under PI type structure, would the use of assigner in the
Subject Alt Name not take care of it?

 It is also a problem with 
> attributes like Organization, which in some cases means 
> "employer" and in other situations means "The RA this subject 
> has a relationship with", Country which in some cases is the 
> country of residence and in other cases is the country of 
> affiliation of some sort. And it goes on and on.
[Santosh] Would the certificate policy not dictate this?

> 
> To allow the CA to design and offer a visual representation 
> of a certificate is not more strange than the natural task 
> for an issuer of any physical token to design its physical 
> appearance, which possibly could differ from the content of 
> any chip or the magnetic stripe on the very same card. We 
> realize this potential for fraudulent issuer behavior, and we 
> find it to be an acceptable tradeoff rather than forcing all 
> cards to be blank.
> 
> The certificate image provides a reasonably simple solution 
> for the UI designer. Those who want to oppose it should at 
> least provide a reasonable alternative. 
> 
> Because we need one.
> 
> /Stefan
> 
> 
> 
> > It is clear from the Security Considerations in this 
> document that the 
> > risk of deploying this technology far outweighs the (mostly 
> novelty) 
> > value. The WG has not come up with any good mechanisms for reducing 
> > the risks posed; therefore, I think this document should be 
> abandoned by the WG.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 04 Dec 2009 09:53:33 +0100

> That is described in-line.

Great. My response in-line.

>> <...>
I'm sure there are things to be aware of. However that work is separate from
this document, but can benefit from both this document as well as RFC 3709
and RFC 3739.

>> <...> 

If the SerialNumber attribute contains an identifier that meets the criteria
of PI, then the answer is yes, PI would work for this isolated attribute.
But it is inadequate for the overall problem.

> [Santosh] Would the certificate policy not dictate this?

Unfortunately not. Certificate policy is not granular, nor flexible as a
tool to handle this.

Even if certificate policies would be flexible enough, they would still not
carry explicit data about UI design. The rules they carry are simply
identified by the policy, but the rules as such need to be provided out of
band. It is not realistic for UIs to learn and update display rules of every
conceivable certificate policy.

/Stefan

>><...>

---

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 4 Dec 2009 10:48:20 +0100

Stefan,

I have strong objections to the progression of this I-D.

1 - The text states:

   Display of a certificate information to humans is challenging due to
   lack of well defined semantics for critical identity attributes.
 
   (...) Consequently the application can
   display the actual data, but faces problem to label that data in the
   UI, informing the human about the exact nature (semantics) of that
   data. 

The semantics of all the fields contained in a certificate is well defined.
Using another way (like an image) to present them could lead to change their semantics.
If you believe that the current attributes that are included in a DN are not explicit enough, 
then it is possible to define additional ones. I fear that you would like to keep the current ones, 
but change their semantics. This is not acceptable.

New DN attributes, if necessary, could easily be added by ISO or IETF since each one 
is defined using an OID.

2 - The text also states:

   It is also challenging for the application to determine which
   identification attribute that are important to display and how to
   organize them in a logical order.

In this way, you will mandate a uniform representation across all applications, whereas the goal is the contrary.
Some applications may need a minimalist representation while some others may need a maximalist representation.
The proposal mandates a (single) "complete visual representation of the certificate". 

I believe that the cert-image approach is the wrong solution to the problems you mention.

3 - Using an image is also the wrong way when facing I18N. Should we have a french image, an italian image, 
a spanish image, a portuguese image, etc ..  so that the image includes the language of the relying party application ? 
This is not realistic. Should we only have pictograms in the cert-image ? What is the pictogram for a Qualifed Certificate 
(in the sense of the EU Directive on Electronic Signatures) ? Which standardization body is going to standardize them 
(otherwise there might be a misuse of pictograms) ? The problem is much wider than mentioned in the draft.

4 - We should not forget that certificates may be lodged in smart cards. So their size should be kept as small as possible.
Including the image itself in the certificate is the wrong approach because this leads to an increase of the size. 
There even not limit to the size of the image. How would you like relying party applications to be able to process data structures 
where the limits cannot be established ? Note that mandating PDF/A may make the problem even worse (PDF/A is larger than PDF).

5 - You are asking for a "reasonable alternative" for the UI designer. Here it is. 
Considering the needs of the relying party application and the localization features of the application (I18N), 
the UI designer chooses which components should be made visible and picks the appropriate values in the certificate. 
In this way, the values that are displayed are accurate and correspond exactly to the needs of the application.

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : Paul Hoffman,pkix 
Date : 2009-12-03, 15:18:57
Sujet : Re: [pkix] WGLC for draft-ietf-pkix-certimage-03

Paul and Santosh,

Because we need one.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 04 Dec 2009 11:45:10 +0100

Denis,

In-line

> New DN attributes, if necessary, could easily be added by ISO or IETF since

I whish the deployment of PKI would allow for a dynamic inclusion of new
attributes that were automatically meaningful for UIs.

However, that is not the case.

I'm not proposing changing the semantics of attributes, simply allowing the
exact meaning of the data to be presented.

An organizationName for example may represent your employer but may
represent something else.

> In this way, you will mandate a uniform representation across all
> applications, whereas the goal is the contrary.

No, the certificate image does not mandate anything. It offers the UI one
image for user friendly communication. It does not prevent applications to
hide this behind a minimalistic vew of their choice, nor offering a
maximalistic view of their choice.

> I believe that the cert-image approach is the wrong solution to the problems

This is of course always interesting to know. It would be even more
interesting (and useful) to know what you suggest as an alternative.

Please provide me with a generic algorithm any UI can use to present the
following identities. Both are provided by real certificate profiles in
public commercial use.

Example 1:(issued by BankID in Sweden with altered data)

CN = GUN INGER PERSSON
2.5.4.41 = (090508 11.55) INGER PERSSON - BankID på fil
SERIALNUMBER = 193505153742
G = GUN INGER
SN = PERSSON
O = Swedbank AB (publ)
C = SE

Or Example 2:

T = 2144 Civilingenjörer m.fl., elektronik och teleteknik
CN = Stefan Hansson--Projektledare--Test Företag AB
SERIALNUMBER = 1620210020801453
SN = Hansson
G = Stefan
O = Test Företag AB
C = SE

> a spanish image, a portuguese image, etc ..  so that the image includes the
> language of the relying party application ?

This is a possible and not unrealistic scenario yes. But it would not be
typical.

A more realistic scenario would be to offer one image in you local language
(e.g. Japanese) and one e.g. in English. The local UI would then select the
one that is most appropriate for your local language selection.

But this is just speculation on my part. This is up to the issuers and
application providers to figure out over time.
 
> This is not realistic. Should we only have pictograms in the cert-image ? What
> is the pictogram for a Qualifed Certificate

I don't know. Such marks can be developed elsewhere if they are useful and
used within this solution.

> (in the sense of the EU Directive on Electronic Signatures) ? Which
> standardization body is going to standardize them

I don't know. If there is a need and a will, there is a way.

> than mentioned in the draft.

This is no different from the design of physical credentials. Visual symbols
and marks need to be developed over time. This is not solved by this draft,
but this draft at least make it possible to break into the realm of visual
representation of certificates. Which today is totally lacking.

>  
> 4 - We should not forget that certificates may be lodged in smart cards. So
> their size should be kept as small as possible.

Images does not need to be included in the certificate. RFC 3709 defines the
framework for having them externally stored.

> There even not limit to the size of the image. How would you like relying
> party applications to be able to process data structures
> where the limits cannot be established ? Note that mandating PDF/A may make
> the problem even worse (PDF/A is larger than PDF).
>  

This is already handled in the infrastructure surrounding the different
storage options. If the image is embedded, the ASN.1 TLV structure gives
length.

> to the needs of the application.

Yes, sounds simple doesn't it.

Now please apply this as a general logic to the examples above.

1) Considering the needs of the relying party application and the
localization features of the application (I18N),

 - First of all, as a UI, you don't know the nature of the atributes (e.g.
You don't know the nature of the organization in O=. You know even less how
to label the specific meaning of "O=" in different languages.

2 the UI designer chooses which components should be made visible and picks
the appropriate values in the certificate.

- How do you know which values that should be visible. Should you show both
given name, surname, commonName and Name (2.5.4.41). If you come up with one
selection for one certificate type, how do you know that selection is valid
for every conceivable certificate on this planet?

> to the needs of the application.

This way you will NOT solve the need of the uneducated human viewer. At best
you have provided me with the accurate data, but you fail to inform me about
the meaning of that data and you have not even considered how to tell me
thinks like the type of credentials this certificate represents.

/Stefan

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Dec 2009 12:14:07 +0000

Stephen Kent wrote:
> Folks,
> 
> I'm initiating WGLC for this document, at the request of the author. It
> has been briefed at the last two IETF meetings and changes have been
> made in response to feedback received from the list.  The WGLC will
> close on December 18.

I don't think this is ready. (As an aside, I'm not at all
convinced that its useful, nor that it ought be on the
standards track. I'm also concerned that it could be
harmful if deployed. But I won't keep yelling:-)

- Is there experience with deployment of 3709 that indicates
that this spec is required/useful? If not, then why would we
want to add yet more to that already complex story? If there
is, a pointer would be appreciated. (And I don't mean a claim
that some EU something requires something.)

- I think there should be at least some fairly worked-out
use-case included, e.g. for a browser. While that would
not be normative, I at least would be a lot happier with
this if I saw such a use-case described and if some browser
vendors said that they might actually implement it. As-is,
I suspect that this would just make things less usable
(yet more meaningless PKI-related clicks) rather than
more usable, which I guess is the intent.

- RFC 3709 defines a quite complex structure (LogotypeExtn)
with lots of optional fields. This draft doesn't say which of
those can or cannot be present nor what to do if they are or
are not present. For example, is audio required for this
or not? (There are many examples.)

- Its not clear which of the image formats defined here
(PDF/A, SVG, etc.) an RP is expected to support - they
all seem to be optional for the CA, but (implicitly)
it seems that all are mandatory to support for the RP.
That's nice for the CA, but nasty for the RP and I
suspect would lead to interop problems since I would
not expect support for all image types in all RPs.

- Some of the image formats can include URLs (or things
that a renderer treats as URLs) within the image that
could be de-referenced insecurely. Is that allowed? If
so, some security considerations seem called for. If not,
some MUST NOT seems called for in which case how would a
CA scan supplied images for this? (Not necessarily
trivial IMO.)

- The security considerations says that implementations
(meaning the RP?) MUST "reject" images that contain
external references. That seems impractical - are there
really libraries that developers could use to enforce
that for the image types mentioned? I suspect not.

- Same as above: what does "reject" mean for an RP? (Reject
the cert or display a warning or what?)

- There have been vulnerabilities found in various
image formats. Those should at least be referenced
(I don't have references handy, but I guess CVE
references would be appropriate) so that a putative
CA developer has a hint as to what kind of things to
watch out for in supplied images.

- What if this were included in a self-signed cert?
Should/must an RP do something different?

- What if an entire chain included these? How would
the (e.g. broswer) use-case look then? Would that
habituate users to clicking inside the image and
expecting to see a new image?

Stephen.

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 7 Dec 2009 17:50:44 +0100

Stefan,

None of your responses is convincing me that the draft should proceed to RFC.

1 - You said: "I'm not proposing changing the semantics of attributes, simply allowing the
exact meaning of the data to be presented". I have difficulties to understand the difference 
you want to introduce between the semantics of the data and the exact meaning of the data 
to be represented. Clearly you want to add a meaning in the image which is not present in 
the certificate data structure. This means that the human user will be able understand 
a difference that is not visible to the application. This is not acceptable. 

2 - About the image you said: "It does not prevent applications to hide this behind 
a minimalistic vew of their choice, nor offering a maximalistic view of their choice". 

Since the format does not contain information on where to "cut" the image, it is only possible 
to present the full view or no view at all. 

3 - About your examples. I would suggest that you provide me with the images you have in mind 
and then I will provide you with the data. :-)

However, without waiting for the images, hereafter would be my proposal for a french viewer:

Nom = GUN INGER PERSSON
Identifiant complémentaire = (090508 11.55) INGER PERSSON - BankID på fil
Numéro de série = 193505153742
Organisation = Swedbank AB (publ)
Pays = SE

or example 2 for an english viewer:

Name = Stefan Hansson--Projektledare--Test Företag AB
Title = 2144 Civilingenjörer m.fl., elektronik och teleteknik
Serial number= 1620210020801453
Organization = Test Företag AB
Country = SE

In these two cases the end user has sufficient information to distinguish between different identifiers.

4 - You said: "A more realistic scenario would be to offer one image in your local language
(e.g. Japanese) and one e.g. in English". You are advocating for more than one image to be present.
This will increase the size of the certificate. This should be avoided. 

5 - About pictograms You said:" Such marks can be developed elsewhere if they are useful and
used within this solution." In response to my question which was "Which standardization body 
is going to standardize them ?", you replied:"I don't know. If there is a need and a will, there is a way".

I want to say that want you propose is only the top of an iceberg. 
Without standardization of the part of the iceberg which is under the water (which is much bigger 
than the part which is outside), the cert-image approach is going to create more confusion than advantages.

6 - You said: "Images does not need to be included in the certificate. RFC 3709 defines the
framework for having them externally stored". 

The draft should NOT allow images to be included in the certificate. If the image itself cannot be included, 
then it is a guarantee that certificates will not "explose". For example, for in S-MIME messages, we would 
simply need to be able to carry such images by defining a new unsigned attribute. However, IMO, 
the advantages to carry such images have not yet been demonstrated.

Denis

----- Message reçu ----- 
De : Stefan Santesson 
À : denis.pinkas,pkix 
Date : 2009-12-04, 11:45:10
Sujet : Re: [pkix] WGLC for draft-ietf-pkix-certimage-04

Denis,

In-line

CN = GUN INGER PERSSON

Or Example 2:

 

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Dec 2009 00:07:57 +0100

Hi Stephen,

> harmful if deployed. But I won't keep yelling:-)

You might be right that we are not ready. It is still a bit premature to
say, but with the current situation we may have to wait for more concrete
development within EU as well as making en effort to bring supportive
vendors and CAs to this list to complete the discussion about deployment and
usability.

> that some EU something requires something.)

The idea with 3709 was good but did not provide a complete solution to the
problem. We don't add more to make this more complex. We add this image to
make it easier.

Using the logotypes of RFC 3709 the UI need to compose a mix of the
logotypes and the attributes. Using the certificate image the UI only need
to display that image since the certificate image contains both logotypes
and text in one package.

The reason why this would be useful is because it is easier to deploy.

> more usable, which I guess is the intent.

Unfortunately the browser vendors have been hard to flirt with. First of
all, they have a fairly well defined certificate type to deal with, which
means that know fairly well what information to look for and what
attributes. Secondly they are reluctant to give up UI space to the CAs.

The current primary use case for this is currently in the in various
national PKIs, e.g. Throughout Europe where this can enhance certificate
selection UIs and signature verification UIs  such as in the upcoming
Visible signature standardization.

It is my hope that browsers over time will discover why this would be a good
idea also fro them.

> or not? (There are many examples.)

This is not changed form RFC 3709. I have not found it necessary to further
regulate the options of RFC 3709, but I'm open for suggestions.

On the good image questions below.
I will try to get answers on these from Leonard (Adobe co-author)

> Should/must an RP do something different?

A certificate must validate and be trusted in order for graphics to be
displayed. I guess if you have determined a root certificate to be trusted
by OOB means, then it's up to you to use a provided image for display, but
this is not the typical usage.

> expecting to see a new image?

I don't think the standard should mandate the UI design. When one particular
certificate is displayed, the UI may use graphics to enhance the view if the
certificate is trusted.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Dec 2009 00:37:18 +0100

> a difference that is not visible to the application. This is not acceptable.

I will explain in the examples below.

> to present the full view or no view at all.

You misunderstood me. A minimalistic view could be just the name field (no
graphics). The max detail view could be a list of all attributes (like
current certificate viewers.

When showing the certificate image, the image is naturally shown on its own.
Typically the image is scalable.

> between different identifiers.

Well, here is the truth about these certificates. Certificate 1 is a
certificate issued to a private individual. The Organization (Swedbank AB)
is the organization where the subject belong as customer, not as employee.

Example 2 is an organizational certificate, certifying Stefan Hansson as
employee of Test Företag AB.

There is no way a UI can determine the type of certificate they are showing,
even less the nature of the data they contain.

Both organizational attributes contain an organization name, but the
semantics of the values differ. If this had been a certImgae, then all this
would have been made evident to a human by text and graphics provided in the
image.

> This will increase the size of the certificate. This should be avoided.

Not at all, If you incorporate these images by reference, then the size of
the certificate is only increased by the size of the URL.

> more confusion than advantages.

Pictograms can be useful, but they are not necessary. If they are not
necessary for the current purely text based certificate viewers, then why
would they be necessary for an improved UI.

Useful, yes, necessary no.

> the advantages to carry such images have not yet been demonstrated.

I disagree that we should NOT allow certificates to be embedded.
In the context of defining local PKIs, it may make sense to have embedded
images.

I don't find it to be a realistic scenario that a CA suddenly decides to
issue certificates with embedded images that suddenly explodes.
In the realistic world, the CA would test their certificates in the
environments and protocols they are using to determine the most suitable
approach.

/Stefan

> Denis
>  
>>  
>> -----  Message reçu -----
>>  
>> De  : Stefan Santesson <mailto :[email-masked]>
>>  
>> À  : denis.pinkas,pkix <mailto :[email-masked],[email-masked]>
>>  
>> On 09-12-04 10:48 AM, "Denis Pinkas"  <[email-masked] <mailto:
>> [email-masked]> >  wrote:
>> 
>>> Stefan,
>>> 
>>> Using another way (like an image) to  present them could lead to change
>>> their
>>> semantics.
>>> If you  believe that the current attributes that are included in a DN are
>>> not
>>>  explicit enough,
>>> then it is possible to define additional ones. I  fear that you would like
>>> to
>>> keep the current ones,
>>> Some applications may need a minimalist representation  while some others
>>> may
>>> need a maximalist representation.
>>> I believe that the cert-image approach is the  wrong solution to the
>>> problems
>>> you mention.
>>> 
>> 
>>> (otherwise there might be a misuse of pictograms)  ? The problem is much
>>> wider
>>> than mentioned in the draft.
>>>  
>> 
>>> 5 - You are asking for a "reasonable alternative" for the UI  designer. Here
>>> it
>>> is. 
>>> the UI designer chooses which components should be made  visible and picks
>>> the
>>>  In this way, the values that are displayed are accurate and correspond
>>> exactly
>>> to the needs of the application.
>>> 
>> 
>>> In this  way, the values that are displayed are accurate and correspond
>>> exactly
>>>  to the needs of the application.
>>

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 8 Dec 2009 09:53:11 +0100

Stefan,

Before I reply to this email, would you please provide the images you have in mind for your two examples ?

Denis 
----- Message reçu ----- 
De : Stefan Santesson 
À : denis.pinkas,pkix 
Date : 2009-12-08, 00:37:18
Sujet : Re: [pkix] WGLC for draft-ietf-pkix-certimage-04

When showing the certificate image, the image is naturally shown on its own..
Typically the image is scalable.

/Stefan

>> - First of all, as a UI, you don't know the nature of the atributes (e..g.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Dec 2009 10:22:05 +0000

Hi Stefan,

> vendors and CAs to this list to complete the discussion about deployment and

Are you now saying that waiting rather than proceeding with this
document is better? I think that'd be good. (But even so, let's
thrash the issues out below:-)

> problem. We don't add more to make this more complex. We add this image to

IMO additions to 3709 inherently make it more complex. If you
want something simpler, make 3709 historic and start over, with
some real, quotable, use-cases and something that's got vendor
support. (That doesn't have to be browser vendors of course,
but something.)

> to display that image since the certificate image contains both logotypes

Maybe. Some proof-of-concept would seem called for before
that can be confidently asserted.

> The reason why this would be useful is because it is easier to deploy.

I fail to see the logic in that last statement. The evil bit could
be easy to deploy, but isn't useful.

> attributes. Secondly they are reluctant to give up UI space to the CAs.

Right. So then you need another use case IMO. I suspect that the
UI real estate may be an issue in other applications as well, e.g.
what'd happen for an application that had an iPhone/android device
port, or on a book reader.

> Visible signature standardization.

Again, you don't quote something that we can look at. Which countries?
Which standards activities? Which UIs?

> regulate the options of RFC 3709, but I'm open for suggestions.

So you're saying that conformance to this requires conformance
to all the MUSTs etc. from 3709? If so, I think you lose the
"simpler" argument. If not, then I think you need to say how
conformance to this differs, which means saying how to handle
all the other fields of LogotypeExtn.

> I will try to get answers on these from Leonard (Adobe co-author)

I'll answer the other mail on that.

Cheers,
S.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Dec 2009 11:56:30 +0100

Denis,

Sorry, I don¹t have time right not to craft demonstration images.
I had hoped you could use your imagination. Reading Stephen¹s question I
realize that I might have to anyway, but probably not before the weekend.

/Stefan

On 09-12-08 9:53 AM, "Denis Pinkas" <[email-masked]> wrote:

>> On 09-12-07 5:50 PM, "Denis Pinkas" <[email-masked] <mailto:
>>> > 1 - You  said: "I'm not proposing changing the semantics of attributes,
>>> simply
>>> >  allowing the
>>> > exact meaning of the data to be presented". I have  difficulties to
>>> understand
>>> > the difference
>>> > you want to  introduce between the semantics of the data and the exact
>>> meaning
>>> > of  the data 
>>> > to be represented. Clearly you want to add a meaning in the  image which
>>> is not
>>> > present in 
>>> > the certificate data structure.  This means that the human user will be
>>> able
>>> > understand 
>>> > 2 - About the image you said: "It does not prevent  applications to hide
>>> this
>>> > behind 
>>> > a minimalistic vew of their  choice, nor offering a maximalistic view of
>>> their
>>> > choice". 
>>> >  Since the format does not contain information on where to "cut" the
>>> image,  it
>>> > is only possible
>>> > 3 - About your examples. I would suggest  that you provide me with the
>>> images
>>> > you have in mind
>>> > However, without  waiting for the images, hereafter would be my proposal
>>> for a
>>> > french  viewer:
>>> > 
>>> > Nom = GUN INGER PERSSON
>>> > 4 - You said: "A  more realistic scenario would be to offer one image in
>>> your
>>> > local  language
>>> > (e.g. Japanese) and one e.g. in English". You are advocating  for more
>>> than one
>>> > image to be present.
>>> > 5 -  About pictograms You said:" Such marks can be developed elsewhere if
>>> they
>>> > are useful and
>>> > is going to  standardize them ?", you replied:"I don't know. If there is a
>>> need
>>> > and  a will, there is a way".
>>> > 
>>> > Without standardization of the part of  the iceberg which is under the
>>> water
>>> > (which is much bigger
>>> >  than the part which is outside), the cert-image approach is going to
>>> create
>>> > more confusion than advantages.
>>> > 
>> 
>>> > 6 - You said: "Images does not need to be included in the  certificate.
>>> RFC
>>> > 3709 defines the
>>> > The draft should NOT allow images to be  included in the certificate. If
>>> the
>>> > image itself cannot be  included,
>>> > then it is a guarantee that certificates will not "explose".  For example,
>>> for
>>> > in S-MIME messages, we would
>>>> >> De : Stefan Santesson <mailto :[email-masked] <mailto:
>>>> [email-masked]> >
>>>> >>  
>>>> >> À : denis.pinkas,pkix <mailto :[email-masked] <mailto:
>>>> [email-masked]> ,[email-masked] <mailto: [email-masked]> >
>>>> >> 
>>>> [email-masked]>   <mailto:
>>>> >> [email-masked] <mailto: [email-masked]> > >  wrote:
>>>> >> 
>>>>> >>> Stefan,
>>>>> >>> 
>>>>> >>> New DN  attributes, if necessary, could easily be added by ISO or IETF
>>>>> since
>>>>> >>> each one 
>>>>> >>> is defined using an  OID.
>>>>> >>> 
>>>>> >>> 
>>>> >> 
>>>>> >>> The proposal mandates a (single) "complete  visual representation of
the
>>>>> >>> certificate".
>>>>> >>> 3 - Using an image is also the wrong way when facing I18N.  Should we
>>>>> have a
>>>>> >>> french image, an italian  image,
>>>>> >>> This is not realistic.  Should we only have pictograms in the
>>>>> cert-image ?
>>>>> >>>  What
>>>>> >>> Including the image itself in the certificate is the  wrong approach
>>>>> because
>>>>> >>> this leads to an increase of the  size.
>>>> >> 
>>>> >> Images does not need to be included in the  certificate. RFC 3709
>>>> defines
>>>> >> the
>>>>> >>> Considering the needs of the relying  party application and the
>>>>> localization
>>>> >>  given name, surname, commonName and Name (2.5.4.41). If you come up
>>>> with
>>>> >> one
>>> > [email-masked] <mailto: [email-masked]>

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 8 Dec 2009 12:02:58 +0100

Stefan,

You have, at the moment, requests for images from three different people.
It is worth waiting for theses examples.

Denis

----- Message reçu ----- 
De : Stefan Santesson 
À : denis.pinkas,pkix 
Date : 2009-12-08, 11:56:30
Sujet : Re: [pkix] WGLC for draft-ietf-pkix-certimage-04

Denis,

Sorry, I don’t have time right not to craft demonstration images.
I had hoped you could use your imagination. Reading Stephen’s question 
I realize that I might have to anyway, but probably not before the weekend..

/Stefan

Stefan,

Denis 

-----  Message reçu ----- 

 

/Stefan

>  Denis
> 
>> 
>> ----- Message reçu -----
>>  
>> De : Stefan Santesson <mailto :[email-masked] <mailto: [email-masked]> >
>>  
>> À : denis.pinkas,pkix <mailto :[email-masked] <mailto: [email-masked]> ,[email-masked] <mailto: [email-masked]> >
>> 
>> On 09-12-04 10:48  AM, "Denis Pinkas" <[email-masked] <mailto: [email-masked]>   <mailto:
>> This is no different from the design of physical  credentials.. Visual symbols
>>>  appropriate values in the certificate.