Subject: [pkix] Certimage - way forward

From: Stefan Santesson <[email-masked]>
Date: Wed, 16 Dec 2009 11:07:07 +0100

The WGLC list discussion so far has so far included

- implementers, CAs and individuals supporting the publication of this draft
- some who suggest that solving this issue would best be done in a different
way
- some who either doubt the value of this draft or question whether the
problem needs solving at all but who seems to abstain whether to publish
this document or not
- some who have raised concerns about security considerations

I have not done the count of the number of individuals in each category.

Before we conclude this WGLC I would like to address the security
considerations of this draft. This is the issues I have noted:

- Current draft removed security considerations text concerning the CAs
ability to include graphics that are inconsistent with other information in
the certificate. Some text need to be reinstated that describes this issue
in the perspective of RFC 3709.

- Provide guidance related to inclusion of image data in a certificate

* If the software used to render an image has a security vulnerability, a CA
may explaoit that vulnerability by including malicious images in
certificates. 
* In order to limit the threat above, the CA must not blindly accept a
certimage for inclusion in a certificate from the certificate subject, or
any other untrusted sources.
* Implementers of certificate UIs displaying images should keep software
libraries up to date in order to reduce threats from known vulnerabilities.
* images must not include any ³clickable² URLs that can be dereferenced by
clicking on a URL within the image.
* SVG images must be verified to be self contained (only contains embedded
images) before they are displayed by a UI

This should also be described relative to RFC 3709 (which already allow
inclusion of images)
Possibly include reference to other protocols that may carry image data.

I will try to address these issues in an updated draft as soon as possible,
but I may not have time to do so before X-mas.
I would therefore like to request extra time to address these issues before
the WGLC is concluded.

Please let me know if there are any issues that you think is missing from
the list above.

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 16 Dec 2009 11:57:05 +0100

Stefan,

You have not mentioned : "some who suggest continue with the WD as an Informational RFC".

If I understand you correctly, your intent is to continue with the current draft by polishing the security considerations section.
This may solve the concerns of the fourth category of people (i.e. some who have raised concerns about security considerations)

However, as you noted : some who suggest that solving this issue would best be done in a different way
So I wonder whether polishing the security considerations section is the right way to proceed.

At this stage, since there is no concensus, I would propose that your co-chair states 
what to do with this draft or how to proceed with this draft.

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : pkix 
Date : 2009-12-16, 11:07:07
Sujet : [pkix] Certimage - way forward

- implementers, CAs and individuals supporting the publication of this draft
- some who suggest that solving this issue would best be done in a different way
- some who either doubt the value of this draft or question whether the problem needs solving at all but who seems to abstain whether to publish this document or not
- some who have raised concerns about security considerations

Before we conclude this WGLC I would like to address the security considerations of this draft. This is the issues I have noted:

- Current draft removed security considerations text concerning the CAs ability to include graphics that are inconsistent with other information in the certificate. Some text need to be reinstated that describes this issue in the perspective of RFC 3709.

If the software used to render an image has a security vulnerability, a CA may explaoit that vulnerability by including malicious images in certificates. 
In order to limit the threat above, the CA must not blindly accept a certimage for inclusion in a certificate from the certificate subject, or any other untrusted sources. 
Implementers of certificate UIs displaying images should keep software libraries up to date in order to reduce threats from known vulnerabilities. 
images must not include any “clickable” URLs that can be dereferenced by clicking on a URL within the image. 
SVG images must be verified to be self contained (only contains embedded images) before they are displayed by a UI

This should also be described relative to RFC 3709 (which already allow inclusion of images)
Possibly include reference to other protocols that may carry image data.

I will try to address these issues in an updated draft as soon as possible, but I may not have time to do so before X-mas.
I would therefore like to request extra time to address these issues before the WGLC is concluded.

Please let me know if there are any issues that you think is missing from the list above.

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 16 Dec 2009 12:01:30 +0100

Typo correction.

