Subject: [pkix] New CertImage draft 05 posted

From: Stefan Santesson <[email-masked]>
Date: Wed, 17 Feb 2010 17:48:38 +0100

All,

I have carefully reviewed all issues raised during WGLC.
I have no submitted a new draft where I have tried to resolve these issues.

draft-ietf-pkix-certimage-05.txt

In short, this is my compressed list of recorded issues and their
resolutions:

1) Previous versions of the draft highlighted the risk that a CA may include
conflicting information. This was removed as I thought the security
considerations section of RFC 3709 was enough. Some thought not so I have
included some new text in the security considerations section to address
this.

2) Restrictions for SVG images: SVG Tiny 1.2 provides limited functionality
but need to be restricted further. Previous drafts addressed external
references. This draft has been clarified in the SVG section (4.2) to
exclude all forms of potentially harmful references to external data. Other
concerns was raised regarding scripting and conditional processing. Section
(4.2) has been updated to disallow scripting elements but still allows
conditional processing rules. The latter should be a valid option that can
safely be used by the CA to allow a well defined and signed image to adapt
to the local environment.

3) Threat from rendering of images with malicious content: This issue has
been addressed in the security considerations section

Other concerns has been related to the usability of the document as such and
whether PKIX should produce a standard in this area.

Diff from version 04 is available from:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pkix-certimage-05.txt

Please let me know if I missed out on anything.

/Stefan

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 18 Feb 2010 15:28:58 +1100

Stefan,

Does a “data:” URI with a gzipped SVG work (SVGZ instead of SVG) — as in the example in appendix A?

There is nowhere in a “data:” URI [RFC2397] to indicate the Content-Encoding.

The only way to parse it is to use heuristics to guess if the content is SVG or SVGZ.

The heuristic is easy (a GZIP value starts with 2 magic bytes 1F 8B), but I don’t know if tools commonly do this.

Perhaps the certimage spec needs to explicitly say that SVG and SVGZ are valid in a data URI that lists the image/svg+xml media type. It would be a shame to lose the compression (x5.6 in the example).

--

James Manger

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 18 Feb 2010 10:59:46 +0100

James,

The differentiation in content encoding given by the file extension .svg or
.svgz is, as you point out, lost when providing the image in a ³data:² URI.
Image/svg+xml is however a valid mediatype for both svg and svgz encoded
content and thus I see nothing wrong in including compressed svgz data under
that media type. 

See for example: http://wiki.svg.org/MIME_Type

I agree with you that the text in the draft should be more specific about
this and explicitly allow both svg and svgz under image/svg+xml with added
reference to SVG 1.1 section 1.2 and RFC 1952 (GZIP). I would also hate to
loose the compression.

I¹ll do some updates and resubmit.

/Stefan

On 10-02-18 5:28 AM, "Manger, James H" <[email-masked]>
wrote:

> Stefan,
>  
> Does a ³data:² URI with a gzipped SVG work (SVGZ instead of SVG) ‹ as in the
> example in appendix A?
> There is nowhere in a ³data:² URI [RFC2397] to indicate the Content-Encoding.
> The heuristic is easy (a GZIP value starts with 2 magic bytes 1F 8B), but I
> don¹t know if tools commonly do this.
> Perhaps the certimage spec needs to explicitly say that SVG and SVGZ are valid
> in a data URI that lists the image/svg+xml media type. It would be a shame to
> lose the compression (x5.6 in the example).
>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 18 Feb 2010 12:51:24 +0100

James,

I have now submitted an update:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-pkix-certimage-06.txt

Does this resolve your concerns?

/Stefan

On 10-02-18 10:59 AM, "Stefan Santesson" <[email-masked]> wrote:

> I agree with you that the text in the draft should be more specific about this
> and explicitly allow both svg and svgz under image/svg+xml with added
>> Perhaps the certimage spec needs to explicitly say that SVG and SVGZ are
>> valid in a data URI that lists the image/svg+xml media type. It would be a
>> shame to lose the compression (x5.6 in the example).
>>  
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 18 Feb 2010 22:50:48 +1000

Stefan,

The certimage-06 now makes it absolutely clear how SVGZ must be supported. That is great.

It might mean a little bit of SVG-specific code needs to appear in an otherwise generic "data URI"/"media type" block of code - but that's a very minor quibble.
If someone has tried a data URI with SVG and with SVGZ in an existing tool that supports both, that would be ideal. Perhaps in an Opera browser?

My concern is resolved.

--
James Manger

________________________________________
From: Stefan Santesson [[email-masked]]
Sent: 18 February 2010 22:51
To: Stefan Santesson; Manger, James H; pkix
Subject: Re: [pkix] CertImage: SVGZ in data: URI

James,

/Stefan

James,

The differentiation in content encoding given by the file extension .svg or .svgz is, as you point out, lost when providing the image in a “data:” URI.
Image/svg+xml is however a valid mediatype for both svg and svgz encoded content and thus I see nothing wrong in including compressed svgz data under that media type.

I agree with you that the text in the draft should be more specific about this and explicitly allow both svg and svgz under image/svg+xml with added reference to SVG 1.1 section 1.2 and RFC 1952 (GZIP). I would also hate to loose the compression.

I’ll do some updates and resubmit.

/Stefan

On 10-02-18 5:28 AM, "Manger, James H" <[email-masked]> wrote:

Stefan,

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 22 Feb 2010 23:03:06 +0100

James,

I asked Yngve Pettersen from Opera how they would treat a data URL with
image/svg+xml containing svgz. He confirmed that this works just fine.

/Stefan

On 10-02-18 1:50 PM, "Manger, James H" <[email-masked]>
wrote:

> It might mean a little bit of SVG-specific code needs to appear in an
> otherwise generic "data URI"/"media type" block of code - but that's a very
> minor quibble.
> If someone has tried a data URI with SVG and with SVGZ in an existing tool
> that supports both, that would be ideal. Perhaps in an Opera browser?
> 
> My concern is resolved.
> 
> --
> James Manger
>