Subject: [pkix] Certimage example

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

Here is an example certificate image showing a certificate image for a
certificate which in a traditional UI looks like this:

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

The SVG image (viewable in all browsers except IE):
http://aaa-sec.com/pub/certimage/CertImageDemo-GunIngerPersson.svg

An equivalent jpg image:
http://aaa-sec.com/pub/certimage/CertImageDemo-GunIngerPersson.jpg

The actual SVG image is fully scalable without loosing sharpness and consist
of the following XML information:

<?xml version="1.0" standalone="no"?>
<svg contentScriptType="text/ecmascript" width="400.0px"
xmlns:xlink="http://www.w3.org/1999/xlink"
    baseProfile="full" zoomAndPan="magnify" contentStyleType="text/css"
height="300.0px"
    preserveAspectRatio="xMidYMid meet" xmlns="http://www.w3.org/2000/svg"
version="1.0">
    <g id="Shapes">
        <rect width="400.0" x="0.0" fill="#000066" height="40.5" y="0.0"
stroke="#000000"/>
        <rect x="-0.5" y="259.0" transform="matrix(1.0 0.0 0.0 1.5802469 0.0
-173.78395)" fill="#000033"
            width="400.0" height="40.5" stroke="#000000"/>
        <line fill="none" x1="25.0" x2="25.0" y1="67.5" y2="211.50002"
stroke="#000000"
            stroke-opacity=".2" stroke-width="2"/>
        <line fill="none" x1="25.5" x2="365.5" y1="102.0" y2="102.0"
stroke="#000000"
            stroke-opacity=".2" stroke-width="2"/>
        <line fill="none" x1="25.0" x2="365.0" y1="141.0" y2="141.0"
stroke="#000000"
            stroke-opacity=".2" stroke-width="2"/>
        <line fill="none" x1="25.5" x2="365.0" y1="176.5" y2="176.5"
stroke="#000000"
            stroke-opacity=".2" stroke-width="2"/>
        <line fill="none" x1="25.5" x2="365.0" y1="211.5" y2="211.5"
stroke="#000000"
            stroke-opacity=".2" stroke-width="2"/>
    </g>
    <g id="Certificate Info">
        <text x="78.0" y="20.0" id="Brand" transform="matrix(1.5550566 0.0
0.0 2.1454139 -109.28226 -15.569351)"><tspan
                fill="#ffffcc" xml:space="preserve" stroke-width=".5"
stroke="#f5c800">BankID</tspan></text>
        <text fill="#2e0642" x="40.08352" id="Certificate Type"
y="26.728981" transform="matrix(1.4111366 0.0 0.0 1.8448845 43.55606
-21.430695)"><tspan
                fill="#ffffff" xml:space="preserve" stroke-opacity="0"
stroke="#000000">Personal eID for Identification</tspan></text>
        <text x="12.5" y="54.0" id="Subject Frame Title"
transform="matrix(1.0 0.0 0.0 1.0 -4.5 -1.0)"><tspan
                stroke-width=".5" xml:space="preserve"
stroke="#000000">Issued to </tspan></text>
        <text fill="#000000" x="12.5" id="Issuer Frame Title" y="54.0"
transform="matrix(1.0 0.0 0.0 1.0 -8.0 196.0)"><tspan
                fill="#ffffff" xml:space="preserve" stroke-width="0.3"
stroke="#ffffff">Issuer</tspan></text>
    </g>
    <g id="Subject Info">
        <g id="Subject Attribute Labels">
            <text x="29.0" id="CommonName Attribute Label" y="77.5"
transform="matrix(1.0 0.0 0.0 0.9177735 0.0 5.666242)"
                stroke="#052020"><tspan fill="#000099" xml:space="preserve"
stroke-width="0.6"
                    stroke-opacity="0" stroke="#1d331d">Name </tspan></text>
            <text x="28.0" id="SerialNumber Attribute Label" y="118.22398"