I meant:

"You have not mentioned : "some who suggest continue with the WD as an Experimental RFC".

Denis

---------- 
De : pkix-bounces 
À : pkix 
Date : 2009-12-16, 11:57:05
Sujet : Re: [pkix] Certimage - way forward

Stefan,

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : pkix 
Date : 2009-12-16, 11:07:07
Sujet : [pkix] Certimage - way forward

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 16 Dec 2009 12:50:46 +0100

Denis,

I simply mean that we should fix the security consideration issues as the
next step.
To do so we need some extra time.

/Stefan

On 09-12-16 12:01 PM, "Denis Pinkas" <[email-masked]> wrote:

>> De  : pkix-bounces <mailto :[email-masked]>
>>  
>> À  : pkix <mailto :[email-masked]>
>>  
>> If I understand you correctly, your intent is to continue with the  current
>> draft by polishing the security considerations section.
>>  
>> This may solve the concerns of the fourth category of people (i.e. some who
>> have raised concerns about security  considerations)
>>  
>>> De  : pkix-bounces <mailto :[email-masked]>
>>>  
>>> À  : pkix <mailto :[email-masked]>
>>>  
>>> * If the software used to render an image has a  security vulnerability, a
>>> CA may explaoit that vulnerability by including  malicious images in
>>> certificates.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Dec 2009 11:52:02 +0000

I guess I'd argue that the changes are significant enough that another  
wglc should be done later, maybe >1 rev later. As I said in my initial  
mail, IMO this just isn't ready. But, as Denis pointed out, that's  
Steve's call.
S.

On 16 Dec 2009, at 10:07, Stefan Santesson <[email-masked]> wrote:

> - some who either doubt the value of this draft or question whether  
> the problem needs solving at all but who seems to abstain whether to  
> publish this document or not
> - Current draft removed security considerations text concerning the  
> CAs ability to include graphics that are inconsistent with other  
> information in the certificate. Some text need to be reinstated that  
> describes this issue in the perspective of RFC 3709.
>
> If the software used to render an image has a security  
> vulnerability, a CA may explaoit that vulnerability by including  
> malicious images in certificates.
> In order to limit the threat above, the CA must not blindly accept a  
> certimage for inclusion in a certificate from the certificate  
> subject, or any other untrusted sources.
> Implementers of certificate UIs displaying images should keep  
> software libraries up to date in order to reduce threats from known  
> vulnerabilities.
> images must not include any “clickable” URLs that can be  
> dereferenced by clicking on a URL within the image.
> SVG images must be verified to be self contained (only contains  
> embedded images) before they are displayed by a UI
>
> I will try to address these issues in an updated draft as soon as  
> possible, but I may not have time to do so before X-mas.
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Dec 2009 08:13:31 -0800

At 11:52 AM +0000 12/16/09, Stephen Farrell wrote:
>I guess I'd argue that the changes are significant enough that another wglc should be done later, maybe >1 rev later. As I said in my initial mail, IMO this just isn't ready. But, as Denis pointed out, that's Steve's call.

I'm with Stephen (again) on this. Given the primary author's earlier stated reservation to having a fleshed-out Security Considerations section, we really should have another chance to do a full WG Last Call. That WG LC should also directly address the intended status of the document.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 16 Dec 2009 17:40:18 +0100

I have no problem doing a new WGLC once we have a new version which also
addresses the intended status.

/Stefan

On 09-12-16 5:13 PM, "Paul Hoffman" <[email-masked]> wrote:

>> I guess I'd argue that the changes are significant enough that another wglc
>> should be done later, maybe >1 rev later. As I said in my initial mail, IMO
>> this just isn't ready. But, as Denis pointed out, that's Steve's call.
> 
> I'm with Stephen (again) on this. Given the primary author's earlier stated
> reservation to having a fleshed-out Security Considerations section, we really
> should have another chance to do a full WG Last Call. That WG LC should also
> directly address the intended status of the document.