transform="matrix(1.0 0.0 0.0 0.9177735 0.0 5.666242)"
                stroke="#052020"><tspan fill="#000099" xml:space="preserve"
stroke-width="0.6"
                    stroke-opacity="0" stroke="#1d331d">Civic Registration
Number</tspan></text>
            <text x="29.0" id="Organization Attribute Label" y="160.03757"
transform="matrix(1.0 0.0 0.0 0.9177735 0.0 5.666242)"
                stroke="#052020"><tspan fill="#000099" xml:space="preserve"
stroke-width="0.6"
                    stroke-opacity="0" stroke="#1d331d">Customer of
(Bank)</tspan></text>
            <text x="28.5" id="Country Attribute Label" y="198.89594"
transform="matrix(1.0 0.0 0.0 0.9177735 0.0 5.666242)"
                stroke="#052020"><tspan fill="#000099" xml:space="preserve"
stroke-width="0.6"
                    stroke-opacity="0" stroke="#1d331d">Country of
Registration</tspan></text>
        </g>
        <g id="Subject Attribute Values">
            <text x="29.57605" y="94.265594" id="Common Name Attribute
Value" stroke-width="0.6"
                transform="matrix(1.6234648 0.0 0.0 1.5821863 -21.464563
-49.556145)"><tspan
                    stroke-width="0.4" xml:space="preserve"
stroke="#000000">Gun Inger Persson</tspan></text>
            <text x="29.294779" y="119.06652" id="Serial Number Attribute
Value" stroke-width="0.6"
                transform="matrix(1.6234648 0.0 0.0 1.5821863 -21.464563
-49.556145)"><tspan
                    stroke-width="0.4" stroke="#000000"
xml:space="preserve">19350515-3742</tspan></text>
            <text x="30.526712" y="141.52856" id="Organization Attribute
Value" stroke-width="0.6"
                transform="matrix(1.6234648 0.0 0.0 1.5821863 -21.464563
-49.556145)"><tspan
                    stroke-width="0.4" stroke="#000000"
xml:space="preserve">Swedbank AB</tspan></text>
            <text x="30.526712" y="163.3631" id="Country Attribute Value"
stroke-width="0.6"
                transform="matrix(1.6234648 0.0 0.0 1.5821863 -21.464563
-49.556145)"><tspan
                    stroke-width="0.4" stroke="#000000"
xml:space="preserve">Sweden</tspan></text>
        </g>
    </g>
    <g id="Issuer Info">
        <text x="25.491337" stroke-width="0.6" y="175.57446" id="Issuer Name
Attribute Value"
            transform="matrix(1.2401435 0.0 0.0 1.3584048 -12.124399
31.136198)"><tspan fill="#c8c876"
                xml:space="preserve" stroke-width="0.5" stroke-opacity="0.5"
stroke="#000000">Example Trust BankID Certification Authority</tspan></text>
        <text x="24.50131" id="Issuer Info Compiled Attributes"
stroke-width="0.6" y="190.9802"
            transform="matrix(0.7663044 0.0 0.0 0.6924319 0.16282727
149.57846)"><tspan fill="#c8c876"
                xml:space="preserve" stroke-width="0.5" stroke-opacity="0.5"
stroke="#000000">Trusted Road 101, S-123 45 Stockholm, SWEDEN    Org#
551122-3344</tspan></text>
        <text x="24.50131" y="200.3674" id="Issuer Contact Info"
stroke-width="0.6" transform="matrix(0.7288873 0.0 0.0 0.6924319 2.0960374
153.07846)"><tspan
                fill="#c8c876" xml:space="preserve" stroke-width="0.5"
stroke-opacity="0.5" stroke="#000000">e-mail: [email-masked]@example.com
Web:www.example.com/trustedca</tspan></text>
    </g>
</svg>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Dec 2009 23:43:01 +0100

Alternative certificate for Signing could look like this:

SVG:
http://aaa-sec.com/pub/certimage/CertImageDemoSign-GunIngerPersson.svg

JPG:
http://aaa-sec.com/pub/certimage/CertImageDemoSign-GunIngerPersson.jpg

This certificate is distinguished from the former by a separate coloring of
the top frame.
The user, using these certificates frequently for accessing eGovernment
application would soon be able to quickly associate the different looking
eID certificates with their different usages (Identification and Signing)

/Stefan

On 09-12-08 11:30 PM, "Stefan Santesson" <[email-masked]> wrote:

>         <text x="78.0" y="20.0" id="Brand" transform="matrix(1.5550566 0.0 0.0
> 2.1454139 -109.28226 -15.569351)"><tspan
>         <text fill="#2e0642" x="40.08352" id="Certificate Type" y="26.728981"
> transform="matrix(1.4111366 0.0 0.0 1.8448845 43.55606 -21.430695)"><tspan
>         <text x="12.5" y="54.0" id="Subject Frame Title" transform="matrix(1.0
> 0.0 0.0 1.0 -4.5 -1.0)"><tspan
>                 stroke-width=".5" xml:space="preserve" stroke="#000000">Issued
> to </tspan></text>
>             <text x="29.57605" y="94.265594" id="Common Name Attribute Value"
> stroke-width="0.6"
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 9 Dec 2009 10:44:07 +1100

> Here is an example certificate image …

This image is a much better example to include in the spec because it is realistic -- both in its contents and size.
Including a simpler ASCII-art version in the spec would be nice as well :-)

>    baseProfile="full" zoomAndPan="magnify" contentStyleType="text/css" height="300.0px"

The contentScriptType="text/ecmascript" attribute was a concern to see.
Scripting is allowed in SVG Tiny, but should probably be disallowed in cert images.
It might be hard for an RP to disable scripting if it hands an SVG file to a standard SVG library on the device, but at least say "CAs MUST NOT include scripting in images".

P.S. This example is not SVG Tiny, which it needs to be to if it is used in the spec.
P.S. The email address in the footer with two @s looks invalid: [email-masked]@example.com

-- 
James Manger

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 09 Dec 2009 01:21:49 +0100

James,

On 09-12-09 12:44 AM, "Manger, James H" <[email-masked]>
wrote:

>> Here is an example certificate image Š
> This image is a much better example to include in the spec because it is
> realistic -- both in its contents and size.

I agree, with the points taken below.

> It might be hard for an RP to disable scripting if it hands an SVG file to a
> standard SVG library on the device, but at least say "CAs MUST NOT include
> scripting in images".
> 

Yes, all of these issues need to be fixed. The tool I used for this example
did not produce SVG Tiny unfortunately. But it hopefully works as an
illustrative example.

/Stefan

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Dec 2009 17:08:09 -0800

>did not produce SVG Tiny unfortunately. But it hopefully works as an

It did. You are now asking CAs to create certificates to use tools that are more difficult to configure than plain text. This introduces a security risk (particularly if they use a tool that accidentally places URLs in the certificates).

Please add this to the Security Considerations section of the next draft, in addition to the long list that others have brought up in the past few days.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Dec 2009 10:10:40 +0000

> It might be hard for an RP to disable scripting if it hands an SVG file to a standard SVG library on the device, but at least say "CAs MUST NOT include scripting in images".

I think getting this right is important if this document progresses
and I'm concerned that we're not the right people to specify this.
(Hence my going on about URLs in PDF/A yesterday.)

I personally don't know the right set of rules that CAs would
need to follow in preparing images or accepting (parts of) images,
nor would PKIX traditionally have that expertise.

Absent some field/security testing of running code, how will
we know we've done a good (enough) job and aren't producing an
RFC that does harm?

S.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 09 Dec 2009 11:52:40 +0100

Stephen,

We are extending a current RFC 3709 with one new image OID.

Yes we should try to do this right but in the end of the day, this is about
displaying an image from a trusted source, something that your browser does
everyday, but from non-trusted sources. This is not exactly rocket science.

I think the presence and contributions from both James Manger and Leonard
Rosenthol in the discussion shows that we have more than enough expertise to
extend one of our own standard RFCs.

/Stefan

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Dec 2009 11:37:58 +0000

> everyday, but from non-trusted sources. This is not exactly rocket science.

That is not an accurate characterisation of the problem.

Just for a moment, I'll accept the "legal signature" use case
is real, in which case:

One of the things you're trying to figure out are some "safe"
(technical) rules for CAs to use when preparing images for signing,
where those images will be used by untrained end-users in order to
select between presumably important credentials which are in a
form that those end-users definitely don't understand, and which
may have legal significance.

And this is to be deployed in an environment where the tools
that developers can use have a history of known vulnerabilities
triggered by bad images and where all of this image handling
detail is new to PKI developers.

I do not believe doing that right is trivial.

It may be that other communities (e.g. whoever's responsible for
PDF/A or SVG Tiny) have already done a lot of the work, though
I note that the former is an archive format and the latter is
a mobile display format. I don't know that security or safety
was a design goal for any of that work. For example, I only
find one occurrence of the word "security" in (what I think
is) the (not tiny:-) SVG Tiny specification [1] (outside of
the MIME type registration).

Even if others have done a lot of the work, you need to define
what's safe and what's not in a way that CA operators and RP
developers (and this list) can understand.

S.

[1] http://www.w3.org/TR/SVGTiny12/single-page.html

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 09 Dec 2009 13:20:01 +0100

Stephen,

I would still like to stress that it is important to understand what makes
this different from an author of web content creating an image that is
displayed in a web browser.

The only difference I can see that our case is more secure as the the image
is provided by a trusted source and is signed. Attacking a system with a
malicious image is hard enough for someone who is actively trying to exploit
the weakness of rendering code. Still we are capable of handling images on
the internet today with acceptable risk exposure. The risk drops with a
magnitude if you only display signed images from a trusted source.

As far as I can tell, the only thing the CA needs to do is to create an
image that complies to the standards and displays the expected result.

Including the following considerations:

1) Verify that the image is self contained (relevant for SVG only)

2) Don't include or render "clickable" links that could inspire a UI to
dereference URLs.

3) It is strongly advised to update the code base/library used to render
images and to use code that is actively evaluated and considered appropriate
for rendering images that are received over the internet, such as code used
in browsers. (possibly refer to some suitable http security considerations).

If you require more, then I think you have to provide some kind of plausible
attack scenario.

/Stefan

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Dec 2009 12:48:51 +0000

>From a cursory glance at the SVG Tiny spec, I'm not convinced
that that's the only restriction needed. For example, is the
systemLanguage conditional processing attribute allowed or not?
What about requiredExtensions?  I think James already mentioned
use of scripting. Is a new EvenTinier profile of SVG really
what's needed?

Has someone done that analysis?

> If you require more, then I think you have to provide some kind of plausible

I'd need an updated I-D first I think. There are too many open
issues now.

S.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 10 Dec 2009 12:54:19 +0100

Here is a better working example of a certImage that scales, is self
contained and is accurately tagged.

http://aaa-sec.com/pub/certimage/CertImageDemo.svg
http://aaa-sec.com/pub/certimage/CertImageDemo.svgz
http://aaa-sec.com/pub/certimage/CertImageDemo.pdf
http://aaa-sec.com/pub/certimage/CertImageDemo.png
http://aaa-sec.com/pub/certimage/CertImageDemo.xml

The svgz file is a compressed svg file. This one displays directly in
browsers like Opera and Google Chrome.

The xml version is just included for convenience if you want to view the
content of the svg image file.
This is still not SVG Tiny, but this one would allow to be converted to SVG
Tiny once I have got a good tool for it.

The B64 encoded svgz (which could be included in a data URL) looks like this
and takes up 2668 bytes of space:

/Stefan

On 09-12-08 11:43 PM, "Stefan Santesson" <[email-masked]> wrote:

> application would soon be able to quickly associate the different looking eID
> certificates with their different usages (Identification and Signing)
> 
> /Stefan
> 
>