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

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Dec 2009 08:35:48 +0100

Stephen,

Forwarding replies from Leonard Rosenthol, Adobe.

My own additional comments is that rendering the images is totally optional
and therefore there is no mandatory to render image format.

There is always the possibilities to provide the same image in multiple
formats to support a wider variety of clients. SVG may be the most
attractive candidate as a recommend to implement for scalable graphics as it
is becoming the browser standard.

Reject an image means to not display it. The language should be clarified.

I don't know SVG API's in detail. It does not strike me as overly complex to
verify that an image is self contained.

/Stefan

------ Forwarded Message
From: Leonard Rosenthol <[email-masked]>
Date: Mon, 7 Dec 2009 18:54:21 -0800
To: Stefan Santesson <[email-masked]>
Cc: "Bajaj, Siddharth" <[email-masked]>, Russ Housley
<[email-masked]>
Subject: RE: [pkix] WGLC for draft-ietf-pkix-certimage-03

1 - yes, it's true, there isn't an expectation that all readers can handle
all formats.

2 - the only format that support URLs is SVG and we recommend the use of
data URIs instead.  PDF/A is completely self-contained as are all th raster
formats.

3 - since SVG is the only format impact, and it's XML, I don't see the
issue.

4 - I am not aware of any vulnerabilities in the formats that we're
supporting.

Leonard

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Monday, December 07, 2009 6:11 PM
To: Leonard Rosenthol
Cc: Bajaj, Siddharth; Russ Housley
Subject: FW: [pkix] WGLC for draft-ietf-pkix-certimage-03

Leonard,

Do you have any good suggestions/reply on these issues posted on the PKIX
list today.

/Stefan

------ Forwarded Message
From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Dec 2009 12:14:07 +0000
To: <[email-masked]>
Subject: Re: [pkix] WGLC for draft-ietf-pkix-certimage-03

- 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.

------ End of Forwarded Message

------ End of Forwarded Message

---

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

Hi Stefan, Leonard,

> and therefore there is no mandatory to render image format.

I don't get that. If an RP implements this spec and is faced with
a cert containing an image it can't display then IMO we have an
interop failure. Specifying one or more MUST support image types
seems to me like what you'd need for this to actually work.

> is becoming the browser standard.

If you said CAs and RPs MUST support SVG that would be an answer.

> Reject an image means to not display it. The language should be clarified.

Ok. If that has no impact on path validation then that should also be
stated otherwise developers will mistakenly fail cert validation. In
that case I think you also need another security consideration to the
effect that if the RP rejects the image, then the CA cannot assume
that anything like terms & conditions embedded in the image have been
seen, even by applications that support this spec.

> verify that an image is self contained.

I wonder. More below.

> 1 - yes, it's true, there isn't an expectation that all readers can handle

Dealt with above.

> data URIs instead.  PDF/A is completely self-contained as are all th raster

I have seen many PDFs that contain URLs where the renderer allows me to
click on the URL. Is that prohibited by PDF/A?

If not, then there is a potential mismatch problem where the "secure"
certimage is presented, the user clicks on the URL within the image and
gets presented with results based on no security or a different
security context that may be problematic when the user is presumably
trying to decide whether to accept/use a cert or not.

In terms of raster formats, doesn't TIFF allow a single image
to contain multiple layers/views (don't know the right term) and
which is displayed can depend on the renderer/context. Does that
count as "self-contained"? Regardless, I think that issues like
that need to be called out somewhere if its the case for any of
the image types mentioned here.

So I don't think that presentation is as simple as claimed (though
this is not really my area) and I do think that more detail is
needed before you can really claim that these images can't cause
security problems that need to be documented in this spec. (I'm
not saying you need to solve those problems, but the spec needs
to acknowledge that they exist and offer guidance where possible.)

> 3 - since SVG is the only format impact, and it's XML, I don't see the

My point is that you need to list the restrictions on the type
of images allowed in certs (thus putting the onus on the CA to
do the right thing) and anything else dangerous that's left over
has to be such that an RP can easily check/enforce using the
kind of libraries that are available.

> 4 - I am not aware of any vulnerabilities in the formats that we're

The first hits I got when searching for "cve <foo>" for the
image types are below.

PDF/A:
http://www.ca.com/us/securityadvisor/virusinfo/virus.aspx?id=66876
SVG:
https://bugzilla.redhat.com/show_bug.cgi?id=506246
PNG (scroll to the end):
http://www.libpng.org/pub/png/libpng.html

There are *lots* more.

So there are clearly known security issues where malformed images
affect renderers. This spec should warn CA operators about the
more dangerous of those so CA operators can figure out how to
check supplied images. I realise that such warnings can't be
exhaustive or up-to-date, but right now they're totally missing.

Regards,
Stephen.

---

From: Leonard Rosenthol <[email-masked]>
Date: Tue, 8 Dec 2009 03:19:06 -0800

PDF/A restricts MANY things in PDF that remove the issues that you are concerned about - URLs, JavaScript, etc.  That's why it is the choice for many use cases over PDF itself as it offers a more secure solution.  

You should also be aware that the PDF, SVG, and PNG vulnerability you selected (as would be the case for ANY such format) are NOT vulnerabilities of the file format, they are vulnerabilities of specific implementations of the format (Adobe Reader, KSVG and libpng, in those specific cases).  

Leonard

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, December 08, 2009 5:51 AM
To: Stefan Santesson
Cc: pkix; Leonard Rosenthol
Subject: Re: FW: [pkix] WGLC for draft-ietf-pkix-certimage-03

Hi Stefan, Leonard,

I wonder. More below.

Dealt with above.

PDF/A:

There are *lots* more.

Regards,
Stephen.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Dec 2009 14:21:16 +0100

Stephen,

On 09-12-08 11:50 AM, "Stephen Farrell" <[email-masked]> wrote:
>><..>

This is an optional feature and unless this is used in a completely local
context, a certificate should work as normal without it.

It's tempting to mandate SVG, however I know one CA who plans to provide an
image just in PNG (raster graphic) to be displayed in their authentication
and signature plugin in order to display the user's own certificates when
selecting an appropriate certificate for access to eGov services.

I don't think it is reasonable to force them to support SVG in order to use
this standard.

>><..>

No this has no impact on path validation. I could add text to clarify this.

>><..>

I agree in principle that if there are security issues that an implementer
should consider, we should mention them.

I'm not sure whether you have any specific in mind or if this is just a
question whether there are any?

I personally see no issues with a PDF/A even if it would contain a
"clickable" URL, e.g. to a certificate policy document somewhere.
As long as the rendered image is a self-contained image provided by the CA,
I think we are good.

/Stefan

---

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

Hi Leonard,

> PDF/A restricts MANY things in PDF that remove the issues that you are concerned about - URLs, JavaScript, etc.  That's why it is the choice for many use cases over PDF itself as it offers a more s…

That's good to know. As I said its not my area. Just to check
though: is a renderer prohibited from enabling a user to click
on a URI that's part of a PDF/A document?

I did a quick check and the PDF at [1] which is all about
PDF/A does include a URL that I can click on from acrobat
reader. I assume that's a PDF/A document but I've not found
an easy way to be sure.

I think that clicking out of a certimage that way could be
undesirable and the spec needs to call that out and say what
the CA and/or RP should or should not do.

I'm not sure if there are any other features of the image
formats here that would need to be handled similarly.

> You should also be aware that the PDF, SVG, and PNG vulnerability you selected (as would be the case for ANY such format) are NOT vulnerabilities of the file format, they are vulnerabilities of spe…

Sure. But this spec. calls for inclusion of such code
inside or alongside PKI libraries, so those potential
vulnerabilities become relevant for CA and RP developers
as soon as support for this spec is added.

One might also expect that CAs would not include/link
problematic images in certs. The current draft says nothing
that'd help either a CA or RP developer in this respect. (I
think rfc 3709 should also have included such text btw, but
it doesn't.)

And just to re-iterate, I'm not asking that this draft
magically solve all these problems, just that it calls them
out as appropriate and offers guidance where possible.

Regards,
S.

[1]
http://www.pdf-tools.com/public/downloads/whitepapers/whitepaper-pdfa.pdf

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Dec 2009 13:49:18 +0000

Hi Stefan,

Couple of comments inline, but I suspect we're heading
towards diminishing returns on this thread for this version.

> context, a certificate should work as normal without it.

Disagree. If a CA implements this and an RP implements this and
there's a high probability nothing happens, then I think that's
an interop failure. With three formats the combinations will
tend to ensure such a high probability if each party just
supports one format.

> selecting an appropriate certificate for access to eGov services.

If its all their own code they don't need a standards-track
RFC.

> No this has no impact on path validation. I could add text to clarify this.

Good. I think the fact that the image may not get seen needs to
be noted. I can imagine legal nonsense accumulating otherwise.

> should consider, we should mention them.

Good.

> question whether there are any?

There are some. They should be mentioned. I'm not the document author:-)

> As long as the rendered image is a self-contained image provided by the CA,

Disagree. I'll bet a beer that'd generate a "PKI is crap" slashdot
article as soon someone crafts a dodgy example cert or does a bit
of DNS messing or causes a nice loop for the RP via an https URL.

Cheers,
S.

---

From: Leonard Rosenthol <[email-masked]>
Date: Tue, 8 Dec 2009 06:14:25 -0800

A "PDF/A conforming reader" (as defined by ISO 19005-1) is strongly recommend against activating the URL - that's why Adobe Reader doesn't let you do so.  However, at this time, Adobe's products (version 9 and later) are the only ones that conform to the specification.  So other viewers MAY (will) let you click - but then they aren't following ANY of the rules for PDF/A.

If you have Adobe Reader 9 (or later), you will know it's a PDF/A file as it will notify you accordingly.  I've enclosed a small PDF/A file with a link for you to test.

This spec calls for support for specific file formats - it says NOTHING about what libraries are to be used to read/process/render such images.  Just because one library that supports that format has a flaw, doesn't mean that all do.  

Leonard

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, December 08, 2009 8:38 AM
To: Leonard Rosenthol
Cc: Stefan Santesson; pkix
Subject: Re: FW: [pkix] WGLC for draft-ietf-pkix-certimage-03

Hi Leonard,

Regards,
S.

[1]

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Dec 2009 15:17:12 +0100

> towards diminishing returns on this thread for this version.

We may, but there is still some to gain from it :)

> tend to ensure such a high probability if each party just

Well, if it would be the WG consensus that we must have a MUST implement
image format for readers, I'd go for a self contained SVG Tiny image.

For now I just disagree that a MUST format is required. I'd be happy to add
a SHOULD implement for SVG.

I will craft an SVG example tonight and post to the list (warning for my
limited artistic skills).

> If its all their own code they don't need a standards-track

Well, this is all their code, however using their code and their
certificates for authentication and signing then their certificate will also
end up in other systems with other viewers. The chance for interoperability
increases if they follow a standard RFC.

However, their viewers will only view their own certificates, and thus, will
only need to support the image format of their choice.

> be noted. I can imagine legal nonsense accumulating otherwise.

Good suggestion. No CA can rely on these images being displayed. The choice
to display these images is totally at the discretion of the issuer.

> There are some. They should be mentioned. I'm not the document author:-)

I will do the editing, but if you can help point me to the issues we need to
address, I would be really grateful.

> of DNS messing or causes a nice loop for the RP via an https URL.

Hmm. Clicking on a link opens a separate web browser session that is totally
independent of this cert viewer. I'm not sure how that can create a loop
even if validating that server certificate involves the same certificate.
Especially not since the user need to click on the link to reiterate the
loop.

Maybe it's just me, but I have a problem understanding why it would be
dangerous to view a signed and authenticated PDF/A with a "clickable" URL
from a CA you trust. Could you provide a threat scenario?

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Dec 2009 15:28:02 +0100

Corrections on my previous post:

> to display these images is totally at the discretion of the issuer.

Oups....

That was of course meant to say "at the discretion of the RP"

> from a CA you trust. Could you provide a threat scenario?

I guess this is a non issue anyway according to Leonard's clarification.

I'd be happy to add text that reinforce that a PDF/A certimage MUST NOT
contain such URLs.

/Stefan

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Dec 2009 14:45:04 +0000

> A "PDF/A conforming reader" (as defined by ISO 19005-1) is strongly recommend against activating the URL - that's why Adobe Reader doesn't let you do so.  However, at this time, Adobe's products (v…

I think that's a relevant thing to note in the draft (i.e. some
politically correct way of saying the same thing). In particular
if "strongly recommended against" means that they MAY activate
the URL.

> If you have Adobe Reader 9 (or later), you will know it's a PDF/A file as it will notify you accordingly.  I've enclosed a small PDF/A file with a link for you to test.

Thanks. Will try it later. (Don't have that reader)

> This spec calls for support for specific file formats - it says NOTHING about what libraries are to be used to read/process/render such images.  Just because one library that supports that format h…

Right. They each have different sets of flaws;-)

I'd claim that experience shows that vulnerabilities like these
constantly occur in most all libraries & tools, and this spec is
asking the CA and RP to trust images (for some definition of
"trust," the details of which don't matter right now), which is
basically a new thing for PKI tools/libraries (*) so I think its
important to note and give whatever guidance is possible.

S.

(*) I say this is a new thing because afaik 3709 isn't really
implemented.

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 8 Dec 2009 15:47:30 +0100

Leonard,

Thanks for providing the pdf file. It reinforces one of my points. 

This small PDF/A file is 48 kbytes long.

If a single image is included within the certificate, how many certificates will I be able to store on my smart card ?

If two images are included within the certificate, how many certificates will I be able to store on my smart card ?
Denis

----- Message reçu ----- 
De : pkix-bounces 
À : 'Stephen Farrell' 
Date : 2009-12-08, 15:14:25
Sujet : Re: [pkix] FW: WGLC for draft-ietf-pkix-certimage-03

Pièce(s) Jointe(s) au message original :
  (1). This is a test of a URL.pdf

Leonard

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, December 08, 2009 8:38 AM
To: Leonard Rosenthol
Cc: Stefan Santesson; pkix
Subject: Re: FW: [pkix] WGLC for draft-ietf-pkix-certimage-03

Hi Leonard,

Regards,
S.

[1]

>> ------ End of Forwarded Message

_____________________ next part ______________________

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Dec 2009 14:53:54 +0000

> increases if they follow a standard RFC.

...only if that standard RFC has e.g. some MUSTs so the chances of
it working are high enough.

> only need to support the image format of their choice.

So they don't care then.

> address, I would be really grateful.

Sorry, I really don't have (more) time, and am not familiar enough
with image-format related vulnerabilities in any case. I think the
onus should fairly be on those proposing this to have done the
threat analysis  and to document that sufficiently. I can't see
that that's happened. (It may have, but its not in the document
or anywhere else that I can see.)

> from a CA you trust. Could you provide a threat scenario?

Isn't it obvious?

De-referencing via http can result in random garbage instead
of whatever the CA intended to be seen. Maybe that garbage
looks like a certimage.

De-referencing via https usually results in a new certificate
validation, which may result in a new certimage presentation
that looks just like the last one. So the user thinks nothing
happened and clicks that URL again. Fun.

S.

---

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

Denis, 

I will soon provide you with an SVG example that will be considerably
smaller.

/Stefan

On 09-12-08 3:47 PM, "Denis Pinkas" <[email-masked]> wrote:

> If a single image is included within the certificate, how many certificates
> will I be able to store on my smart card ?
>  
>> De  : pkix-bounces <mailto :[email-masked]>
>>  
>> À  : 'Stephen Farrell' <mailto :[email-masked]>
>>  
>> A "PDF/A conforming reader" (as defined by ISO 19005-1) is strongly
>> recommend against activating the URL - that's why Adobe Reader doesn't let
>> you  do so. However, at this time, Adobe's products (version 9 and later) are
>> the  only ones that conform to the specification. So other viewers MAY (will)
>> let  you click - but then they aren't following ANY of the rules for  PDF/A.
>> 
>> If you have Adobe Reader 9 (or later), you will know it's a  PDF/A file as it
>> will notify you accordingly. I've enclosed a small PDF/A file  with a link
>> for you to test.
>> 
>> This spec calls for support for specific  file formats - it says NOTHING
>> about what libraries are to be used to  read/process/render such images. Just
>> because one library that supports that  format has a flaw, doesn't mean that
>> all do.  
>> 
>> Leonard
>> 
>> From: Stephen Farrell  [mailto:[email-masked] <mailto:
>> [email-masked]> ]
>>> > PDF/A restricts MANY things in PDF that remove the issues that  you are
>>> concerned about - URLs, JavaScript, etc. That's why it is the choice  for
>>> many use cases over PDF itself as it offers a more secure solution.
>> 
>>> > You should also be aware that the PDF, SVG, and  PNG vulnerability you
>>> selected (as would be the case for ANY such format) are  NOT vulnerabilities
>>> of the file format, they are vulnerabilities of specific  implementations of
>>> the format (Adobe Reader, KSVG and libpng, in those  specific cases).
>> 
>>> > From:  Stephen Farrell [mailto:[email-masked] <mailto:
>>> [email-masked]> ]
>>>> >> From: Leonard Rosenthol <[email-masked] <mailto: [email-masked]>
>
>>>> >> To: Stefan Santesson <[email-masked] <mailto: [email-masked]> >
>>>> >> Cc:  "Bajaj, Siddharth" <[email-masked] <mailto:
>>>> [email-masked]> >, Russ  Housley
>>>> >> <[email-masked] <mailto: [email-masked]> >
>>>> >> From: Stefan Santesson [mailto:[email-masked] <mailto:
>>>> [email-masked]> ]
>>>> >> From: Stephen Farrell <[email-masked] <mailto:
>>>> [email-masked]> >
>>>> >> To: <[email-masked] <mailto: [email-masked]> >
>> [email-masked] <mailto: [email-masked]>

---

From: Leonard Rosenthol <[email-masked]>
Date: Tue, 8 Dec 2009 07:07:02 -0800

I wasn't producing a sample for size - just a sample to demonstrate URLs.

If you want to see a small sample, I can make of those....

But there is no question that PDF/A is NOT optimized for size...it's optimized for reliable storage.

Leonard

From: Stefan Santesson [mailto:[email-masked]]
Sent: Tuesday, December 08, 2009 10:02 AM
To: [email-masked]; pkix
Cc: Leonard Rosenthol
Subject: Re: [pkix] FW: WGLC for draft-ietf-pkix-certimage-03

Denis,

I will soon provide you with an SVG example that will be considerably smaller.

/Stefan

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

Leonard

-----Original Message-----
From: Stephen Farrell  [mailto:[email-masked] <mailto: [email-masked]> ]
Sent: Tuesday, December 08, 2009 8:38 AM
To: Leonard Rosenthol
Cc:  Stefan Santesson; pkix
Subject: Re: FW: [pkix] WGLC for  draft-ietf-pkix-certimage-03

Hi Leonard,

Regards,
S.

[1]

> From:  Stephen Farrell [mailto:[email-masked] <mailto: [email-masked]> ]
>> From: Leonard Rosenthol <[email-masked] <mailto: [email-masked]> >
>> Cc:  "Bajaj, Siddharth" <[email-masked] <mailto: [email-masked]> >, Russ  Housley
>> From: Stefan Santesson [mailto:[email-masked] <mailto: [email-masked]> ]
>> From: Stephen Farrell <[email-masked] <mailto: [email-masked]> >

________________________________
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

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

Leonard,

I strongly agree with you:
"there is no question that PDF/A is NOT optimized for size…it’s optimized for reliable storage."
So why I think that PDF/A should NOT be mentionned in the draft.
This would also simplify interoperability issues.

Denis
---------- 
De : Leonard Rosenthol 
À : Stefan Santesson,[email-masked],pkix 
Date : 2009-12-08, 16:07:02
Sujet : RE: [pkix] FW: WGLC for draft-ietf-pkix-certimage-03

I wasn’t producing a sample for size – just a sample to demonstrate URLs.
If you want to see a small sample, I can make of those….
But there is no question that PDF/A is NOT optimized for size…it’s optimized for reliable storage.
Leonard
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, December 08, 2009 10:02 AM
To: [email-masked]; pkix
Cc: Leonard Rosenthol
Subject: Re: [pkix] FW: WGLC for draft-ietf-pkix-certimage-03
Denis, 

/Stefan

 

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

À  : 'Stephen Farrell' <mailto :[email-masked]>  

 

 

Leonard

-----Original Message-----
From: Stephen Farrell  [mailto:[email-masked] <mailto: [email-masked]> ]  
Sent: Tuesday, December 08, 2009 8:38 AM
To: Leonard Rosenthol
Cc:  Stefan Santesson; pkix
Subject: Re: FW: [pkix] WGLC for  draft-ietf-pkix-certimage-03

Hi Leonard,

Regards,
S.

[1]

> If you said CAs and RPs MUST support SVG  that would be an answer..
> 
> stated otherwise  developers will mistakenly fail cert validation.. In
> to acknowledge that they  exist and offer guidance where possible..)
>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Dec 2009 16:27:59 +0100

Stephen,

Not sure this is worth the bandwidth, since we can and should not allow
URLs. But anyway...

> of whatever the CA intended to be seen. Maybe that garbage

How would de-referencing a URL provided by the CA lead to garbage that
differs from what the CA intended when placing this URL in the certimage.
Sorry, this is not obvious to me.

> happened and clicks that URL again. Fun.

Before a new certificate validation it would open a new web browser window,
showing new content and the new certificate image would be shown in that
context (if this was implemented by a browser). Eventually the user would
see new browser windows popping up with new cert UIs and eventually would
stop clicking the same link over and over again without substantial harm
being caused to anyone.

/Stefan

---

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

> Sorry, this is not obvious to me.

Thanks to an attacker.

> Before a new certificate validation it would open a new web browser window,

How do you know? It doesn't say that and implementing it all
within one app shouldn't be non-compliant. The app could also
just be a browser of course.

> stop clicking the same link over and over again without substantial harm

Is that usable? How about if all certs in a chain have certimages?
What if they're also in CRLs or OCSP responder certs? I thought the
point of this was to improve usability?

The more I think about it, the more this seems like it should be
tested first and/or be experimental or just remain as a draft.

S.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Dec 2009 16:42:36 +0100

Stephen,

> important to note and give whatever guidance is possible.

We are allowing a CA to create and compile an image that is rendered by the
RP IF the RP trust the CA to provide such image.

In the daily use of the Internet we render images downloaded from
non-trusted sources every day, and that is considered OK.

I this case we are rendering an image compiled by a trusted authority.

It's kind of obvious that implementers should not use libraries with known
bugs, but even if they did, I think they would be safe in this case.

/Stefan

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Dec 2009 15:52:25 +0000

Stefan Santesson wrote:
> We are allowing a CA to create 

s/create/accept/ - private key holders will provide the
images; CAs need to check they're ok and need to know
what to check since that's not afaik something they
currently do.

> and compile an image that is rendered by the

There's no per-CA control on this that I can see. The RP
either does or doesn't implement the spec. Unless you're
proposing a modification to TAMP for this as well or
something;-)

> non-trusted sources every day, and that is considered OK.

Yes. But you're arguing that this image will help people
to judge credentials. That is different. Maybe its like the
green location bar in EV-certs, but its not like any old
favicon.

> I this case we are rendering an image compiled by a trusted authority.

s/compiled/signed/

> bugs, 

In which universe does that happen? Implementers will use
existing, rather complex, image libraries, they won't write
that code from scratch.

> but even if they did, I think they would be safe in this case.

Disagree. At least as currently specified.

S.

PS: Have we diminished the returns sufficiently yet? ;-)

---

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

Stephen,

>> Sorry, this is not obvious to me.

I'll run this off-line with you until I understand your scenario. You are
not providing any details that helps me understand what the attacker does.

> just be a browser of course.

How about common sense?

What is the likely hood that a certificate UI would implement it's on
complete browser in order to dereference URLs in certimages?

It would not be non-conformant, just incredibly redundant.

> point of this was to improve usability?

Yes, that is usable. In any certificate UI today, you are ONLY viewing one
certificate at the time and typically you are only interested in the EE
certificate.

In all these situations, you are typically only using the UI enhancement of
the particular certificate you are interested in, e.g. The signer of a
document. The rest are of no interest for you to see.

> tested first and/or be experimental or just remain as a draft.

Compared with other incredibly complex standards we have produced, this one
is is probably one of the simplest, and it is just defining 1 new OID for
one new image type of RFC 3709.

The concept of using it is dead simple:

CA -> Generate one (or more) image and bind it to the certificate

RP -> IF CA is trusted then display this image as a representation of the
certificate where it makes sense. RP owns the UI and decides when, if at all
to use the image.

/Stefan

---

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

Stephen,

> what to check since that's not afaik something they

Maybe this is the core of the misunderstandings.

This is entirely wrong. The CA will compile the certificate image based on
the data it has collected and verified about the subject.

This will include textual representation of the subject name, organization,
serialNUmber, country etc.

The image MAY also contain things like logotypes provided by the private key
holder, which is processed by the CA before incorporating it into the
certificate image. 

This aspect is however safer than using the RFC 3709 logotypes where the
image from the private key holder is just signed as is.

Maybe we should hold off the discussion until I have provided an SVG sample
of what a certificate image could look like.

/Stefan

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Dec 2009 16:15:54 +0000

> the data it has collected and verified about the subject.

Where does it say that?

S.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Dec 2009 17:31:04 +0100

>From section 2.
---------------
   When present the Certificate Image MUST represent a complete visual
   representation of the certificate. This means that the display of
   this certificate image represents all information about the
   certificate that the issuer subjectively defines as relevant to show
   a typical human user within the typical intended use of the
   certificate, giving adequate information about at least the following
   three aspects of the certificate:

      - Certificate Context
      - Certificate Issuer
      - Certificate Subject

   Certificate Context information is visual marks and/or textual
   information which helps the typical user to understand the typical
   usage and/or purpose of the certificate

   It is up to the issuer to decide what information in the form of text
   and graphical symbols and elements, which represents a complete
   visual representation of the certificate.
---------------

Well, this is what this text is supposed to say. Suggested improvements are
welcome but it is hard to provide information about the subject without
adding any textual information derived from the subject name attributes or
relevant AltNames.

/Stefan

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Dec 2009 16:45:51 +0000

>>> the data it has collected and verified about the subject.
...

I read that. It never says anywhere who creates the image, nor based
on what. (It says what should be included, not who does it nor how).
If you added all the text from your previous mail as normative
requirements, that would certainly help with some of the issues
raised.

S.

---

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

Thanks Stephen,

It's easy to drown in your own material.
I though of this as an obvious consequence that the CA have to create this
image in order to provide this information, but as you say, it's not
explicitly stated.

I will add normative text about this.

/Stefan

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 08 Dec 2009 18:11:00 +0100

Denis Pinkas wrote:
> This _small_ PDF/A file is 48 kbytes long.
>  
> If a single image is included within the certificate, how many 
> certificates will I be able to store on my smart card ?
>  
> If two images are included within the certificate, how many 
> certificates will I be able to store on my smart card ?
> Denis

You are obviously referring to the form of smart cards that were 
designed some 15 years ago.

Nowadays mere mortals have gigabytes of cheap storage in their pockets.

One day even an ultra-conservative industry segment like the smart card 
vendors will realize that you don't need to put everything in expensive 
"secure silicon", just a symmetric "master-key", while private keys 
(encrypted by the master-key), certificates and and images are put in 
dirt-cheap Flash.

I is possible that you will buy your next token at a Wal-mart (or other 
similar) store because such a smart card can be housed in a slightly 
upgraded memory stick!   Unlike your technically dated and space-limited 
smart card, it can also be securely provisioned on-line from any "PC" 
using a standard browser:
http://webpki.org/papers/keygen2/secure-key-store.pdf

Anders

---

From: Nelson B Bolyard <[email-masked]>
Date: Tue, 08 Dec 2009 09:25:31 -0800

>> My own additional comments is that rendering the images is totally
>> optional and therefore there is no mandatory to render image format.
> 
> I don't get that. If an RP implements this spec and is faced with a cert
> containing an image it can't display then IMO we have an interop failure.
> Specifying one or more MUST support image types seems to me like what
> you'd need for this to actually work.

On which of the three 7-segment displays on my embedded device MUST this
cert image be displayed?

---

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

Hi Nelson,

None. There is no requirement for this image to be displayed.

/Stefan

---

From: Andrea Caccia <[email-masked]>
Date: Tue, 8 Dec 2009 19:38:28 +0100

It's quite difficult to jump on any specific point of this long discussion, I'd like to add some thoughts:
- a real use (it was an idea from a customer) is to use certificates to store a scan copy of the handwritten signature (for human beings) or official stamp (for legal entities). This could be relevant for the work that is ongoing on visible signature in OASIS/DSS-X and ETSI/ESI
- I think that not allowing referencing external objects we miss a lot of opportunities. Among which:
  - storing large objects (large wrt common certified smart cards that must be able to carry the certificate) and
  - granting access control on the pointed object. In case of i.e. a fingerprint or a photo, the certificate owner possibly do not want these info become publicly available. It he/she can make available the pointed data only to relevant parties, that parties can check the authenticity of that data
- it is responsibility of the CA (possibly via its RA's) to guarantee the correctness of the associated data, being it in the certificate or external
- it is responsibility of the CA to make available the data on its servers or delegate someone else to supply this service under its supervision. I see a similar responsibility than making available the CRL or an OCSP server for all the lifecycle of the certificate. Possibly the pointed object can be made available on an HTTP server whose certificate can contain a specific extended key usage for this usage
- usage of the data, being displaying an image or supply biometric data for an access control system is a matter of the context. It data has to be i.e. displayed or understood, then the extension has to be set critical
- If the pointed object is a PDF/A, it has a guaranteed and standard representation. If pointed data is an electronic copy of ID Cart or a driver license, a certified copy can be retrieved in a secure way. It can be also a representation of the card containing the chip: if it is a national ID card, it is more difficult to forge it (e.g. changing the photo)
- in general I think this technology can be useful when you have a "Hybrid" scenario, not fully paperless, where some of the stakeholders still want to have paper documents or a representation of them, having also some of the guaranteed that came form PKI technologies.

Hope it helps,
Andrea

---

From: Stephen Wilson <[email-masked]>
Date: Wed, 09 Dec 2009 06:50:33 +1100

As Andrea says, it's tricky jumping in on this.  But what the hell ...

I just wanted to question whether standardising the way images are 
conveyed in certificates is worth all the effort?  Images are for 
humans, but for the most part, digital certificates are for machines. 

Aren't 99.9% of digital signatures and certificates are processed 
straight-through by computers?  The idea that strangers Alice and Bob 
will use one another's certificates to establish "trust" is almost a 
caricature of what went wrong with PKI in the first place.  Fifteen 
years ago the notion was that Alice and Bob would open up the 
certificates, find the CP/CPS, read these documents, and make a trust 
decision.  I cannot see that augmenting a certificate with an image 
makes any difference.

Cheers,

Stephen Wilson
Managing Director
Lockstep Group

Phone +61 (0)414 488 851

www.lockstep.com.au <http://www.lockstep.com.au>

Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.  Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.

---

From: Stephen Wilson <[email-masked]>
Date: Wed, 09 Dec 2009 06:54:49 +1100

Anders,

This sort of thinking (memory is cheap cheap cheap) is what got 
Microsoft and others into so much trouble, with flabby, unconstrained 
software development.  There is never any excuse for undisciplined data 
structure design, regardless of how much storage you have.

Cheers,

Stephen Wilson
Lockstep Group

Anders Rundgren wrote:
> One day even an ultra-conservative industry segment like the smart 
> card vendors will realize that you don't need to put everything in 
> expensive "secure silicon", just a symmetric "master-key", while 
> private keys (encrypted by the master-key), certificates and and 
> images are put in dirt-cheap Flash.
>
> I is possible that you will buy your next token at a Wal-mart (or 
> other similar) store because such a smart card can be housed in a 
> slightly upgraded memory stick!   Unlike your technically dated and 
> space-limited smart card, it can also be securely provisioned on-line 
> from any "PC" using a standard browser:

---

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

Hi Stephen,

It is a bit misleading to talk about when you need to see a certificate.

The important start question is: Do humans (here termed the user) need to
know who they communicate with, alternatively who is the originator,
recipient of some information or who committed to an agreement with them?

If the answer is yes, then one have to ask, what is the source of this
information?

If the technology used is PKI (or else it is out of scope of this WG), then
this information is derived from the certificate representing the
authenticated subject.

Then one have to ask: Can a UI derive useful information about the
authenticated subject from the certificate and present that to the user?

Well, the answer is no, except for very closed environments. There is no
generic UI today that can accomplish this task.

As a result: If you receive a signed e-mail, if you verify the signature of
a signed document, e.g. Pdf, if you received signed code to install in your
computer or if you verify the identity of a service somewhere, then there is
no user friendly information available informing the user who the
authenticated signer/opponent is.

Basically the UIs in general are terribly bad, even for a detailed view of
web server identities.

We have devised the most superior math to prove the identity of the opponent
using the most superior and secure protocols, but we have no way of
extending that information to a normally skilled human being.

Is it worth fixing?  Well I suspect you know my answer :)

I'd bury this draft under three tons of rock any day anyone can show me
another solution that works which is better and more implementation friendly
than the present one.

Cheers

/Stefan

On 09-12-08 8:50 PM, "Stephen Wilson" <[email-masked]> wrote:

>> - a real use (it was an idea from a customer) is to use certificates to store
>> a scan copy of the handwritten signature (for human beings) or official stamp
>> (for legal entities). This could be relevant for the work that is ongoing on
>> visible signature in OASIS/DSS-X and ETSI/ESI
>>   - granting access control on the pointed object. In case of i.e. a
>> fingerprint or a photo, the certificate owner possibly do not want these info
>> become publicly available. It he/she can make available the pointed data only
>> to relevant parties, that parties can check the authenticity of that data
>> - it is responsibility of the CA (possibly via its RA's) to guarantee the
>> correctness of the associated data, being it in the certificate or external
>> - it is responsibility of the CA to make available the data on its servers or
>> delegate someone else to supply this service under its supervision. I see a
>> similar responsibility than making available the CRL or an OCSP server for
>> all the lifecycle of the certificate. Possibly the pointed object can be made
>> available on an HTTP server whose certificate can contain a specific extended
>> key usage for this usage
>> - usage of the data, being displaying an image or supply biometric data for
>> an access control system is a matter of the context. It data has to be i.e.
>> displayed or understood, then the extension has to be set critical
>> - If the pointed object is a PDF/A, it has a guaranteed and standard
>> representation. If pointed data is an electronic copy of ID Cart or a driver
>> license, a certified copy can be retrieved in a secure way. It can be also a
>> representation of the card containing the chip: if it is a national ID card,
>> it is more difficult to forge it (e.g. changing the photo)
>> - in general I think this technology can be useful when you have a "Hybrid"
>> scenario, not fully paperless, where some of the stakeholders still want to
>> have paper documents or a representation of them, having also some of the
>> guaranteed that came form PKI technologies.
>> 
>> Hope it helps,
>> Andrea
>> 
>> 
>

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 08 Dec 2009 22:35:32 +0100

Stephen,

I think that putting an equal-sign between large storage size and sloppy 
software
was a bit premature since my proposal is not about bloatware but about 
making it practical
carrying a huge number of credentials in a single package.  Who would 
want that?
Well, the password explosion on the Internet needs a better solution 
than "PostIt".
InformationCards is an example of credentials that are way out of reach 
for traditional
smart cards.  Certimage is sort of a PKI-version of InformationCards.

Anders

Stephen Wilson wrote:
> software development.  There is never any excuse for undisciplined 
> data structure design, regardless of how much storage you have.
>
> Cheers,
>
> Stephen Wilson
> Lockstep Group
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 8 Dec 2009 23:15:15 +0100

>another solution that works which is better and more implementation friendly

I think you should limit this statement to the core principle (i.e. using an
image as a visual representation of a credential) since there are at
least two competitors to the actual draft.  One is the already
standardized OASIS IMI which has been shipping since IE7.

Another challenger is my brain-child the SKS.

It is though true that your draft takes the image notion one step further
since it also involves RPs.  Personally, I think this is a fundamentally
flawed idea, particularly if the image is related to human and not to a brand,
organization or similar.  I.e. you are trying to solve two *entirely
different* problems with a single solution and that will make CAs
quite uncomfortable.  The (mentioned) lack of images samples is
a bad sign.

Anders

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 09 Dec 2009 12:29:02 +1300

Leonard Rosenthol <[email-masked]> writes:

>A "PDF/A conforming reader" (as defined by ISO 19005-1) is strongly recommend 
>against activating the URL - that's why Adobe Reader doesn't let you do so.  
>However, at this time, Adobe's products (version 9 and later) are the only 
>ones that conform to the specification.  So other viewers MAY (will) let you 
>click - but then they aren't following ANY of the rules for PDF/A.

Hmm, so if I interpret this correctly you're saying that there's a single 
product that conforms to the requirements and that's one that's been 
notoriously vulnerable to PDF security issues.  

This does not strike me as a good thing to encode into a security spec.

Peter.

---

From: Leonard Rosenthol <[email-masked]>
Date: Tue, 8 Dec 2009 15:37:30 -0800

Actually, all vulnerabilities discovered against Adobe Reader have been with POC documents that would NOT pass compliance with PDF/A - so, as stated earlier, the use of PDF/A would avoid all such issues.

That said, it is also unfortunate that other vendors of PDF viewers have not complied with this standard (which was published in 2005).

Leonard

-----Original Message-----
From: pgut001 [mailto:[email-masked]] On Behalf Of Peter Gutmann
Sent: Tuesday, December 08, 2009 6:29 PM
To: Leonard Rosenthol; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] FW: WGLC for draft-ietf-pkix-certimage-03

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 09 Dec 2009 12:47:40 +1300

>humans, but for the most part, digital certificates are for machines. 

There's more to it than that.  We know from numerous usability studies of 
general (non-PKI-expert) users [0] that virtually no-one ever looks at certs, 
and of the minute percentage of people who do, no-one understands what they're 
seeing.  Putting an image in there isn't going to change this.

Having said that, since PKIX will publish RFCs on absolutely anything I don't 
have any real objection to publishing this one as well.  It's not as if anyone 
has to pay any attention to it.

Peter.

[0] I'm on a different machine at the moment so can't include the refs, I
    can dig them up if required.

---

From: max pritikin <[email-masked]>
Date: Tue, 8 Dec 2009 17:55:49 -0600

> seeing.  Putting an image in there isn't going to change this.

I'm not convinced that putting "an image" isn't going to change this.  
I think there are substantial examples of "brick and mortar  
images" (read: signs, logos, trademarks, etc) that help consumers  
tremendously. I do agree that an image form of the existing textual  
data, such as in the examples recently posted, probably won't address  
the core problems.

- max

---

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

Peter,

> seeing.  Putting an image in there isn't going to change this.

You are missing the point.

First of all, of course no-one clicks on Certificates the way UI works
today, that is of no relevance. If clicking a "details" link is needed to
obtain the cert image, then you are of course right.

The question is whether you have any business knowing who a signer is, who
you are talking to or if you ever have any reason to see the credentials you
are choosing among.

If you agree that this could be useful, then please tell me how a UI can
provide this information out of the information it can find in a normal
certificate.

If you don't want to obtain this information from the certificate, then
please tell me what magic source you are using.

/Stefan

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 09 Dec 2009 14:10:17 +1300

Leonard Rosenthol <[email-masked]> writes:

>Actually, all vulnerabilities discovered against Adobe Reader have been with 
>POC documents that would NOT pass compliance with PDF/A - so, as stated 
>earlier, the use of PDF/A would avoid all such issues.

Hmm, not wanting to get into a debate over the pros and cons of PDF readers 
(note that I very carefully avoided mention anything related to "bloatware" in 
my previous message :-), people don't install a reader purely to read PDF/A, 
they end up reading all PDFs with it.  So by installing Acrobat so you can 
read PDF/A you're also getting all the security issues that come with it for 
non-/A forms.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 09 Dec 2009 14:13:46 +1300

>provide this information out of the information it can find in a normal

No-one knows of any way to do this, and every indication we have from numerous 
user studies is that users don't know and don't care.  As long as they see a 
padlock somewhere, either in the chrome or on the web page itself, you're OK. 
It's purely a boolean value, bCanUseTheDamnThing.

Peter.

---

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

>You are missing the point.

Given the long and thoughtful responses from people other than the document authors in the past few days, possibly it is you who is missing the point.

>provide this information out of the information it can find in a normal

In the same way you put together the examples, but as a single text field.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 09 Dec 2009 02:30:57 +0100

Paul,

> In the same way you put together the examples, but as a single text field.

Please provide me with an example of what such single text field that makes
sense to an uneducated person would look like.

Isn't that quite obvious that this is not possible in the given example?

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 09 Dec 2009 02:43:24 +0100

Peter,

On 09-12-09 2:13 AM, "Peter Gutmann" <[email-masked]> wrote:

> No-one knows of any way to do this

Just out of curiosity. What is it in the certimage example that fails to
provide useful information?

>, and every indication we have from numerous

Web certificates are not the only use case. In eGovernment services users
are confronted with the choice of eID for signing and identification.

In the implementation of the services directive, signed documents are
exchanged where the identity of the signer (e.g. Point of single contact)
needs to be communicated.

You can't look at studies that does not apply on the problems you are trying
to solve. We need a way to obtain a user friendly representation of the
authenticated identity, and I'm interested to learn if you have any better
proposal.

/Stefan

---

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

>sense to an uneducated person would look like.

It has the same layout and format as the one you used. Tag: value<cr>.

>Isn't that quite obvious that this is not possible in the given example?

That is not the part that I find "quite obvious".

---

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

Paul,

> It has the same layout and format as the one you used. Tag: value<cr>.

But you don't have access to the meta information contained in the
certimage! 

All you have as information source is the attribute values:

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

That's it.

My certimage contains much more granular display metadata information:
http://aaa-sec.com/pub/certimage/CertImageDemo-GunIngerPersson.svg
http://aaa-sec.com/pub/certimage/CertImageDemo-GunIngerPersson.jpg

There is a delta in the information that the CA have no way to encode into
the attribute values. The rest have to go into policy identifiers that are
useless to the UI.

But the CA can put this display metadata into the cert image.

Please provide an explicit example out of the data above if you disagree.

/Stefan

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Dec 2009 19:18:34 -0800

>But you don't have access to the meta information contained in the

Yes, I do. I (the CA) has the same metainfo to create a text representation as I do to create a visual representation. If not, where did you (the visual CA) get your metainfo?

>the attribute values. The rest have to go into policy identifiers that are

They could go into a new field that holds this metainfo, formatted in the fashion described in the PKIX extension that defines the field. That way, the application only needs to parse text (which it knows how to do), not have a display engine.

>But the CA can put this display metadata into the cert image.

Then it could put it into a text field as well.

>Please provide an explicit example out of the data above if you disagree.

I already did that.

---

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

Paul,

Thank you for the clarification. This makes absolute sense and is definitely
worth discussing.

On 09-12-09 4:18 AM, "Paul Hoffman" <[email-masked]> wrote:
> Yes, I do. I (the CA) has the same metainfo to create a text representation as
> I do to create a visual representation. If not, where did you (the visual CA)
> get your metainfo?
> 

Absolutely. The CA can provide metadata for enhancing the certificate UI
instead of an image. The two approaches have different pros and cons and are
not necessarily mutually excusive.

> They could go into a new field that holds this metainfo, formatted in the
> fashion described in the PKIX extension that defines the field.

Agreed, so far

> That way, the 
> application only needs to parse text (which it knows how to do), not have a
> display engine.
> 

The UI application does not need to know how to display an image, but
instead it needs to learn how to use this metadata to display certificate
information.

Structured UI metadata (text based) versus an image is a valid discussion.
When approaching this issue I started evaluating the possibility to create
standard describing structured UI metadata. This could be done as an
extension of the RFC 3739 QCStatements extension or as a new certificate
extension.

I produced various proposals (internally at Microsoft) on how such
structured metadata would look like. It needs to contain quite some
information to be useful and generic:
 
- Display labels for attributes and name forms (e.g. "Civic Registration
Number" as label for the data provided in SerialNumber etc). This need to
support multilingual presentation.

- Other metadata describing the type and nature of the Certificate/ID (e.g.
Personal certificate, Organizational/employee certificate, signing
certificate, authentication certificate), This also requires multilingual
support.

- Optionally/Possibly other display metadata providing color schemes, style
sheets etc.

- Identifier/Attributes display subset, providing the list of attributes and
other name forms that should be displayed in the primary certificate UI
(i.e. Not the extended detailed view n clicks away)

- Extensibility, to provide for any future needs

The reason this didn't go anywhere was because it was considered too complex
at the time. This would simply not result in a standard with uniform
deployment in any reasonable time frame.

The alternative was to make it simple by allowing the CA to simply compile
an image. This would save us a complex UI metadata standard. The problem at
the time was lack of standards for scalable graphic representation.

But with PDF/A and with the SVG standard progressing as the industry choice
for scalable graphics on the web, the situation is different. SVG offers (as
my example demonstrate) structured text based display metadata through which
we can define everything a UI needs to know in order to display the
certificate using standard libraries that are widely available. We don't
have to re-invent the wheel.

Pros/Cons - Structured metadata is:
+ Every UI can maintain their own look and feel
+ No image processing
- Much more complex metadata standard
- Not complete - UI still have to construct it's own flavor of display
- Hard to distinguish different types of certificates.

Pros/Cons - Certificate image
+ Simple certimage standard
+ Uniform look across platforms
+ Easy to use. Existing industry standards and tools
+ Easy to give different certificate types a unique look and feel
- Requires parsing of images (possible security issues)
- CA may provide conflicting information
- RP UI can't decide their own look and feel.

Personally I don't think one size fits all. I think both approaches may
support different important use cases.

I would propose progressing the certimage draft, possibly as experimental,
as an extension to RFC 3709. There are definitely enough use cases that
would substantially benefit from this solution as there are significant
enough vendors interested in using it, to define this new image type.

I would also support initiating a work to investigate defining structured
metadata, which may produce a useful standard in a hopefully not to distant
future. This work could also be merged with proposed work to define extended
semantics for attributes (e.g. By reference to Information Card Foundation
Claims Catalog or similar definitions). See minutes from Hiroshima for
further details.

Thoughts?

/Stefan

---

From: Andrea Caccia <[email-masked]>
Date: Wed, 9 Dec 2009 10:25:05 +0100

Stefan,
I already talk to you about this solution in another context, but maybe it's interesting to discuss it now.

We can consider the following transformation to obtain a visual representation of certificate content:

- transform the certificate format to DER to XER. This give us a deterministic XML representation of all certificate content
- apply an XSLT transformation to obtain an XHTML representation that fit the visualization needs
- render with a browser

The same with some change could apply to obtain a PDF/A representation, possibly more guaranteed in terms of presentation.
The XSLT is provided by the CA and signed to guarantee the output.

Advantages:
- applicable also on already issued certificates (and possibly no change also on the new ones; eventually add an URI to point to the published XSLT)
- the same certificate can have different XSLT (so different representation) for different scenarios
- The XSLT can easily manage the localization issues, presenting the same certificate in different languages (like MS Windows does with its visualization utility, presenting the content of the certificate differently depending on the language. By the way, the result in Italian is sometimes ridiculous, I have to map back to the original english term to understand the meaning... The Operating System approach can't deal with any possible business scenarios indeed)
- if no visualization is needed there is any overhead in the certificate content
- XSLT transformation is present in most browsers (with some issues indeed...) 

Andrea

---

From: Andrea Caccia <[email-masked]>
Date: Wed, 9 Dec 2009 10:36:34 +0100

Stefan,

Advantages:

Andrea

---

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

Stefan,

> I would propose progressing the certimage draft, possibly as experimental,

Experimental is better I think. But we clearly need another rev of
the draft (or more) before going there. Even better would be running
code first (to find out if the resulting UI is actually better, which
I personally doubt) and then progress the thing if it still looks good.

> enough vendors interested in using it, to define this new image type.

I've still not seen references I can follow for the use-cases, nor have
I seen vendors saying they want this. Perhaps I missed that?

> Claims Catalog or similar definitions). See minutes from Hiroshima for

For me: No thanks. I don't really think extending the scope of work
is the right reaction to this draft not being ready.

S.

---

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

Andrea,

The idea is interesting to consider. I'm not expert in XSLT enough to fully
understand what you can or cannot do with this technique.

It would be very interesting to se an example what a certificate could look
like after such transformation.

However, to solve the issue at hand in a generic and useful way we MUST add
metadata to the certificate. Without that added metadata, the UI have no
clue what type of certificate this is or the nature of the data stored in
attributes. So even if your transform may provide a useful technique, I
can't see that it frees us from the need to add metadata in one way or the
other.

/Stefan 

On 09-12-09 10:36 AM, "Andrea Caccia" <[email-masked]>
wrote:

> - transform the certificate format to DER to XER. This give us a deterministic
> XML representation of all certificate content
> The same with some change could apply to obtain a PDF/A representation,
> possibly more guaranteed in terms of presentation.
> - applicable also on already issued certificates (and possibly no change also
> on the new ones; eventually add an URI to point to the published XSLT)
> - The XSLT can easily manage the localization issues, presenting the same
> certificate in different languages (like MS Windows does with its
> visualization utility, presenting the content of the certificate differently
> depending on the language. By the way, the result in Italian is sometimes
> ridiculous, I have to map back to the original english term to understand the
> meaning... The Operating System approach can't deal with any possible business
> scenarios indeed)

---

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

Stefan,
First of all, thank you for this fair analysis.
>From what you say, the following wording you used is the most important:
"define extended semantics for attributes" 
However, we cannot change the meaning of existing DN attributes, but in practice
there is the need to have additional (hence new) semantics.
Rather than using an image or another extension to give an additional semantics 
to existing attributes like CN, OU or SN, it would be much simpler to define new DN attributes. 
Since a DN attribute is defined using an OID, this solves all I18N problems.
These new DN attributes might be used in a subjectAltName extension 
and/or in the subject field (now or later). 
>From the image example you provided, we would simply need some OIDs to define:

- Civic Registration Number:
- Customer of :
- Country of Registration :

I would guess that we would also need:

- Country of Residence :

Such a certificate would remain fairly compact, when compared to the current proposal.

I would simply propose to define new DN attributes, rather than following the "images" track.

Denis

---------- 
De : pkix-bounces 
À : Paul Hoffman 
Date : 2009-12-09, 09:01:56
Sujet : [pkix] Structured UI metadata versus certificate imgae

Paul,

Agreed, so far

 

Thoughts?

/Stefan

---

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

Stephen,

> I personally doubt) and then progress the thing if it still looks good.

If this would go experimental then this would be an overly restrictive
attitude against this work relative to other work in the IETF. Especially in
absence of a clear threat scenario. Yes we need clear security guidance but
no one has shown that displaying an image from a trusted source poses a
major threat to humanity.

I still vote for standards track though but could accept experimental.

> I seen vendors saying they want this. Perhaps I missed that?

Yes you have missed that. Speaking of vendors, both VeriSign and Adobe has
spoken in favor of this work on this list. They are also co-authors of this
document. I have personally spoken to several not so major vendors and CAs
who are not active on this list, who support this mechanism and would like
to use and implement this if it becomes an RFC. Finally people involved in
ETSI has declared this issue interesting for the coming standards work
concerning visible signatures even thought there is no commitment to follow
this solution yet.

> is the right reaction to this draft not being ready.

Fair enough. I would be satisfied with certImage for now. I'm just saying
that I would support also the structured metadata if there is a considerable
interest in it.

/Stefan

---

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

Denis,

> First of all, thank you for this fair analysis.

Thank you for a balanced discussion.

> there is the need to have additional (hence new) semantics.

Extending is NOT changing. You could also say "further specifying" or
"defining a subset of" as well.

Such as "Employer" is a subset (or further definition) of Organization.
Civic Registration code is a valid serialNUmber and so on.

> I would simply propose to define new DN attributes, rather than following the

Well, defining new attributes have a number of problems that you would have
to find a solutions to:

1) An attribute is only identified by an OID in the certificate. It provides
no display metadata such as what this attribute value should be labeled in
the UI. Regular UIs would simply use the OIDs as label (Windows) or mark
them as "Other Name" (Apple Safari).

2) The number of granular attributes that needs to be defined and that UIs
need to learn about would soon explode and make UI design a real challenge.

3) We need to find a solution that works for legacy deployments of PKI AND
for the new upgraded UIs. The old attributes need to be preserved in order
for old certificate UIs to work properly. Defining new attributes does not
allow any migration path within a mixed environment.

/Stefan

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 09 Dec 2009 12:17:17 +0100

> understand what you can or cannot do with this technique.
The following is not XER, you wouldn't see the "type" (from openssl)
not the OID text, the  formatting of dates, ... etc.
forgot the details, that was rather simple "hack" of about 500 lines
of code 6 years ago.

The proposed approach means that whenever you need
to display protocol data encoded in whatever coding,
make some xml representation of it, and then tell the
UI people to do their work. :-)

<X509>

        <cert_info type="X509_CINF">
          <version type="ASN1_INTEGER">2</version>
          <serialNumber type="ASN1_INTEGER">10438500460942</serialNumber>
          <signature type="X509_ALGOR">
            <algorithm type="ASN1_OBJECT">(md5WithRSAEncryption)1.2.840.113549.1.1.4</algorithm>
            <parameter type="NULL" />
          </signature>
          <issuer>
            <X509_NAME_ENTRY>
              <object type="ASN1_OBJECT">(countryName)2.5.4.6</object>
              <value type="ASN1_PRINTABLE">WW</value>
            </X509_NAME_ENTRY>
            <X509_NAME_ENTRY>
              <object type="ASN1_OBJECT">(organizationName)2.5.4.10</object>
              <value type="ASN1_PRINTABLE">OpenEvidence</value>
            </X509_NAME_ENTRY>
            <X509_NAME_ENTRY>
              <object type="ASN1_OBJECT">(commonName)2.5.4.3</object>
              <value type="ASN1_PRINTABLE">Authority</value>
            </X509_NAME_ENTRY>
          </issuer>
          <validity type="X509_VAL">
            <notBefore type="ASN1_TIME">Jan 29 14:20:46 2003 GMT</notBefore>
            <notAfter type="ASN1_TIME">Jan 28 14:20:46 2005 GMT</notAfter>
          </validity>
          <subject>
            <X509_NAME_ENTRY>
              <object type="ASN1_OBJECT">(countryName)2.5.4.6</object>
              <value type="ASN1_PRINTABLE">FR</value>
            </X509_NAME_ENTRY>
            <X509_NAME_ENTRY>
              <object type="ASN1_OBJECT">(organizationName)2.5.4.10</object>
              <value type="ASN1_PRINTABLE">OpenEvidence</value>
            </X509_NAME_ENTRY>
            <X509_NAME_ENTRY>
              <object type="ASN1_OBJECT">(organizationalUnitName)2.5.4.11</object>
              <value type="ASN1_PRINTABLE">Demonstration Service</value>
            </X509_NAME_ENTRY>
            <X509_NAME_ENTRY>
              <object type="ASN1_OBJECT">(commonName)2.5.4.3</object>
              <value type="ASN1_PRINTABLE">DVCS CCPD Authority</value>
            </X509_NAME_ENTRY>
          </subject>
          <key type="X509_PUBKEY">
            <algor type="X509_ALGOR">
              <algorithm type="ASN1_OBJECT">(rsaEncryption)1.2.840.113549.1.1.1</algorithm>
              <parameter type="NULL" />
            </algor>
            <public_key type="ASN1_BIT_STRING">
30:81:89:02:81:81:00:e2:d8:f2:29:79:b0:da:7f:ac:
55:ed:2f:b2:f1:06:9a:6b:fb:5b:16:42:8e:d1:a0:51:
a4:e3:90:60:fe:81:b6:34:8d:23:19:db:f6:20:9b:ca:
53:96:be:25:80:51:c4:4d:3c:68:23:15:6d:87:ca:6d:
76:e9:bb:49:f7:a3:d5:dd:80:49:e0:5f:c0:52:c4:ee:
3f:d2:1e:dd:65:e6:3c:b2:52:6f:59:b5:7a:46:c6:c5:
43:61:e3:91:73:78:06:b7:00:19:6d:1b:55:9d:f4:93:
9c:97:42:a5:74:f4:9a:ef:3f:c9:da:d6:dd:83:26:e4:
ba:46:ed:29:39:07:63:02:03:01:00:01</public_key>
          </key>
          <extensions>
            <Extension type="X509_EXTENSION">
              <object type="ASN1_OBJECT">(X509v3 Subject Alternative Name)2.5.29.17</object>
              <value>
                <GeneralNames>
                  <GENERAL_NAME type="GENERAL_NAME">
                    <uniformResourceIdentifier type="ASN1_IA5STRING">
http://www.openevidence.org/</uniformResourceIdentifier>
                  </GENERAL_NAME type="GENERAL_NAME">
                </GeneralNames>
              </value>
            </Extension>
            <Extension type="X509_EXTENSION">
              <object type="ASN1_OBJECT">(X509v3 Key Usage)2.5.29.15</object>
              <value>
                <ASN1_BIT_STRING>c0</ASN1_BIT_STRING>
              </value>
            </Extension>
            <Extension type="X509_EXTENSION">
              <object type="ASN1_OBJECT">(X509v3 Extended Key Usage)2.5.29.37</object>
              <value>
                <EXTENDED_KEY_USAGE>
                  <ASN1_OBJECT>(dvcs)1.3.6.1.5.5.7.3.10</ASN1_OBJECT>
                  <ASN1_OBJECT>(E-mail Protection)1.3.6.1.5.5.7.3.4</ASN1_OBJECT>
                </EXTENDED_KEY_USAGE>
              </value>
            </Extension>
            <Extension type="X509_EXTENSION">
              <object type="ASN1_OBJECT">(X509v3 Basic Constraints)2.5.29.19</object>
              <value>
                <BASIC_CONSTRAINTS>
                </BASIC_CONSTRAINTS>
              </value>
            </Extension>
            <Extension type="X509_EXTENSION">
              <object type="ASN1_OBJECT">(X509v3 Subject Key Identifier)2.5.29.14</object>
              <value>
                <ASN1_OCTET_STRING>
20:8b:d5:60:e3:4e:ae:b6:36:19:05:b0:5a:a0:17:b1:
9c:78:c9:3f</ASN1_OCTET_STRING>
              </value>
            </Extension>
            <Extension type="X509_EXTENSION">
              <object type="ASN1_OBJECT">(X509v3 Authority Key Identifier)2.5.29.35</object>
              <value>
                <AUTHORITY_KEYID>
                  <keyid type="ASN1_OCTET_STRING">
e5:fb:f9:88:4d:6f:85:79:45:8c:1d:8a:c6:3b:ee:a2:
ed:32:d9:d7</keyid>
                </AUTHORITY_KEYID>
              </value>
            </Extension>
            <Extension type="X509_EXTENSION">
              <object type="ASN1_OBJECT">(Subject Information Access)1.3.6.1.5.5.7.1.11</object>
              <value>
                <GeneralNames>
                  <ACCESS_DESCRIPTION>
                    <method type="ASN1_OBJECT">(ad dvcs)1.3.6.1.5.5.7.48.4</method>
                    <location type="GENERAL_NAME">
                      <uniformResourceIdentifier type="ASN1_IA5STRING">
https://www.openevidence.org/dvcs/service-ccpd</uniformResourceIdentifier>
                    </location type="GENERAL_NAME">
                  </ACCESS_DESCRIPTION>
                </GeneralNames>
              </value>
            </Extension>
            <Extension type="X509_EXTENSION">
              <object type="ASN1_OBJECT">(Authority Information Access)1.3.6.1.5.5.7.1.1</object>
              <value>
                <GeneralNames>
                  <ACCESS_DESCRIPTION>
                    <method type="ASN1_OBJECT">(ad dvcs)1.3.6.1.5.5.7.48.4</method>
                    <location type="GENERAL_NAME">
                      <uniformResourceIdentifier type="ASN1_IA5STRING">
https://www.openevidence.org/dvcs/service-ccpd-vsd</uniformResourceIdentifier>
                    </location type="GENERAL_NAME">
                  </ACCESS_DESCRIPTION>
                </GeneralNames>
              </value>
            </Extension>
          </extensions>
        </cert_info>
        <sig_alg type="X509_ALGOR">
          <algorithm type="ASN1_OBJECT">(md5WithRSAEncryption)1.2.840.113549.1.1.4</algorithm>
          <parameter type="NULL" />
        </sig_alg>
        <signature type="ASN1_BIT_STRING">
99:2a:bf:6d:0a:04:ba:41:bc:62:3e:73:7f:02:62:ed:
f6:5f:1c:22:fc:40:ee:96:5c:78:9a:61:bc:5c:0e:76:
8e:1c:29:de:90:9e:5c:2e:fa:84:70:3c:ae:15:a4:dd:
2f:3b:61:82:0e:03:6b:14:ea:18:05:2d:d7:76:b1:76:
e5:6e:c5:9d:79:d6:5b:15:61:52:dc:f7:d1:f1:5f:02:
ca:aa:03:80:8a:7e:17:f9:df:34:eb:e9:2d:f7:60:bb:
13:57:00:01:26:74:e9:e6:32:97:89:12:7d:dc:db:fd:
8c:0c:c2:d3:1d:7d:84:c5:1b:bb:dc:a9:9d:ad:15:a6:
c4:28:47:7b:55:2a:83:67:b2:7c:72:cc:f5:98:20:67:
4d:89:86:66:d8:8c:2e:f8:81:da:86:76:50:0d:b2:03:
bb:b6:81:fa:11:52:71:33:d7:00:1d:e0:6c:18:2b:44:
9d:c9:b4:ed:31:a0:01:5f:2c:0d:df:a9:27:77:73:bb:
cb:60:70:ed:08:ce:12:9d:7a:b2:68:11:78:e2:91:53:
11:86:7d:e7:8d:35:d9:61:c8:1d:d3:10:59:50:ea:5e:
6f:98:33:ef:6e:52:c4:f5:07:16:73:e9:5f:14:25:dc:
4a:ea:a0:8c:ed:16:7b:9b:80:5c:f0:49:10:78:10:67</signature>
      </X509>

---

From: Andrea Caccia <[email-masked]>
Date: Wed, 9 Dec 2009 12:42:27 +0100

If you apply a stylesheet (XSLT transform) to this XML, you can have a representation similar to the one provided by Stefan in its examples.
The XSLT can be developed (and authenticated) by the CA to grant the correct data is displayed.
This does not mean you don't need to write code (writing XSLT is more or less like programming) but you can move this activity from operating system vendor to each CA or domain.

Just to give you an example, qualified certificates in Italy issued for people not belonging to any organization have "NON PRESENTE" as the value of organization name in subject DN.
You can guess the English translation (not present) but you can also assume that it is a real company name. Moreover, the Country field is the country of citizenship in the case above but is the country where the company is registered where Organization contains a real company. A specific XSLT can be used that knows about some all specific semantics associated with the certificate (and checking some attribute such as the certificate policy can detect if it is applied to the correct certificate not giving wrong information about a certificate it does not apply to).
I'm sure there are plenty of examples like this around, and defining each time a new OID and related X.500 object classes and rules is not  a viable solution in many cases and there are millions of such certificates already issued that can benefit from a tool that present the correct information in different languages. And this cannot be done by a generic tool packaged with MS Windows or MAC OS or whatever.

This is indeed an issue and one of the reason for the current lack of interoperability (the other is certificate trust but hopefully this is addressed and hopefully solved in with the implementation of the Service Directive using TSL, at least within  Europe...)

Andrea

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 9 Dec 2009 13:24:06 +0100

Stefan,

I reply to your three points below:

[SS] : "1) An attribute is only identified by an OID in the certificate. It provides
no display metadata such as what this attribute value should be labeled in
the UI. Regular UIs would simply use the OIDs as label (Windows) or mark
them as "Other Name" (Apple Safari)".

Existing applications cannot support enhancements that are not yet defined.:-)
This is valid for any approach. 

[SS] : "2) The number of granular attributes that needs to be defined and that UIs
need to learn about would soon explode and make UI design a real challenge".

I would guess that less than ten new attributes would need to be defined to solve most cases.
One of the most important arguments for using this approach is I18N. It allows localisation based on 
the RP language rather than localisation based on the CA languages. 

[SS] : "3) We need to find a solution that works for legacy deployments of PKI AND
for the new upgraded UIs. The old attributes need to be preserved in order
for old certificate UIs to work properly. Defining new attributes does not"

If you look carefully to my proposal, I would propose to start using the new attributes 
in the subjectAltName extension(i.e. keep unchanged the current DN). Later on, 
the new DN attributes could be used in the subject field. This would allow a smooth transition.

Denis
----- Message reçu ----- 
De : Stefan Santesson 
À : denis.pinkas,pkix 
Date : 2009-12-09, 11:44:55
Sujet : Re: [pkix] Structured UI metadata versus certificate imgae

Denis,

/Stefan

---

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

Denis,

Thee difference with the approaches is that if metadata is provided in the
certificate, then the UI can learn what it needs to know from within the
certificate.
If you define new attributes, the UI needs to obtain this metadata from out
of band sources. This is a huge magnitude harder to maintain.

Defining new OtherName forms is possible and they could as well contain
necessary metadata, but then we could as well define a new extension and
avoid confusing new and old name forms and name duplication.

/Stefan

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

>> De  : Stefan Santesson <mailto :[email-masked]>
>>  
>> À  : denis.pinkas,pkix <mailto :[email-masked],[email-masked]>
>>  
>> On 09-12-09 11:20 AM, "Denis Pinkas" <[email-masked] <mailto:
>> [email-masked]> >  wrote:
>> 
>>> > Stefan,
>>> > 
>>> > to existing attributes like CN, OU or  SN, it would be much simpler to
>>> define
>>> > new DN attributes.
>>> > Such a certificate would remain fairly compact, when  compared to the
>>> current
>>> > proposal.
>>> > 
>>> > I would simply  propose to define new DN attributes, rather than following
>>> the
>>> >  "images" track.
>>> > 
>>

---

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

Andrea,

I like many properties of this approach!

In your case the metadata is encoded in the XSLT and you would need one
unique XSLT for every type of certificate and a way for the UI to find,
download and verify that it is appropriate for the present certificate. I
also guess the XML transform of the certificate needs to be defined.

For now this feels like a very interesting candidate for a structured
metadata approach.

I need to learn more, but right now it feels more complementary than a
complete replacement of certimages.

/Stefan

On 09-12-09 12:42 PM, "Andrea Caccia" <[email-masked]>
wrote:

> If you apply a stylesheet (XSLT transform) to this XML, you can have a
> representation similar to the one provided by Stefan in its examples.
> This does not mean you don't need to write code (writing XSLT is more or less
> like programming) but you can move this activity from operating system vendor
> to each CA or domain.
> 
> Just to give you an example, qualified certificates in Italy issued for people
> not belonging to any organization have "NON PRESENTE" as the value of
> organization name in subject DN.
> You can guess the English translation (not present) but you can also assume
> that it is a real company name. Moreover, the Country field is the country of
> citizenship in the case above but is the country where the company is
> registered where Organization contains a real company. A specific XSLT can be
> used that knows about some all specific semantics associated with the
> certificate (and checking some attribute such as the certificate policy can
> detect if it is applied to the correct certificate not giving wrong
> information about a certificate it does not apply to).
> I'm sure there are plenty of examples like this around, and defining each time
> a new OID and related X.500 object classes and rules is not  a viable solution
> in many cases and there are millions of such certificates already issued that
> can benefit from a tool that present the correct information in different
> languages. And this cannot be done by a generic tool packaged with MS Windows
> or MAC OS or whatever.
> 
> This is indeed an issue and one of the reason for the current lack of
> interoperability (the other is certificate trust but hopefully this is
> addressed and hopefully solved in with the implementation of the Service
> Directive using TSL, at least within  Europe...)
> 
> Andrea
> 
> 
>>           <algorithm
>> type="ASN1_OBJECT">(md5WithRSAEncryption)1.2.840.113549.1.1.4</algorithm>
>>             <object
>> type="ASN1_OBJECT">(organizationalUnitName)2.5.4.11</object>
>>             <algorithm
>> type="ASN1_OBJECT">(rsaEncryption)1.2.840.113549.1.1.1</algorithm>
>>                 <ASN1_OBJECT>(E-mail
>> Protection)1.3.6.1.5.5.7.3.4</ASN1_OBJECT>
>>               </EXTENDED_KEY_USAGE>
>>             </value>
>>           </Extension>
https://www.openevidence.org/dvcs/service-ccpd-vsd</uniformResourceIdentifier>>
>>         <algorithm
>> type="ASN1_OBJECT">(md5WithRSAEncryption)1.2.840.113549.1.1.4</algorithm>

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 9 Dec 2009 13:54:18 +0100

Stefan,

There is a huge difference between including metadata and using OIDs.
Metadata is language specific. OIDs support any kind of language.

Translation of metadata from english into another language should be done 
using out of band sources to make sure that the translation is accurate.
So the advantage you highlighted vanishes ...

Denis
----- Message reçu ----- 
De : pkix-bounces 
À : denis.pinkas,pkix 
Date : 2009-12-09, 13:33:18
Sujet : Re: [pkix] Structured UI metadata versus certificate imgae

Denis,

Thee difference with the approaches is that if metadata is provided in the certificate, 
then the UI can learn what it needs to know from within the certificate.
If you define new attributes, the UI needs to obtain this metadata from out of band sources. 
This is a huge magnitude harder to maintain.

Defining new OtherName forms is possible and they could as well contain necessary metadata, 
but then we could as well define a new extension and avoid confusing new and old name forms
 and name duplication.

/Stefan

Stefan,

 

 
 
Denis

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

 

Denis,

/Stefan

---

From: Andrea Caccia <[email-masked]>
Date: Wed, 9 Dec 2009 16:00:48 +0100

Stefan,
some further explanation inline.

Andrea

Il giorno 09/dic/2009, alle ore 13.48, Stefan Santesson ha scritto:

> unique XSLT for every type of certificate
exactly. To be more general nothing prevents to have additional XSLTs for specific purposes.

> and a way for the UI to find,
> download and verify that it is appropriate for the present certificate.
A possibility is to set an extension in the certificate with an URI, another (for EU and the Service Directive) to set an extension in the TSL.
To verify the integrity we have some options: use a secure connection or digitally sign the XSLT. Using XML Signature (or XAdES) and the enveloped form appropriately does not prevent browsers to use it without problems (of course the do not verify the signature, this has to be done externally with the current browsers implementations)

> I
If we stay with CXER encoding (Canonical XML Encoding Rules, an alternative to DER) then you need only to implement it as it is fully standardized. And, using CXER instead of XER (exactly as using DER instead of BER) gives you a fully predictable transformation.

> complete replacement of certimages.
I fully agree and it was not my intent to replace it. I also tried to argument why *in general* we need to give more expressivity to certificates (as certimages can do) and also the possibility to add a certified reference to external contents (photos, scanned handwritten signatures, biometric data, etc) in a controlled way. 
But consider that, as far as I know, my proposal is the only method applicable also to certificates already issued, if you use a way to find the related XSLT that does not depend on the certificate content (e.g. the TSL but I'm sure we can find others). This is an important aspect to consider if you think i.e. to the tens of millions of electronic id cards in Spain or the millions of qualified certificates in italy. Consider also that, when some new standard or legal rule is in place it can make the situation even worst, as you have at the same time certificates with different content for the same semantic (it happened in Italy). With XSLT you can also deal with this problem too.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Dec 2009 07:50:47 -0800

>is the right reaction to this draft not being ready.

+1

---

From: Russ Housley <[email-masked]>
Date: Wed, 09 Dec 2009 10:07:33 -0500

Andrea:

>- transform the certificate format to DER to XER. This give us a 
>deterministic XML representation of all certificate content

Have you done this?  I'm curious what it actually looks like.

Also, handling of extensions, especially unrecognized ones, would 
need some clear wording.  It is clear to me that many extensions hold 
information that is not useful for a UI.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 09 Dec 2009 11:06:06 -0500

Andrea:

>If we stay with CXER encoding (Canonical XML Encoding Rules, an 
>alternative to DER) then you need only to implement it as it is 
>fully standardized. And, using CXER instead of XER (exactly as using 
>DER instead of BER) gives you a fully predictable transformation.

I am strongly apposed to another encoding.  We have encountered 
enough interoperability problems because a certificate generated and 
posted with DER gets re-encoded into BER at some point.  Introducing 
another encoding is just asking for even worse results.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 09 Dec 2009 13:46:46 -0500

This discussion is no longer about certificate images.  It is not
even about the metadata that the certificate image discussion
spawned.  It is about a completely new proposal that appear to be
addressing a different concern altogether.

Please change the subject line for this discussion.

Russ

At 07:24 AM 12/9/2009, Denis Pinkas wrote:

Stefan,

[SS] : "1) An attribute is only identified by an OID in the
certificate. It provides

no display metadata such as what this attribute value should be labeled
in

the UI. Regular UIs would simply use the OIDs as label (Windows) or
mark

Existing applications cannot support enhancements that are not yet
defined.:-)

[SS] : "2) The number of granular attributes that needs to be
defined and that UIs

need to learn about would soon explode and make UI design a real
challenge".

I would guess that less than ten new attributes would need to be defined
to solve most cases.

One of the most important arguments for using this approach is I18N. It
allows localisation based on

[SS] : "3) We need to find a solution that works for legacy
deployments of PKI AND

for the new upgraded UIs. The old attributes need to be preserved in
order

for old certificate UIs to work properly. Defining new attributes does
not"

If you look carefully to my proposal, I would propose to start using the
new attributes

in the subjectAltName extension(i.e. keep unchanged the current DN).
Later on,

the new DN attributes could be used in the subject field. This would
allow a smooth transition.

Denis

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

De : Stefan Santesson

À :

denis.pinkas,pkix

Sujet : Re: [pkix] Structured UI metadata versus certificate
imgae

Denis,

On 09-12-09 11:20 AM, "Denis Pinkas"
<[email-masked]>

> However, we cannot change the meaning of existing DN attributes,
but in

> practice

Extending is NOT changing. You could also say "further
specifying" or

Such as "Employer" is a subset (or further definition) of
Organization.

> Rather than using an image or another extension to give an
additional

> semantics

> to existing attributes like CN, OU or SN, it would be much
simpler to define

> Such a certificate would remain fairly compact, when compared to
the current

> I would simply propose to define new DN attributes, rather than
following the

Well, defining new attributes have a number of problems that you
would have

to find a solutions to:

1) An attribute is only identified by an OID in the certificate. It
provides

no display metadata such as what this attribute value should be
labeled in

the UI. Regular UIs would simply use the OIDs as label (Windows) or
mark

2) The number of granular attributes that needs to be defined and
that UIs

need to learn about would soon explode and make UI design a real
challenge.

3) We need to find a solution that works for legacy deployments of
PKI AND

for the new upgraded UIs. The old attributes need to be preserved in
order

for old certificate UIs to work properly. Defining new attributes
does not

/Stefan

pkix mailing list

[email-masked]

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 09 Dec 2009 19:41:04 +0100

Paul,

I interpret these two statements by you in two separate mails as if you are
now voting against your own proposal.

First you said:

On 09-12-09 4:18 AM, "Paul Hoffman" <[email-masked]> wrote:

> fashion described in the PKIX extension that defines the field. That way, the

Now you say:

>> is the right reaction to this draft not being ready.

How can you implement the approach you suggest above without extending the
scope of work?

Or have you changed your mind?

/Stefan

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Dec 2009 11:00:57 -0800

>now voting against your own proposal.

Your interpretation feels fairly contrived.

>How can you implement the approach you suggest above without extending the

I don't want to implement the approach I suggested: I was responding to the humorously-wrong-yet-emphatic statement that you quoted above. You said "it can't be done!" and I showed how it could. I was not proposing that we should do it: I see little utility in doing so.

---

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

On 09-12-09 8:00 PM, "Paul Hoffman" <[email-masked]> wrote:

> I don't want to implement the approach I suggested: I was responding to the
> humorously-wrong-yet-emphatic statement that you quoted above. You said "it
> can't be done!" 

Well, what I said can't be done is still so. You answered a question I
didn't ask, which I showed you in a private mail if you care to look.

> and I showed how it could. I was not proposing that we should
> do it: I see little utility in doing so.

OK, I'll pin you down for not caring how we don't solve the problem as long
as we don't solve the problem.

/Stefan

---

From: "Bajaj, Siddharth" <[email-masked]>
Date: Wed, 9 Dec 2009 11:26:50 -0800

I've been trying to keep track of the hundreds of emails on this topic on the PKIX mailing list.
It seems that there are two categories of concerns.

1) First concern is whether there is a use case/value in doing this.

Based on our experience at VeriSign - absolutely. I think of this as a problem of 
enabling the user to select their identity while abstracting the details of PKI 
under the hood.

All of us are used to a visual metaphor in our daily lives in the form of credit cards, 
loyalty cards, etc. 

I offer two examples of where this metaphor has been tried - 

- VeriSign had implemented a PKI client called the PTA (Personal Trust Agent) about 10 years ago 
  where we had implemented the certificate image concept. A sample UI is attached. This client
  was deployed globally, in some cases for consumers accessing their online bank application. 
  Main issue in widespread deployment was around client propagation and maintenance. 
  A standards based approach can help us propagate this concept much more widely. 

- More recently, Microsoft Cardspace. All of you have probably seen the Microsoft 
  Cardspace Identity Selector, which uses visual card representation for user's 
  identities. (see attached picture)

This particular draft/RFC will help provide us with a building block to address some
of the usability concerns that we have with PKI UX today - too hard to understand for 
average users. 

2) Second set of concerns are around how we can enable this functionality securely, 
without introducing additional vulnerabilities. There seems to be 
a lot of good discussion in this second bucket and we will try and capture as much of 
this as we can in the specification.

As in PKI all the trust chains up to the root or the CA that operates the 
root. Needless to say that the CA will need to ensure that there is no misrepresentation
in the images. It is likely that there will need to be higher level policy agreement
between the CAs and the user-agents for specific application scenarios. However, that 
would be outside the scope of this specification. 

Thanks,

Siddharth

-----Original Message-----
From: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Stefan Santesson
Sent: Tuesday, December 08, 2009 6:01 PM
To: Paul Hoffman
Cc: [email-masked]
Subject: Re: [pkix] Are human readable images really all that important? [was: WGLC for draft-ietf-pkix-certimage-03]

Paul,

On 09-12-09 2:37 AM, "Paul Hoffman" <[email-masked]> wrote:
>> Please provide me with an example of what such single text field that
>> makes sense to an uneducated person would look like.
>

But you don't have access to the meta information contained in the certimage!

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

That's it.

My certimage contains much more granular display metadata information:
http://aaa-sec.com/pub/certimage/CertImageDemo-GunIngerPersson.svg <http://aaa-sec.com/pub/certimage/CertImageDemo-GunIngerPersson.svg> 
http://aaa-sec.com/pub/certimage/CertImageDemo-GunIngerPersson.jpg <http://aaa-sec.com/pub/certimage/CertImageDemo-GunIngerPersson.jpg> 

There is a delta in the information that the CA have no way to encode into the attribute values. The rest have to go into policy identifiers that are useless to the UI.

/Stefan

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix <https://www.ietf.org/mailman/listinfo/pkix>

---

From: Russ Housley <[email-masked]>
Date: Wed, 09 Dec 2009 15:06:42 -0500

>>fully standardized. And, using CXER instead of XER (exactly as 
>>using DER instead of BER) gives you a fully predictable transformation.
>

Based on a phone call that I received, I guess that the above comment 
was not clear to some people.  I want to try and explain my position 
more clearly.

First, the certificate image document is about providing information 
to human users.  It is not about encoding the certificate in another 
manner.  The point is to improve the man-machine interface.  The 
logotypes document (RFC 3709), but this has not seen widespread 
deployment.  This is an attempt to represent the certificate in one 
image instead of having several logotypes that the UI developer can 
use in some fashion.

Second, I believe that we should stick with a single certificate 
encoding, and that is DER.  We already have interoperability mishaps 
when the certificate gets re-encoded in BER.  Adding other encoding 
scheme such as CXER will not improve interoperability.

Russ

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 10 Dec 2009 09:31:07 +1300

>provide useful information?

Uhh, unless I'm mis-interpreting your question in some way this is exactly the
question I answered in my previous message about the results of studies on
real-world users.

>to solve. 

What problems are we trying to solve then?  Does the fact that we have no data
whatsoever on something mean that we can just speculatively invent random
mechanisms in case one works?  Or was the eID example chosen specifically
because the lack of any data on it means that it's not possible to point to
studies showing that it won't work when deployed?

>We need a way to obtain a user friendly representation of the authenticated
>identity, 

Why?  As I said earlier, the only data we have on this shows that users don't,
and won't, use it because they both don't consider it useful and don't
understand what they're seeing.  The solution isn't to give them even more of
what we already know won't work but to look at other ways of addressing the
problem.  And I'm still not really sure what the problem is that you're trying
to solve here (saying "we need to solve a problem that's defined as being
whatever the RFC does" doesn't count).

Peter.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 10 Dec 2009 01:26:52 +0100

Peter,

I have heard the usability study arguments for a very long time. Some of
them seems to be very old and others I have looked closer into either comes
with flawed conclusions or don't apply to this problem.

A typical flaw: If you build a bad UI and distort and hide potentially
useful functions and their context behind a wall of technocratic garbage,
then you need to be very careful when you draw conclusions from asking
people if they use those features or not.

What is important to me is that there are a lot of practical experience with
public PKI today with millions and millions of users and a growing awareness
that the poor certificate UI is a problem worth solving, and that we need
more metadata from the CA to accomplish this task.

If you have a usability study that you think we should consider, I would be
really interested to see it.

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 10 Dec 2009 09:24:25 +0100

Russ,

This discussion is indeed related to certificate images.

I have changed the subject line to highlight the fact that for solving the issue 
raised by cert images there are now (at least) three different approaches being proposed.

Denis
----- Message reçu ----- 
De : pkix-bounces 
À : pkix 
Date : 2009-12-09, 19:46:46
Sujet : Re: [pkix] Structured UI metadata versus certificate imgae

This discussion is no longer about certificate images.  
It is not even about the metadata that the certificate image discussion spawned.  
It is about a completely new proposal that appear to be addressing a different concern altogether.

Russ

Stefan,

 

 
 
Denis

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

De : Stefan Santesson 

À : denis.pinkas,pkix 

Denis,

> However, we cannot change the meaning of existing DN attributes, but in

> Rather than using an image or another extension to give an additional

> to existing attributes like CN, OU or SN, it would be much simpler to define

> Such a certificate would remain fairly compact, when compared to the current

> I would simply propose to define new DN attributes, rather than following the

to find a solutions to:

/Stefan

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 10 Dec 2009 09:25:33 +0100

Andrea,

You said: "a real use is to use certificates to store a scan copy of the handwritten signature 
(for human beings) or official stamp (for legal entities)".

The former case is already possible using RFC 3739 as described in section 3.2.5. Biometric Information. 

The current ASN.1 structure is:
 
      BiometricData ::= SEQUENCE {
          typeOfBiometricData  TypeOfBiometricData,
          hashAlgorithm        AlgorithmIdentifier,
          biometricDataHash    OCTET STRING,
          sourceDataUri        IA5String OPTIONAL }

The important point is that this structure does not allow the data itself to be included within the certificate, 
hence keeping the size of a certificate to a reasonable size. 

If the draft certimage continues, it should exhibit the same property.

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : Stefan Santesson 
Date : 2009-12-08, 19:38:28
Sujet : Re: [pkix] WGLC for draft-ietf-pkix-certimage-03

Hope it helps,
Andrea

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 10 Dec 2009 09:37:45 +0100

Siddharth,

You said: "enabling the user to select their identity".

The certimage draft identifies three use cases:

   Typical situations when a human needs to examine the visual
   representation of a certificate are:
 
      - A person establishes secured channel with an authenticated
      service. The person needs to determine the identity of the service
      based on the authenticated credentials.
 
      - A person validates the signature on critical information, such
      as signed executable code, and needs to determine the identity of
      the signer based on the signer's certificate.
 
      - A person is required to select an appropriate certificate to be
      used when authenticating to a service or Identity Management
      infrastructure. The person needs to see the available certificates
      in order to distinguish between them in the selection process.

The case you mention is related to the third case only. If the certimage draft was limited to that third case only 
then simplifications would be possible:

1) since only the certificate holder is interrested, only one language will be necessary, 
(i.e. the one from the certificate holder), 

2) only a secure link with an external file would be necessary: RPs will normally not see the external file and 
certificates size would remain reasonable.

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : Stefan Santesson,Paul Hoffman,pkix 
Date : 2009-12-09, 20:26:50
Sujet : Re: [pkix] Are human readable images really all that important? [was: WGLCfor draft-ietf-pkix-certimage-03]

Pièce(s) Jointe(s) au message original :
  (1). pta-sample.jpg
  (2). cardspace-identity-selector.jpg

Thanks,

Siddharth

-----Original Message-----
From: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Stefan Santesson
Sent: Tuesday, December 08, 2009 6:01 PM
To: Paul Hoffman
Cc: [email-masked]
Subject: Re: [pkix] Are human readable images really all that important? [was: WGLC for draft-ietf-pkix-certimage-03]

Paul,

CN = GUN INGER PERSSON

That's it.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 10 Dec 2009 10:13:06 +0100

Denis,

Even though presentation of a certificate to the subject is a primary use
case, it is not the only one.

The option to supply multiple images of various type and language is a
property of RFC 3709.
This draft only provides one new image OID within the framework of RFC 3709.
So the first optimization is not possible.

Finally, certificates should always be issued with reasonable size. It is
important for a CA to be cautious an considerate with respect to certificate
sizes and to test certificates in the environments and applications where
they are to be used. However, the SVG example I provided also shows that it
is possible to provide useful vector graphic images of very small sizes.
We specify URL as the means of referencing to an image, but we simply point
to the existence of data URLs as a legal way to incorporate data into any
URI.

This standard should not preclude valid use cases and I¹m sure that in some
environments it makes perfect sense to embed a small vector graphic image.

/Stefan 

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

>> À  : Stefan  Santesson,Paul Hoffman,pkix <mailto
>> :[email-masked],[email-masked],[email-masked]>
>>  
>> Sujet  : Re: [pkix] Are human readable images really all that important?
>> [was:  WGLCfor draft-ietf-pkix-certimage-03]
>>  
>> 
>>  
>>  
>>  
>> From: [email-masked] <mailto: [email-masked]>
>> [mailto:[email-masked] <mailto: [email-masked]>
>> <mailto:[email-masked] <mailto: [email-masked]> > ] On Behalf
>> Of Stefan Santesson
>> Cc: [email-masked] <mailto: [email-masked]>
>> Subject:  Re: [pkix] Are human readable images really all that important?
>> [was: WGLC for  draft-ietf-pkix-certimage-03]
>> 
>> Paul,
>> 
>> On 09-12-09 2:37 AM, "Paul  Hoffman" <[email-masked] <mailto:
>> [email-masked]> >  wrote:
>> 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
>> 
>> That's it.
>> 
>> <http://aaa-sec.com/pub/certimage/CertImageDemo-GunIngerPersson.svg>
>> <http://aaa-sec.com/pub/certimage/CertImageDemo-GunIngerPersson.jpg>
>> 
>> <https://www.ietf.org/mailman/listinfo/pkix>
>> 
>> 
>> 
>>

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 10 Dec 2009 10:27:15 +0100

Stefan,

You said: " It is important for a CA to be cautious an considerate with respect to certificate sizes 
and to test certificates in the environments and applications where they are to be used."

This statement would be useful to add to the draft.
 
However, in many cases, the CA does not know in which environments and applications the certificate will be used.

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : denis.pinkas,pkix 
Date : 2009-12-10, 10:13:06
Sujet : Re: [pkix] Are human readable images really all that important? [was: WGLCfordraft-ietf-pkix-certimage-03]

Denis,

Even though presentation of a certificate to the subject is a primary use case, it is not the only one.

The option to supply multiple images of various type and language is a property of RFC 3709.
This draft only provides one new image OID within the framework of RFC 3709..
So the first optimization is not possible.

Finally, certificates should always be issued with reasonable size. It is important for a CA to be cautious an considerate with respect to certificate sizes and to test certificates in the environments and applications where they are to be used. However, the SVG example I provided also shows that it is possible to provide useful vector graphic images of very small sizes.
We specify URL as the means of referencing to an image, but we simply point to the existence of data URLs as a legal way to incorporate data into any URI.

This standard should not preclude valid use cases and I’m sure that in some environments it makes perfect sense to embed a small vector graphic image.

/Stefan 

Siddharth,

 

 

 
 
Denis

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

À  : Stefan  Santesson,Paul Hoffman,pkix <mailto :[email-masked],[email-masked],[email-masked]>  

 

  (1). pta-sample.jpg

 

Thanks,

Siddharth

-----Original Message-----
From: [email-masked] <mailto: [email-masked]>  [mailto:[email-masked] <mailto: [email-masked]>  <mailto:[email-masked] <mailto: [email-masked]> > ] On Behalf  Of Stefan Santesson
Sent: Tuesday, December 08, 2009 6:01 PM
To: Paul  Hoffman
Cc: [email-masked] <mailto: [email-masked]> 
Subject:  Re: [pkix] Are human readable images really all that important? [was: WGLC for  draft-ietf-pkix-certimage-03]

Paul,

CN = GUN INGER PERSSON

That's it.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 10 Dec 2009 10:51:23 +0100

Denis

> This statement would be useful to add to the draft.

Yes. The draft currently includes the following statement:

   Note: Implementations need to be cautious about the the size of
         images included in a certificate in order to ensure that the
         size of the certificate does not prevent the certificate to be
         used as intended.

Is this sufficient?

> However, in many cases, the CA does not know in which environments and
> applications the certificate will be used.
>  

Yes that is true. In such case the CA have to be very restrictive in adding
size or they will soon discover that their customers have problems and they
will be forced to adjust.

It is however NOT my experience that CAs are unaware of their
interoperability challenges.

My experience from working several years for a commercial CA, is that it is
a primary task for the CA make sure that their certificates can be used in
every intended/valid environment and application.

However, certificates are such a generic tool, and one size does not fit
all. What is a reasonable constraint in one environment is not reasonable in
another.

We have to rely on those using PKI that they use common sense and test their
implementations.

/Stefan

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 10 Dec 2009 23:19:36 +1300

Stefan Santesson <[email-masked]> writes:

>I have heard the usability study arguments for a very long time. Some of them
>seems to be very old and others I have looked closer into either comes with
>flawed conclusions or don't apply to this problem.

"lalalala I'm not listening lalalala" has never really impressed me as a good
point to make in an argument.

In any case the overall point of the studies, that users don't want to know
about certificate details, is quite apropos and still very relevant.  If users
don't care about X and don't use X then giving them more X isn't going to
work, no matter how you dress it up.

>more metadata from the CA to accomplish this task.

What we have is huge amounts of practical experience in how not to do things.
This is just repeating the existing wrong way of doing things in the hope that
this time it'll work.  I believe psychologists have a term for this...

As I've said before though, I have no objection to publishing this as an RFC,
for the reasons given earlier.  I'm just interested in seeing what the
justification for it is beyond emphatic assertion.

Peter.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 10 Dec 2009 11:40:02 +0100

> point to make in an argument.

Good. Never impressed me either ;)

> What we have is huge amounts of practical experience in how not to do things.

And huge amount of experience of things that actually works.

> this time it'll work.  I believe psychologists have a term for this...

No, it's about improving aspects of a working system that can be done
better.

> for the reasons given earlier.

Great.

> I'm just interested in seeing what the

Would it help to say that we are trying to execute networking truth 3 of RFC
1925, by adding some thrust to PKI in hope that we will achieve a lucky
landing ;)

   (3)  With sufficient thrust, pigs fly just fine. However, this is
        not necessarily a good idea. It is hard to be sure where they
        are going to land, and it could be dangerous sitting under them
        as they fly overhead.

Honestly, we (I) are just trying to improve the UI.

/Stefan

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Dec 2009 10:44:19 +0000

>> flawed conclusions or don't apply to this problem.

Just to note that in a mail a minute ago you (Stefan) pointed out
that you want this spec to cover >1 use case. So "this problem"
becomes ambiguous. I'll assume you mean the "signer picks
cert" problem here.

> work, no matter how you dress it up.

I think Peter's got a real point here. I don't recall seeing any
studies, ever, that said something like "users found PKI UI feature
foo really useful." One can fairly criticise some of PKI usability
studies for various reasons, but given that PKI's been about so
long, and security usability has been an academic hot(-ish) topic
for a few years now, if its true that no academic has published
a study that found users got significant benefit from the UI
associated with PKI, then that'd surely be significant.

Does anyone know of such a study? (And I don't mean a
vendor-driven report, I mean something peer-reviewed & done
independently by someone who does usability studies.)

Maybe cardspace, or this proposal, is different though. I don't
know. But asking if there's evidence that it'd be effective seems
fair to me.

PKI is as good as we have for lots of things, but maybe,
just maybe, UI design should be driven by people who do that
for a living and not by PKI.

S.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 10 Dec 2009 11:59:35 +0100

Stephen,

On 09-12-10 11:44 AM, "Stephen Farrell" <[email-masked]> wrote:

>>> them

Good point. 
Let's stop speculating about what various usability studies say or do not
say. If anyone have a usability study they think we should consider, then
please provide it, or a URL to it so we can look at it.

> for a living and not by PKI.

Good point again.
That is why this draft does not design UIs. It just allows those that do it
for a living to actually do their job.

/Stefan

---

From: "D. K. Smetters" <[email-masked]>
Date: Thu, 10 Dec 2009 11:19:21 PST

Stephen Farrell wrote:
>> work, no matter how you dress it up
> 

Let's step back from this for a minute. While I agree with Peter,
that no amount of UI information in a certificate is ever going
to make them more useful or palatable to end users, that is not the
actual question we should be asking here.

The questions we should be asking are:
a) is it ever useful to show a user something about who they are
  talking to (doing a transaction with, etc) on a network?
b) it is ever helpful to show them logos or other images
  as part of a)?

and what we should be asking for this discussion is:

c) if we think the answers to a) and b) are yes, where should we get
 the images we show the user, and would a certificate used to
authenticate the connection be a useful source of an authenticated
image?

Note: I'm not talking about showing or even mentioning certificates to
the user. What I'm talking about is using a certificate as a
potentially authenticated source of information that I *could* show a
user in a context that they might actually find useful.

> independently by someone who does usability studies.)

I think there is at least some support for a:

Stoll, J., Tashman, C. S., Edwards, W., and Spafford, K. 2008. Sesame:
informing user security decisions with system visualization. In
Proceeding of the Twenty-Sixth Annual SIGCHI Conference on Human
Factors in Computing Systems (Florence, Italy, April 05 - 10, 2008).
CHI '08. ACM, New York, NY, 1045-1054. DOI=
http://doi.acm.org/10.1145/1357054.1357217 (available here:
http://www.cc.gatech.edu/~keith/pubs/chi2008-sesame.pdf)

And some really really sketchy support for b:

Smetters, D. K. ; Stewart, P. Breaking out of the browser to defend
against phishing attacks. Fifth Conference on Email and Anti-Spam
(CEAS 2008); 2008 August 21-22; Mountain View, CA. (available here:
http://www.parc.com/content/attachments/breaking_out_browser_6496_parc.pdf)

What there isn't yet support for is whether image information in
certificates specifically is useful to someone building a UI that
actually helps an end user stay secure. That would require more
user studies, and a significant amount of requirements analysis
to figure out what the user's needs actually are.

My own personal guess about whether it's useful is that the current
approach to certificates is so far off the mark for end users that
this isn't going to help; and standardizing it now without real
requirements might screw it up for the long term. One could even make
things worse, if an attacker can get a familiar image into an
illegitimate cert and make a user overconfident in their security
as a result.

> know. But asking if there's evidence that it'd be effective seems

Yep, but keep in mind, this is a low-level building
block. It's hard to ask if it'd be effective a priori -- maybe
the system I built with it would suck. But maybe someone cleverer than
me would be able to use it to make something really useful. I do
wonder about the fact that nobody starts these standardization
processes by building toy systems and showing that they are useful,
(user studies and all) before attempting to spin them up to the Wider
World.

> for a living and not by PKI.

I absolutely agree. (Critical disclaimer: I'm not a UI designer or an
ethnographer. I just collaborate with them. )

--Diana Smetters

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 11 Dec 2009 14:43:00 +1300

"D. K. Smetters" <[email-masked]> writes:

>informing user security decisions with system visualization. In Proceeding of
>the Twenty-Sixth Annual SIGCHI Conference on Human Factors in Computing
>Systems (Florence, Italy, April 05 - 10, 2008). CHI '08. ACM, New York, NY,
>1045-1054. 

Hmm, I'm not sure if that's really too relevant for certimage though, a better
one I think would be Petnames or the coloured URL bar from FF 2 and EV certs.
OTOH these seem to demonstrate the bCanUseTheDamnThing effect, people look for
the colour change and if it's there, everything's OK.  Looking at the
certimage examples, where are you going to put your large UI with its multiple
lines of information?  What you'll get is just another conditioned response,
UI appears -> bCanUseTheDamnThing = true, and it doesn't matter what the UI
actually contains.

>Smetters, D. K. ; Stewart, P. Breaking out of the browser to defend against
>phishing attacks. Fifth Conference on Email and Anti-Spam (CEAS 2008); 2008
>August 21-22; Mountain View, CA. (available here:

What site-specific browsers show is the use of creative thinking to work
around the failure of PKI to provide effective authentication.  This sort of
thing is what I meant when I mentioned earlier that we should be looking at
new approaches rather than giving users more of what we already know doesn't
work.  SSB's are probably the best defence against phishing that I know of
because they're based on established user interaction principles and not
security dogma.

>I do wonder about the fact that nobody starts these standardization processes
>by building toy systems and showing that they are useful, (user studies and
>all) before attempting to spin them up to the Wider World.

That system worked wonders for OSI, why should we change it now?  We 
standardise, you implement (or, more frequently, we standardise, you ignore).

Peter.

---

From: Stephen Wilson <[email-masked]>
Date: Fri, 11 Dec 2009 14:31:23 +1100

Sorry, I still don't get the point of images in certificates.

There seems to be two rationales:

(1) To give the RP more information with which to make a trust 
decision.  As I mentioned, I think stranger-to-stranger e-commerce and 
PKI was one of the greatest red herrings.  It got us into most of the 
mess we're still digging ourselves out of.  If Alice and Bob really are 
strangers, I don't see that an image of anything at all can help them 
over and above the text information in the cert.

(2) To give the Subject more information about their own certificates, 
to help them pick one.   Cardspace is proffered as an example.  On this 
score, I have to say Cardspace has yet to prove itself.  The 
fundamental, un-stated assumption behind Cardspace is that for a given 
transaction, in general, there will be more than one credential that can 
be used to authenticate the 'sender'.  And thus it makes sense to have 
an InfoCard selector.  But I actually think for the vast majority of 
e-commerce transactions, there is one and only one appropriate 
credential, and that choosing it is trivial.

For instance, my Acme Bank online banking app can pick my Acme bank 
account credential. My health records app can pick my health 
credential.  When I'm shopping on line, the merchant server can find and 
pick out my credit card credential.  OK, I'll grant you I have more than 
one credit card, but you don't really need an image to differentiate 
between "Visa" and "Amex".

The vast majority of successful PKI applications involve embedded 
certificates, selected automatically by machine, and verified 
automatically by machine.  Human readable images seem to me to be geared 
at fringe applications. 

I guess there is no harm is developing an RFC for something that is 
academic ... except ... focusing on human readable images perpetuates 
the misunderstanding that certificates are for humans to read in the 
name of "trust".  So for "political" or "marketing" reasons, I think PKI 
proponents are better off distancing themselves from these sorts of use 
cases, and instead they should concentrate on the mechanised 
applications, like embedded certificates, chip devices, digtial 
credentials for professionals etc etc.

Cheers,

Steve.

Stephen Wilson
Managing Director
Lockstep Group

Phone +61 (0)414 488 851

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 11 Dec 2009 07:46:24 +0100

Stephen,

Thanks for the analysis. I have some clarifying questions.

If we forget about "trust" as the primary driver for a moment.
Is it your opinion that no user ever have any reason to:

1) See their certificate (e.g. to select one)
2) See any information from it (e.g. Who it is issued to or what it is
supposed to be used for)
3) See the identity of an authenticated opponent (using a certificate as
source).

If this is yes in any situation, then what would you propose as the best
means to do it?

Here are some real use cases that could be useful to consider:

1) Millions of certificates are used in public eGovernment in Europe. This
currently leads to situations where user's need to select a credential (They
may have several). First they need to select the type of credential and
secondly they need to select one out of a possible many of that type.

2) In the implementation of the services directive in Europe, each country
is required to provide a point of single contact providing secure electronic
services. These points of single contact are to provide authenticated
services and signed information/documents (such as licenses and permits)
that are to be examined by citizens and service providers.

3) validation of signature and origin of software, software updates, patch
notes etc.

/Stefan

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 11 Dec 2009 09:06:10 +0100

Stephen,
It's pretty obvious that you don't need a certificate image if you
are using the kind of "embedded PKI" applications you are talking about.

However, imagine that you have a phone with dozens of credentials
stored inside of.  It is pretty clear that using and managing such
credentials based on non-intelligible DN strings is not a viable option.

Or to put in a more relevant form: How would that look in your iPhone? :-)

A problem with this particular draft is that it doesn't stop with the
user but extends it to the relying party.  I'm unconvinced that the
latter is a good idea.  Adobe already have a "watermark" symbol for
digitally signed documents and that is (IMO) good enough.

Anders

Stephen Wilson wrote:
>>> Proceeding of
>>> against

---

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

Anders,

> digitally signed documents and that is (IMO) good enough.

How much does that inform you about who the signer is?

/Stefan

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 11 Dec 2009 13:08:46 +0100

Stefan,

>How much does that inform you about who the signer is?

There are indeed some limitations but usually the signer is named in the
associated PDF document which also includes a context.  So it is really
about some kind of semi-manual verification that the digital signer and the
named signer is actually the same person.

Since BankID certificates cannot be verified by end-users (you have to be
an RP-customer and using licensed software in order to do that), BankID
can hardly have had *this* use-case in mind either.

For more open CAs I would have more faith in an Organization or CA logotype
than in a dossier of personal attributes (where some like Social Security Numbers
have even been considered as harmful).

Going back to technology again, I feel that OASIS' IMI (Information Cards)
is a better approach although it requires another infrastructure.   The problem
with all schemes is that the interest in raising new infrastructures is pretty low.
Although it may *appear* that "piggybacking" on PKI and certificates would make
it easier, I think that in practice it is rather the opposite, but I'm just extrapolating
decades of moderately successful PKIng here of course :-)

I whish you good luck but I think that you are overestimating the browser
vendors' motivation for introducing (quite complex) stuff that unlike for example
OASIS' IMI doesn't really give the market any *new* possibilities.

Regards
Anders

----- Original Message ----- 
From: "Stefan Santesson" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; "Stephen Wilson" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 11, 2009 10:38
Subject: Re: [pkix] Are human readable images really all that important? [was: WGLC for 
draft-ietf-pkix-certimage-03]

Anders,

/Stefan

---

From: Andrea Caccia <[email-masked]>
Date: Fri, 11 Dec 2009 16:14:41 +0100

Denis,
I agree and a further property of the extension you mentioned is that if you want to keep private the data you can omit sourceDataUri (and manage directly the distribution of related information to the intended recipients)  or have sourceDataUri pointing to an access protected site.
On the other hand IMO it's useful (if the size is reasonable) to have a graphical representation of the content directly inside the certificate.
Last option I suggested is to standardize a way to extract the information from the certificate without any change to the certificate itself or just adding an extension that point to the official transformation supported by the CA.

Andrea

---

From: Andrea Caccia <[email-masked]>
Date: Fri, 11 Dec 2009 17:05:10 +0100

Russ,
I tray to explain better.
I'm NOT suggesting a different encoding for certificates, it's just an intermediate processing step, user side.
The main idea is to standardize a flexible way to extract the information from the certificate without any change to the certificate or just adding an extension that point to an official transformation supported by the CA or some external authority (but in a specific business domain other transformation can be used as well to suit business needs).

I think the maximum flexibility can be achieved if, after having performed the certificate validation in the usual way, the certificate content is converted in XML and processed with some well known method like XSLT. This can lead to a representation directly renderizable by a browser (indeed many browser already includes the XSLT engine and can show the content it the XSLT is available) or to PDF or wathever other XML format more easily manageable by applications.
For the first transformation, from DER to XML, I suggested CXER as a target XML format because it is a deterministic transformation (C stands for Canonical, having the same properties of representation uniqueness of DER wrt BER) that is also enough expressive (as TAGS are derived from the asn.1 abstract specification, information that with DER is lost).

Here: 

http://files.me.com/andrea.caccia/rakawu

a test certificate together with an elementary XER (without the "C") representation just to better understand. It is obtained using a sample program included in the free asn.1 compiler asn1c (see http://lionet.info/asn1c/). The precompiled version of the utility I used (named  x509dump.exe) is included only in the win binaries. Additional work is needed to open also the (meaningful) certificate extensions and to manage in a better ways the strings, as XML supports UTF8 there is no need for an HEX representation like in the attached file.
It is not in general an alternative to certimage approach, as it is self-contained and can be maintained reasonably small and requires far less processing resources; on the other hand this approach can be applied also to already generated certificate.

Hope it's more clear.

Andrea

Il giorno 09/dic/2009, alle ore 16.07, Russ Housley ha scritto:

> Also, handling of extensions, especially unrecognized ones, would need some clear wording.  It is clear to me that many extensions hold information that is not useful for a UI.
> 
> Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Dec 2009 15:08:13 -0500

This is what my browser renders.   I'm not sure this is really
useful to any user.

- <Certificate>

- <tbsCertificate>

<version>2</version>

<serialNumber>00:CB:21:CA:1C:36:21:13:D7</serialNumber>

- <signature>

<algorithm>1.2.840.113549.1.1.5</algorithm>

<parameters>05 00</parameters>

</signature>

- <issuer>

- <rdnSequence>

- <RelativeDistinguishedName>

- <AttributeTypeAndValue>

<type>2.5.4.6</type>

<value>13 02 49 54</value>

</AttributeTypeAndValue>

</RelativeDistinguishedName>

- <RelativeDistinguishedName>

- <AttributeTypeAndValue>

<type>2.5.4.8</type>

<value>13 02 56 41</value>

</AttributeTypeAndValue>

</RelativeDistinguishedName>

- <RelativeDistinguishedName>

- <AttributeTypeAndValue>

<type>2.5.4.7</type>

<value>13 0D 42 75 73 74 6F 20 41 72 73 69 7A 69
6F</value>

</AttributeTypeAndValue>

</RelativeDistinguishedName>

- <RelativeDistinguishedName>

- <AttributeTypeAndValue>

<type>2.5.4.10</type>

<value>13 0D 53 74 75 64 69 6F 20 43 61 63 63 69
61</value>

</AttributeTypeAndValue>

</RelativeDistinguishedName>

- <RelativeDistinguishedName>

- <AttributeTypeAndValue>

<type>2.5.4.3</type>

<value>13 0D 41 6E 64 72 65 61 20 43 61 63 63 69
61</value>

</AttributeTypeAndValue>

</RelativeDistinguishedName>

</rdnSequence>

</issuer>

- <validity>

- <notBefore>

<utcTime>091211023736Z</utcTime>

</notBefore>

- <notAfter>

<utcTime>100110023736Z</utcTime>

</notAfter>

</validity>

- <subject>

- <rdnSequence>

- <RelativeDistinguishedName>

- <AttributeTypeAndValue>

<type>2.5.4.6</type>

<value>13 02 49 54</value>

</AttributeTypeAndValue>

</RelativeDistinguishedName>

- <RelativeDistinguishedName>

- <AttributeTypeAndValue>

<type>2.5.4.8</type>

<value>13 02 56 41</value>

</AttributeTypeAndValue>

</RelativeDistinguishedName>

- <RelativeDistinguishedName>

- <AttributeTypeAndValue>

<type>2.5.4.7</type>

<value>13 0D 42 75 73 74 6F 20 41 72 73 69 7A 69
6F</value>

</AttributeTypeAndValue>

</RelativeDistinguishedName>

- <RelativeDistinguishedName>

- <AttributeTypeAndValue>

<type>2.5.4.10</type>

<value>13 0D 53 74 75 64 69 6F 20 43 61 63 63 69
61</value>

</AttributeTypeAndValue>

</RelativeDistinguishedName>

- <RelativeDistinguishedName>

- <AttributeTypeAndValue>

<type>2.5.4.3</type>

<value>13 0D 41 6E 64 72 65 61 20 43 61 63 63 69
61</value>

</AttributeTypeAndValue>

</RelativeDistinguishedName>

</rdnSequence>

</subject>

- <subjectPublicKeyInfo>

- <algorithm>

<algorithm>1.2.840.113549.1.1.1</algorithm>

<parameters>05 00</parameters>

</algorithm>

<subjectPublicKey>0011000010000001100010010000001010000001100000010000000010101001
0101111110011100100010001101111101011110110001101111000010010101
1000010111100111000111000001001110111010101111100111111010010110
1000101000010111001000101110100010001001010010001001100111000110
1100101010011110000111001111110111001001111001011111001001000100
1001000001010010101010001111010101011010000011111001011010100110
0110000000110111010010000110011010100101100101001001110001010001
1010011111101110110011101010010100100010110111100111000001000110
0101101110011001010100110000000101000110000111010100010000100111
0100111101101000110101100101111011111010101001000100111000101110
0111101001100111011011011111110110100011000101100011101011111110
1000110111100010000010001101100011110000010010111101100100010100
1101110010010010111100100011110100011000000101001111000011000001
1011011001100011011011110111111110000110000011110011110101011000
0001100001101001000101100000110000111010011110100010010110110001
1100110101111110001000010100101101100100011010011011101000110001
1011001101111011100101100101011111001011101000111100110100000010
00000011000000010000000000000001</subjectPublicKey>

</subjectPublicKeyInfo>

- <extensions>

- <Extension>

<extnID>2.5.29.14</extnID>

<extnValue>04 14 39 1E 54 81 8A 25 12 E2 3F 08 35 11 44 80
52 8B 33 07 88 33</extnValue>

</Extension>

- <Extension>

<extnID>2.5.29.35</extnID>

<extnValue>30 81 89 80 14 39 1E 54 81 8A 25 12 E2 3F 08 35
11 44 80 52 8B 33 07 88 33 A1 66 A4 64 30 62 31 0B 30 09 06 03 55 04 06
13 02 49 54 31 0B 30 09 06 03 55 04 08 13 02 56 41 31 16 30 14 06 03 55
04 07 13 0D 42 75 73 74 6F 20 41 72 73 69 7A 69 6F 31 16 30 14 06 03 55
04 0A 13 0D 53 74 75 64 69 6F 20 43 61 63 63 69 61 31 16 30 14 06 03 55
04 03 13 0D 41 6E 64 72 65 61 20 43 61 63 63 69 61 82 09 00 CB 21 CA 1C
36 21 13 D7</extnValue>

</Extension>

- <Extension>

<extnID>2.5.29.19</extnID>

<extnValue>30 03 01 01 FF</extnValue>

</Extension>

</extensions>

</tbsCertificate>

- <signatureAlgorithm>

<algorithm>1.2.840.113549.1.1.5</algorithm>

<parameters>05 00</parameters>

</signatureAlgorithm>

<signature>0000110110011110111001111010011110100110000000001100010010101100
0000001100001100000001001011100100011100101001010011011011100011
1010110101110110101011000001010010110001001011111100001100010000
1001010010101101011110101110011000100100001011101110001101100011
0100000001011010100111001111011101110010001101110101010011000010
0000011011000100000111000101001000000001110111010000100110111110
0101111001111100011101011000001010001011101111000100000101010111
1100100101101111010000010101010100010001011101010010100010100100
0000001110100111100100111001101001001010101110111001101001011011
1010111011110111001101001011111111110000101001111010000011101000
1100111101111101011001010000010010101110100010111000001100010101
0101010100110010110110101100000100000110100000111100110111011001
0011101011011101011111100011010010011000000101110001001001101111
1110001010000110100011011000111010010000111100000011011111010011
1111000111110010000110010010010101010000011100100100001111111011
0010000001110111111100110010111101010101101110111010010110100111</signature>

</Certificate>

At 11:05 AM 12/11/2009, Andrea Caccia wrote:

Russ,

I'm NOT suggesting a different encoding for certificates, it's just an
intermediate processing step, user side.

The main idea is to standardize a flexible way to extract the information
from the certificate without any change to the certificate or just adding
an extension that point to an official transformation supported by the CA
or some external authority (but in a specific business domain other
transformation can be used as well to suit business needs).

I think the maximum flexibility can be achieved if, after having
performed the certificate validation in the usual way, the certificate
content is converted in XML and processed with some well known method
like XSLT. This can lead to a representation directly renderizable by a
browser (indeed many browser already includes the XSLT engine and can
show the content it the XSLT is available) or to PDF or wathever other
XML format more easily manageable by applications.

For the first transformation, from DER to XML, I suggested CXER as a
target XML format because it is a deterministic transformation (C stands
for Canonical, having the same properties of representation uniqueness of
DER wrt BER) that is also enough expressive (as TAGS are derived from the
asn.1 abstract specification, information that with DER is
lost).

Here:

a test certificate together with an elementary XER (without the
"C") representation just to better understand. It is obtained
using a sample program included in the free asn.1 compiler asn1c (see
http://lionet.info/asn1c/). The precompiled version of the utility I used
(named  x509dump.exe) is included only in the win binaries.
Additional work is needed to open also the (meaningful) certificate
extensions and to manage in a better ways the strings, as XML supports
UTF8 there is no need for an HEX representation like in the attached
file.

It is not in general an alternative to certimage approach, as it is
self-contained and can be maintained reasonably small and requires far
less processing resources; on the other hand this approach can be applied
also to already generated certificate.

Hope it's more clear.

Andrea

> Also, handling of extensions, especially unrecognized ones, would
need some clear wording.  It is clear to me that many extensions
hold information that is not useful for a UI.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 11 Dec 2009 23:11:54 +0100

Russ,

I think you need to parse this through an XSLT style sheet transformation
for it to make any sense where the XSLT would define what to display and
how.

/Stefan

On 09-12-11 9:08 PM, "Russ Housley" <[email-masked]> wrote:

> This is what my browser renders.   I'm not sure this is really useful to any
> user.
> 
> - <#>  <Certificate>
> - <#>  <tbsCertificate>
>   <version>2</version>
> - <#>  <signature>
> - <#>  <issuer>
> - <#>  <rdnSequence>
> - <#>  <RelativeDistinguishedName>
> - <#>  <AttributeTypeAndValue>
>   <type>2.5.4.6</type>
> - <#>  <RelativeDistinguishedName>
> - <#>  <AttributeTypeAndValue>
>   <type>2.5.4.8</type>
> - <#>  <RelativeDistinguishedName>
> - <#>  <AttributeTypeAndValue>
>   <type>2.5.4.7</type>
>   <value>13 0D 42 75 73 74 6F 20 41 72 73 69 7A 69 6F</value>
>   </AttributeTypeAndValue>
> - <#>  <RelativeDistinguishedName>
> - <#>  <AttributeTypeAndValue>
>   <type>2.5.4.10</type>
>   <value>13 0D 53 74 75 64 69 6F 20 43 61 63 63 69 61</value>
>   </AttributeTypeAndValue>
> - <#>  <RelativeDistinguishedName>
> - <#>  <AttributeTypeAndValue>
>   <type>2.5.4.3</type>
>   <value>13 0D 41 6E 64 72 65 61 20 43 61 63 63 69 61</value>
>   </AttributeTypeAndValue>
> - <#>  <validity>
> - <#>  <notBefore>
> - <#>  <notAfter>
> - <#>  <subject>
> - <#>  <rdnSequence>
> - <#>  <RelativeDistinguishedName>
> - <#>  <AttributeTypeAndValue>
>   <type>2.5.4.6</type>
> - <#>  <RelativeDistinguishedName>
> - <#>  <AttributeTypeAndValue>
>   <type>2.5.4.8</type>
> - <#>  <RelativeDistinguishedName>
> - <#>  <AttributeTypeAndValue>
>   <type>2.5.4.7</type>
>   <value>13 0D 42 75 73 74 6F 20 41 72 73 69 7A 69 6F</value>
>   </AttributeTypeAndValue>
> - <#>  <RelativeDistinguishedName>
> - <#>  <AttributeTypeAndValue>
>   <type>2.5.4.10</type>
>   <value>13 0D 53 74 75 64 69 6F 20 43 61 63 63 69 61</value>
>   </AttributeTypeAndValue>
> - <#>  <RelativeDistinguishedName>
> - <#>  <AttributeTypeAndValue>
>   <type>2.5.4.3</type>
>   <value>13 0D 41 6E 64 72 65 61 20 43 61 63 63 69 61</value>
>   </AttributeTypeAndValue>
> - <#>  <subjectPublicKeyInfo>
> - <#>  <algorithm>
> <subjectPublicKey>001100001000000110001001000000101000000110000001000000001010
> 1001 0101111110011100100010001101111101011110110001101111000010010101
> - <#>  <extensions>
> - <#>  <Extension>
>   <extnValue>04 14 39 1E 54 81 8A 25 12 E2 3F 08 35 11 44 80 52 8B 33 07 88
> 33</extnValue> 
>   </Extension>
> - <#>  <Extension>
>   <extnValue>30 81 89 80 14 39 1E 54 81 8A 25 12 E2 3F 08 35 11 44 80 52 8B 33
> 07 88 33 A1 66 A4 64 30 62 31 0B 30 09 06 03 55 04 06 13 02 49 54 31 0B 30 09
> 06 03 55 04 08 13 02 56 41 31 16 30 14 06 03 55 04 07 13 0D 42 75 73 74 6F 20
> 41 72 73 69 7A 69 6F 31 16 30 14 06 03 55 04 0A 13 0D 53 74 75 64 69 6F 20 43
> 61 63 63 69 61 31 16 30 14 06 03 55 04 03 13 0D 41 6E 64 72 65 61 20 43 61 63
> 63 69 61 82 09 00 CB 21 CA 1C 36 21 13 D7</extnValue>
>   </Extension>
> - <#>  <Extension>
> - <#>  <signatureAlgorithm>
>> from the certificate without any change to the certificate or just adding an
>> extension that point to an official transformation supported by the CA or
>> some external authority (but in a specific business domain other
>> I think the maximum flexibility can be achieved if, after having performed
>> the certificate validation in the usual way, the certificate content is
>> converted in XML and processed with some well known method like XSLT. This
>> can lead to a representation directly renderizable by a browser (indeed many
>> browser already includes the XSLT engine and can show the content it the XSLT
>> is available) or to PDF or wathever other XML format more easily manageable
>> by applications.
>> For the first transformation, from DER to XML, I suggested CXER as a target
>> XML format because it is a deterministic transformation (C stands for
>> Canonical, having the same properties of representation uniqueness of DER wrt
>> BER) that is also enough expressive (as TAGS are derived from the asn.1
>> abstract specification, information that with DER is lost).
>> 
>> Here: 
>> 
>> a test certificate together with an elementary XER (without the "C")
>> representation just to better understand. It is obtained using a sample
>> program included in the free asn.1 compiler asn1c (see
>> (named  x509dump.exe) is included only in the win binaries. Additional work
>> is needed to open also the (meaningful) certificate extensions and to manage
>> in a better ways the strings, as XML supports UTF8 there is no need for an
>> HEX representation like in the attached file.
>> self-contained and can be maintained reasonably small and requires far less
>> processing resources; on the other hand this approach can be applied also to
>> already generated certificate.
>> 
>> Hope it's more clear.
>> 
>> Andrea
>> 
>>> > Also, handling of extensions, especially unrecognized ones, would need
>>> some clear wording.  It is clear to me that many extensions hold information
>>> that is not useful for a UI.
>>> > 
>>> > Russ 
> 
>

---

From: "Erik Andersen" <[email-masked]>
Date: Sat, 12 Dec 2009 10:12:56 +0100

As you may be aware, currently X.500, including X.509, is mandating use of
the BER encoding. However, we are looking seriously into providing support
for other encoding rules, such as Packed Encoding Rules (PER) and XER (or
CXER). Especially for XER, certificates and digital signatures raises a
problem as W3C has already done some work here, which appears to
incompatible with the XER approach. W3C is just including signatures and
certificates BER encoded followed by an Base64 encoding. This latter
approach is not very useful to you.

Currently we are considering to have the ASN.1 changed to allow Base64
encoding of a BIT STRING to allow a Base64 encoding instead of the long
strings of 0 and 1 bits as in the public key and signature example below. We
are also considering whether some XML encoding instructions in the ASN.1
definition would optimise the XML encoding.  

Any comment will be welcome.

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: [email-masked]

Skype: andersen-erik

 <http://www.x500.eu/> http://www.x500.eu/

 <http://www.x500standard.com/> http://www.x500standard.com/

Fra: [email-masked] [mailto:[email-masked]] På vegne af Russ
Housley
Sendt: 11. december 2009 21:08
Til: Andrea Caccia
Cc: [email-masked]
Emne: Re: [pkix] Structured UI metadata versus certificate imgae

- <Certificate>
- <tbsCertificate>
  <version>2</version> 
 
<subjectPublicKey>0011000010000001100010010000001010000001100000010000000010
101001 0101111110011100100010001101111101011110110001101111000010010101
00000011000000010000000000000001</subjectPublicKey> 
  </subjectPublicKeyInfo>
- <extensions>
- <Extension>
  <extnID>2.5.29.14</extnID> 
  <extnValue>04 14 39 1E 54 81 8A 25 12 E2 3F 08 35 11 44 80 52 8B 33 07 88
33</extnValue> 
  </Extension>
- <Extension>
  <extnID>2.5.29.35</extnID> 
  <extnValue>30 81 89 80 14 39 1E 54 81 8A 25 12 E2 3F 08 35 11 44 80 52 8B
33 07 88 33 A1 66 A4 64 30 62 31 0B 30 09 06 03 55 04 06 13 02 49 54 31 0B
30 09 06 03 55 04 08 13 02 56 41 31 16 30 14 06 03 55 04 07 13 0D 42 75 73
74 6F 20 41 72 73 69 7A 69 6F 31 16 30 14 06 03 55 04 0A 13 0D 53 74 75 64
69 6F 20 43 61 63 63 69 61 31 16 30 14 06 03 55 04 03 13 0D 41 6E 64 72 65
61 20 43 61 63 63 69 61 82 09 00 CB 21 CA 1C 36 21 13 D7</extnValue> 
  </Extension>
- <Extension>
  <extnID>2.5.29.19</extnID> 
  <extnValue>30 03 01 01 FF</extnValue> 
  </Extension>
  </extensions>
  </tbsCertificate>
- <signatureAlgorithm>
  <algorithm>1.2.840.113549.1.1.5</algorithm> 
  <parameters>05 00</parameters> 
  </signatureAlgorithm>

  </Certificate>

Russ,

I think the maximum flexibility can be achieved if, after having performed
the certificate validation in the usual way, the certificate content is
converted in XML and processed with some well known method like XSLT. This
can lead to a representation directly renderizable by a browser (indeed many
browser already includes the XSLT engine and can show the content it the
XSLT is available) or to PDF or wathever other XML format more easily
manageable by applications.
For the first transformation, from DER to XML, I suggested CXER as a target
XML format because it is a deterministic transformation (C stands for
Canonical, having the same properties of representation uniqueness of DER
wrt BER) that is also enough expressive (as TAGS are derived from the asn.1
abstract specification, information that with DER is lost).

Here: 

Hope it's more clear.

Andrea

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 12 Dec 2009 15:08:43 +0100

Thanks Eric,

This is interesting information.
But we need to clarify something before this discussion goes out of hand.

No one has so far proposed using any other encoding of certificates than
normal DER encoding.

What Andrea has been describing is a process through which he can take a
normal DER encoded certificate and feed it to a UI process using some
additional metadata and a transformation algorithm.
The UI algorithm happens to include a temporary conversion of the
certificate to XML using CXER. This goes nowhere outside of the UI
algorithm. The metadata is provided using XSL and the transformation to a UI
friendly format (like XHTML) is done using XSLT.

This is an interesting complementary technique to specify UI metadata to
support certificate UIs but neither me, nor Andrea think this is a
replacement for certimage. I would therefore like to drop this discussion
for now, unless someone think it needed in the context of the certificate
image draft.

If anyone want to discuss other encoding than DER for certificates, feel
free to do so but in another thread using another subject title.

Thanks

/Stefan

On 09-12-12 10:12 AM, "Erik Andersen" <[email-masked]> wrote:

> As you may be aware, currently X.500, including X.509, is mandating use of the
> BER encoding. However, we are looking seriously into providing support for
> other encoding rules, such as Packed Encoding Rules (PER) and XER (or CXER).
> Especially for XER, certificates and digital signatures raises a problem as
> W3C has already done some work here, which appears to incompatible with the
> XER approach. W3C is just including signatures and certificates BER encoded
> followed by an Base64 encoding. This latter approach is not very useful to
> you.
>  
> e-amail: [email-masked] <[email-masked]>
> Skype: andersen-erik
> http://www.x500.eu/ <http://www.x500.eu/>
> http://www.x500standard.com/ <http://www.x500standard.com/>
>  
> 
> The main idea is to standardize a flexible way to extract the information from
> the certificate without any change to the certificate or just adding an
> extension that point to an official transformation supported by the CA or some
> external authority (but in a specific business domain other transformation can
> be used as well to suit business needs).
> 
> I think the maximum flexibility can be achieved if, after having performed the
> certificate validation in the usual way, the certificate content is converted
> in XML and processed with some well known method like XSLT. This can lead to a
> representation directly renderizable by a browser (indeed many browser already
> includes the XSLT engine and can show the content it the XSLT is available) or
> to PDF or wathever other XML format more easily manageable by applications.
> (named  x509dump.exe) is included only in the win binaries. Additional work is
> needed to open also the (meaningful) certificate extensions and to manage in a
> better ways the strings, as XML supports UTF8 there is no need for an HEX
> representation like in the attached file.
>> > Also, handling of extensions, especially unrecognized ones, would need some
>> clear wording.  It is clear to me that many extensions hold information that
>> is not useful for a UI.
>> > 
>> > Russ 
> 
>

---

From: Andrea Caccia <[email-masked]>
Date: Sat, 12 Dec 2009 16:06:59 +0100

Very interesting. But even with some optimization I do not think that having an XML certificate is the right approach, for the following reasons:
- as it is now, the size is about 10 times the DER one. Even cutting by 50% it is too much for a lot of interesting use cases (e.g. smart cards but also mobile devices and applications)
- we already have billions of certificates, this means that we have a good standard and I do not see enough reasons to change it or facing with additional interoperability problems
- we already have a lot of good software implementing certificate validation and I see no reason to re-implement almost everything or having to manage 2 formats.

The idea is to give an XML access to today certificates (and in general to any DER/BER data is useful access) without the need to reinvent the wheel. 
I know about the standards from W3C and ETSI (with XAdES and others), some are clearly useful, for others it's quite difficult to understand the need other than having better access to "blobs" that otherwise are inaccessible with normal XML processing tools. An example is with RFC3161 TSTs, I see no real strong need for an XML representation.
TSL (Trust-service Status List ETSI TS 102 231) is another example of an XML container of DER stuff. As we are defining also a PDF representation of the TSL, we are facing concretely with the problem representing correctly certificate content.
CXER is a proposal, it's the most natural one as it is already standard, and I agree we can improve it to better suit XML processing needs and XCER seems to me a good starting point for its important quality of having an unique representation.

I changed the subject as correctly suggested by Stefan so, if there is interest, we can continue this discussion.

Andrea

Il giorno 12/dic/2009, alle ore 10.12, Erik Andersen ha scritto:

> As you may be aware, currently X.500, including X.509, is mandating use of the BER encoding. However, we are looking seriously into providing support for other encoding rules, such as Packed Encoding Rules (PER) and XER (or CXER). Especially for XER, certificates and digital signatures raises a problem as W3C has already done some work here, which appears to incompatible with the XER approach. W3C is just including signatures and certificates BER encoded followed by an Base64 encoding. This latter approach is not very useful to you.
>  
> Currently we are considering to have the ASN.1 changed to allow Base64 encoding of a BIT STRING to allow a Base64 encoding instead of the long strings of 0 and 1 bits as in the public key and signature example below. We are also considering whether some XML encoding instructions in the ASN.1 definition would optimise the XML encoding.  
>  
> http://www.x500.eu/
> http://www.x500standard.com/
>  
> Fra: [email-masked] [mailto:[email-masked]] På vegne af Russ Housley
> This is what my browser renders.   I'm not sure this is really useful to any user.
> 
> - <Certificate>
> - <tbsCertificate>
>   <version>2</version> 
>   <subjectPublicKey>0011000010000001100010010000001010000001100000010000000010101001 0101111110011100100010001101111101011110110001101111000010010101 1000010111100111000111000001001110111010101111100111111010010110 1000101000010111001000101110100010001001010010001001100111000110 1100101010011110000111001111110111001001111001011111001001000100 1001000001010010101010001111010101011010000011111001011010100110 0110000000110111010010000110011010100101100101001001110001010001 1010011111101110110011101010010100100010110111100111000001000110 0101101110011001010100110000000101000110000111010100010000100111 0100111101101000110101100101111011111010101001000100111000101110 0111101001100111011011011111110110100011000101100011101011111110 1000110111100010000010001101100011110000010010111101100100010100 1101110010010010111100100011110100011000000101001111000011000001 1011011001100011011011110111111110000110000011110011110101011000 0001100001101001000101100000110000111010011110100010010110110001 1100110101111110001000010100101101100100011010011011101000110001 1011001101111011100101100101011111001011101000111100110100000010 00000011000000010000000000000001</subjectPublicKey> 
>   </subjectPublicKeyInfo>
> - <extensions>
> - <Extension>
>   <extnValue>04 14 39 1E 54 81 8A 25 12 E2 3F 08 35 11 44 80 52 8B 33 07 88 33</extnValue> 
>   </Extension>
> - <Extension>
>   <extnValue>30 81 89 80 14 39 1E 54 81 8A 25 12 E2 3F 08 35 11 44 80 52 8B 33 07 88 33 A1 66 A4 64 30 62 31 0B 30 09 06 03 55 04 06 13 02 49 54 31 0B 30 09 06 03 55 04 08 13 02 56 41 31 16 30 14 06 03 55 04 07 13 0D 42 75 73 74 6F 20 41 72 73 69 7A 69 6F 31 16 30 14 06 03 55 04 0A 13 0D 53 74 75 64 69 6F 20 43 61 63 63 69 61 31 16 30 14 06 03 55 04 03 13 0D 41 6E 64 72 65 61 20 43 61 63 63 69 61 82 09 00 CB 21 CA 1C 36 21 13 D7</extnValue> 
>   </Extension>
> - <Extension>
>   <signature>0000110110011110111001111010011110100110000000001100010010101100 0000001100001100000001001011100100011100101001010011011011100011 1010110101110110101011000001010010110001001011111100001100010000 1001010010101101011110101110011000100100001011101110001101100011 0100000001011010100111001111011101110010001101110101010011000010 0000011011000100000111000101001000000001110111010000100110111110 0101111001111100011101011000001010001011101111000100000101010111 1100100101101111010000010101010100010001011101010010100010100100 0000001110100111100100111001101001001010101110111001101001011011 1010111011110111001101001011111111110000101001111010000011101000 1100111101111101011001010000010010101110100010111000001100010101 0101010100110010110110101100000100000110100000111100110111011001 0011101011011101011111100011010010011000000101110001001001101111 1110001010000110100011011000111010010000111100000011011111010011 1111000111110010000110010010010101010000011100100100001111111011 0010000001110111111100110010111101010101101110111010010110100111</signature> 
>   </Certificate>
> 
>

---

From: "Erik Andersen" <[email-masked]>
Date: Sat, 12 Dec 2009 19:13:33 +0100

Hi Stefan,

I understand what you are doing. I just noticed that XER or CXER has been
mentioned and felt it could be useful to get some feedback from PKIX in our
very initial approach to include other encoding rules than BER/DER. However,
we might come up with something that could be used for your purpose.
Consistency in approaches is useful. I also understand is not part of the ID
how images are prepared, so what I am stating has no relationship with the
progression of the ID.  

Hi Andrea,

Thanks for your valuable input. DER/BER security objects is just a small
corner of providing a general XML representation of directory protocols.
However, security objects are important in the sense that others have done
some work in this area. If possible, we should try to be compatible with
such other approaches. I am not sure how we can express in ASN.1 in such a
way that the we can include surety objects as DER enclosed blobs in an XML
stream. We will carefully study current work and try to come up with some
kind of solution. The ASN.1 guys are quite  ingenious.  

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail:  <x-msg://740/[email-masked]> [email-masked]

Skype: andersen-erik

Fra: Andrea Caccia [mailto:[email-masked]] 
Sendt: 12. december 2009 16:07
Til: Erik Andersen
Cc: [email-masked]
Emne: Re: [pkix] XML representation of DER/BER security objects

Very interesting. But even with some optimization I do not think that having
an XML certificate is the right approach, for the following reasons:

- as it is now, the size is about 10 times the DER one. Even cutting by 50%
it is too much for a lot of interesting use cases (e.g. smart cards but also
mobile devices and applications)

- we already have billions of certificates, this means that we have a good
standard and I do not see enough reasons to change it or facing with
additional interoperability problems

- we already have a lot of good software implementing certificate validation
and I see no reason to re-implement almost everything or having to manage 2
formats.

The idea is to give an XML access to today certificates (and in general to
any DER/BER data is useful access) without the need to reinvent the wheel. 

I know about the standards from W3C and ETSI (with XAdES and others), some
are clearly useful, for others it's quite difficult to understand the need
other than having better access to "blobs" that otherwise are inaccessible
with normal XML processing tools. An example is with RFC3161 TSTs, I see no
real strong need for an XML representation.

TSL (Trust-service Status List ETSI TS 102 231) is another example of an XML
container of DER stuff. As we are defining also a PDF representation of the
TSL, we are facing concretely with the problem representing correctly
certificate content.

CXER is a proposal, it's the most natural one as it is already standard, and
I agree we can improve it to better suit XML processing needs and XCER seems
to me a good starting point for its important quality of having an unique
representation.

I changed the subject as correctly suggested by Stefan so, if there is
interest, we can continue this discussion.

Andrea

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail:  <x-msg://740/[email-masked]> [email-masked]

Skype: andersen-erik

- <Certificate>
- <tbsCertificate>
  <version>2</version> 

  </Certificate>

Russ,

Here: 

 <http://files.me.com/andrea.caccia/rakawu>
http://files.me.com/andrea.caccia/rakawu

a test certificate together with an elementary XER (without the "C")
representation just to better understand. It is obtained using a sample
program included in the free asn.1 compiler asn1c (see
<http://lionet.info/asn1c/> http://lionet.info/asn1c/). The precompiled
version of the utility I used (named  x509dump.exe) is included only in the
win binaries. Additional work is needed to open also the (meaningful)
certificate extensions and to manage in a better ways the strings, as XML
supports UTF8 there is no need for an HEX representation like in the
attached file.
It is not in general an alternative to certimage approach, as it is
self-contained and can be maintained reasonably small and requires far less
processing resources; on the other hand this approach can be applied also to
already generated certificate.

Hope it's more clear.

Andrea

_______________________________________________
pkix mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/pkix>
https://www.ietf.org/mailman/listinfo/pkix

---

From: Stephen Wilson <[email-masked]>
Date: Sun, 13 Dec 2009 13:05:57 +1100

> If we forget about "trust" as the primary driver for a moment. 
Actually, we should forget about "trust" as a driver for PKI for all 
time. The demonstrably best applications for digital certificates have 
nothing to do with "trust" but rather confirmation of a Subject's 
credentials.  The best PKI apps automate formal transactions between 
parties who already recognise one another's qualifications, as expressed 
in the certificates. Examples include medical practitioners, bankers and 
other professionals signing transactions, smartcards and SIM cards 
signing transactions, embedded security like Skype, DDA EMV cards and so 
on.  These apps are context rich.  There is rarely any question about 
the right credential to use when securing these transactions; almost 
always the app itself can invoke the right certificate.

As the old Italian proverb goes: "It's good to trust; but it's better 
not to".

> 1) See their certificate (e.g. to select one)
Yes, my opinion is that this should be very rare.  PKI-enabled 
applications should almost always be able to invoke the right 
certificate on behalf of the user.

I think that a typical human user needs to know as much about the 
contents of a digital certificate as they need to know about the 
magneto-resistive properties of the gamma ferrite formulation in the 
magnetic stripe on their credit card. 

PKI technology will become ubiquitous when keys and certificates become 
as deeply embedded and as easy to use as magnetic stripes.  I think that 
the PKI industry is best served by programs and standards that foster 
embedded apps.  I think that initiatives that further the manual use of 
digital certificates, like including images in certs, are possibly 
misguided, because they perpetuate the 15 year old misconception that 
digital certificates are intended to be used by strangers Alice and Bob 
to determine if they can "trust" one another. 
> 2) See any information from it (e.g. Who it is issued to or what it is
This information is almost always highly context specific, even unique 
to the transaction.  For example, if I am signing a prescription, or an 
electronic conveyancing document, or a court order, or a purchase order, 
or a tax return, or an Amercian Express payment, then the software will 
know what certificate to use.  Therefore the certificate issuer etc. is 
redundant in terms of its meaning to the user.  If you already know what 
app you're using, the certificate is a given. Info like what the 
certificate is supposed to be used for is absolutely vital I agree, but 
mainly it's of interest to the receiver's computer which uses it to 
determine whether or not to accept the signature.

> 3) See the identity of an authenticated opponent (using a certificate as
If this is the case of strangers Alice and Bob exchanging e-mails and 
wondering who the other person really is, then I don't see that an image 
of anything is going to help.  If they are familiar with one another and 
they find a photo helpful as some sort of cue, well then I guess that's 
nice, but it just doesn't seem worthy to me of a whole lot of 
standardisation effort.
> secondly they need to select one out of a possible many of that type.
Yes they may have several credentials, but for any given transaction, I 
think that the choice of appropriate credential usually reduces to one.  
This is why I think that Cardspace has yet to prove its worth.  The 
presumption that there is a largeish set of credentials to choose from 
_in_the_context_of_each_transaction_ seems to me to be excessive. 

That is, I predict that in most cases, when you have an Inforcard 
Selector full of credentials and you initiate an application or 
transaction, the business logic will cause all Infocards bar one to be 
greyed out.

In the case of credit cards when we do often have a non-trivial choice 
(Visa/Amex/MC ...) of credentials for each transaction, I have to say 
that the keys and certificates really should be in chip cards and not 
floating around as soft credentials.  With real cards and hardware-based 
Infocards, then all but one Infocard will be greyed out, with just the 
card that's in the card reader being  highlighted and available to click 
on.
> that are to be examined by citizens and service providers.
Sorry, how does this relate to having multiple credentials to choose 
from for each app?

I should re-iterate, in case of confusion, that I am a very firm 
believer in having multiple credentials/certificates.  It's just that I 
think the choice of credential for each app is usually trivial.  The 
reason why we need multiple credentials is we engage in multiple apps.
> 3) validation of signature and origin of software, software updates, patch
Again, I am not sure how this relates to multiple credentials, much less 
the idea that an image in a credential will be of great help. Will the 
publisher's logo displayed in the code signing certificate make all the 
difference to the user's decision to accept a download?

Cheers,

Stephen Wilson.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 14 Dec 2009 00:14:00 +0100

Stephen,

I will not go into detailed arguments with you but there are many things we
agree on. It sure would be ideal if the service you are accessing could
specify what credentials you should pick.

Unfortunately, modern security protocols only provide very simple selections
mechanisms. I once wrote a draft to discuss possible solutions to the
problem: http://tools.ietf.org/html/draft-santesson-credsel-01

> Yes, my opinion is that this should be very rare.

So you agree that the use case exists (it's just very rare).

> Sorry, how does this relate to having multiple credentials to choose

Nothing. It has to do with signature verification.

> Will the 

Maybe not a logo alone...

But yes, users have an interest;
- to know where the software comes from,
- to know who is providing the service they access,
- to know who signed the permit that grants them the right to conduct
business (EU services directive).

The certificate is the source of this information.

I believe users are naturally capable of understanding the concept of
credentials as it is analogous to the credentials of the physical world. We
just need to offer them a consistent user experience across applications and
platforms and I strongly believe the certificate image can provide an
important contribution.

/Stefan

>>>>> August 21-22; Mountain View, CA. (available here:
http://www.parc.com/content/attachments/breaking_out_browser_6496_parc.pdf>>>>>
)

---

From: Steven Legg <[email-masked]>
Date: Mon, 14 Dec 2009 11:25:47 +1100

Hi Andrea,

Andrea Caccia wrote:
> Very interesting. But even with some optimization I do not think that 
> having an XML certificate is the right approach, for the following reasons:
> - as it is now, the size is about 10 times the DER one. Even cutting by 
> 50% it is too much for a lot of interesting use cases (e.g. smart cards 
> but also mobile devices and applications)
> - we already have billions of certificates, this means that we have a 
> good standard and I do not see enough reasons to change it or facing 
> with additional interoperability problems
> - we already have a lot of good software implementing certificate 
> validation and I see no reason to re-implement almost everything or 
> having to manage 2 formats.
> 
> The idea is to give an XML access to today certificates (and in general 
> to any DER/BER data is useful access) without the need to reinvent the 
> wheel. 
> I know about the standards from W3C and ETSI (with XAdES and others), 
> some are clearly useful, for others it's quite difficult to understand 
> the need other than having better access to "blobs" that otherwise are 
> inaccessible with normal XML processing tools. An example is with 
> RFC3161 TSTs, I see no real strong need for an XML representation.
> TSL (Trust-service Status List ETSI TS 102 231) is another example of an 
> XML container of DER stuff. As we are defining also a PDF representation 
> of the TSL, we are facing concretely with the problem representing 
> correctly certificate content.
> CXER is a proposal, it's the most natural one as it is already standard, 
> and I agree we can improve it to better suit XML processing needs and 
> XCER seems to me a good starting point for its important quality of 
> having an unique representation.

It's not as unique as you might think. What you get for the CXER encoding
depends on which ASN.1 specifications you use. Taking the DistinguishedName
ASN.1 type as an example, the definition in the second edition of X.500
(which RFC 3280 and the LDAP specifications use) produces a different and
incompatible encoding to what the current fifth edition of X.500 produces.
Using the definitions from the soon to be published sixth edition of X.500
will produce yet another different and incompatible CXER encoding.

CXER has an unfortunate and unnecessary dependency on type names in an
ASN.1 specification, which makes it unstable in environments where different
versions of a specification are in use. It was to avoid this instability
that I defined a better set of XML encoding rules for ASN.1 (RXER, RFC 4910).

Regards,
Steven

>> As you may be aware, currently X.500, including X.509, is mandating 
>> use of the BER encoding. However, we are looking seriously into 
>> providing support for other encoding rules, such as Packed Encoding 
>> Rules (PER) and XER (or CXER). Especially for XER, certificates and 
>> digital signatures raises a problem as W3C has already done some work 
>> here, which appears to incompatible with the XER approach. W3C is just 
>> including signatures and certificates BER encoded followed by an 
>> Base64 encoding. This latter approach is not very useful to you.
>>  
>> encoding of a BIT STRING to allow a Base64 encoding instead of the 
>> long strings of 0 and 1 bits as in the public key and signature 
>> example below. We are also considering whether some XML encoding 
>> instructions in the ASN.1 definition would optimise the XML encoding.  
>>  
>> *Fra:* [email-masked] 
>> <mailto:[email-masked]> [mailto:[email-masked]] *På 
>> vegne af *Russ Housley
>> *Sendt:* 11. december 2009 21:08
>> *Til:* Andrea Caccia
>> *Cc:* [email-masked] <mailto:[email-masked]>
>> *Emne:* Re: [pkix] Structured UI metadata versus certificate imgae
>>  
>>   <extnValue>30 81 89 80 14 39 1E 54 81 8A 25 12 E2 3F 08 35 11 44 80 
>> 52 8B 33 07 88 33 A1 66 A4 64 30 62 31 0B 30 09 06 03 55 04 06 13 02 
>> 49 54 31 0B 30 09 06 03 55 04 08 13 02 56 41 31 16 30 14 06 03 55 04 
>> 07 13 0D 42 75 73 74 6F 20 41 72 73 69 7A 69 6F 31 16 30 14 06 03 55 
>> 04 0A 13 0D 53 74 75 64 69 6F 20 43 61 63 63 69 61 31 16 30 14 06 03 
>> 55 04 03 13 0D 41 6E 64 72 65 61 20 43 61 63 63 69 61 82 09 00 CB 21 
>> CA 1C 36 21 13 D7</extnValue> 
>>   </Extension>
>> - <Extension>
>> The main idea is to standardize a flexible way to extract the 
>> information from the certificate without any change to the certificate 
>> or just adding an extension that point to an official transformation 
>> supported by the CA or some external authority (but in a specific 
>> business domain other transformation can be used as well to suit 
>> business needs).
>>
>> like XSLT. This can lead to a representation directly renderizable by 
>> a browser (indeed many browser already includes the XSLT engine and 
>> can show the content it the XSLT is available) or to PDF or wathever 
>> other XML format more easily manageable by applications.
>> target XML format because it is a deterministic transformation (C 
>> stands for Canonical, having the same properties of representation 
>> uniqueness of DER wrt BER) that is also enough expressive (as TAGS are 
>> derived from the asn.1 abstract specification, information that with 
>> DER is lost).
>>
>> Here: 
>>
>> representation just to better understand. It is obtained using a 
>> sample program included in the free asn.1 compiler asn1c 
>> (see http://lionet.info/asn1c/). The precompiled version of the 
>> utility I used (named  x509dump.exe) is included only in the win 
>> binaries. Additional work is needed to open also the (meaningful) 
>> certificate extensions and to manage in a better ways the strings, as 
>> XML supports UTF8 there is no need for an HEX representation like in 
>> the attached file.
>> less processing resources; on the other hand this approach can be 
>> applied also to already generated certificate.
>>
>> Hope it's more clear.
>>
>> Andrea
>>
>> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 14 Dec 2009 09:55:27 +0100

Hi Steven,

The sixth edition of X.500 (incl. X.509) has been published both by ISO and
ITU-T (http://www.x500standard.com/index.php?n=Ig.Latest) . The fifth
edition is now freely available and should be the one referenced by PKIX
(http://www.x500standard.com/index.php?n=Ig.LatestAvail).

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: Steven Legg [mailto:[email-masked]] 
Sendt: 14. december 2009 01:26
Til: Andrea Caccia
Cc: Erik Andersen; [email-masked]
Emne: Re: [pkix] XML representation of DER/BER security objects

Hi Andrea,

CXER has an unfortunate and unnecessary dependency on type names in an
ASN.1 specification, which makes it unstable in environments where different
versions of a specification are in use. It was to avoid this instability
that I defined a better set of XML encoding rules for ASN.1 (RXER, RFC
4910).

Regards,
Steven

101001

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 14 Dec 2009 10:49:15 -0500

Erik,

X.509 mandates DER for signature generation and validation, regardless of the encoding of the certificate.  Of course that requirement may be honored primarily in the breach, as relying party implementations that actually encode TBS-certificates in DER before validation have found.

But if software actually implemented ASN.1 correctly then it wouldn't matter if XER, PER, or whatever were used for transmission - the received data could be converted to DER for signature validation, and then converted again (if desired) to XML for XSLT transformations for display purposes.  That display conversion is entirely outside the realm of the X.500 series.

When you say "have the ASN.1 changed", presumably that actually means "having the definition of XER changed to allow Base64 encoding of a BIT STRING".  The Abstract syntax remains a bit string of a length known to the receiver; whether that string of bits is exploded 8:1 into ASCII "0" and "1" characters interspersed with carriage returns, or exploded 8:6 into Base64 characters, or compressed using run-length or Huffman coding is irrelevant for signature purposes as long as the encoding is lossless.   The idea that "instructions" in the ASN.1 definition should "optimize" an encoding sounds like anathema to me - the ASN.1 definition is an abstract definition of the data, not of the encoding.   Any encoding or decoding options should be outside the ASN.1, e.g. as a compiler directive or user preference or negotiated connection setting: "I want to see bitstrings in hex08 / hex16 / hex32 / binary / base64 / ...".

Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Saturday, December 12, 2009 4:13 AM
To: [email-masked]
Subject: Re: [pkix] Structured UI metadata versus certificate imgae

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: [email-masked]

Skype: andersen-erik

http://www.x500.eu/

- <Certificate>
- <tbsCertificate>
  <version>2</version> 

Russ,

Here: 

Hope it's more clear.

Andrea

---

From: Andrea Caccia <[email-masked]>
Date: Thu, 17 Dec 2009 03:31:21 +0100

I got RFC 4910 (as well as the related RFC 4911 and 4912). It's a lot of material to study, so let see if i understood correctly the concept.
A way to proceed is:
- to transform the asn.1 definition in asn.x. This is done following some guidelines and could be done e.g. by PKIX to have available the same definition of a certificate and its extensions or a timestamp or whatever information specified in asn.1
- at this point an encoding in CRXER (Canonical Robust XML Encoding Rule) can be derived from data in BER or DER in a deterministic way
This could give access to the content of e.g. a certificate using the commonly available XML tools.
Please let me know if I miss something.
Is any compiler that support RXER generation available?

Andrea

Il giorno 14/dic/2009, alle ore 01.25, Steven Legg ha scritto:

>> The idea is to give an XML access to today certificates (and in general to any DER/BER data is useful access) without the need to reinvent the wheel. I know about the standards from W3C and ETSI (with XAdES and others), some are clearly useful, for others it's quite difficult to understand the need other than having better access to "blobs" that otherwise are inaccessible with normal XML processing tools. An example is with RFC3161 TSTs, I see no real strong need for an XML representation.
>>> Currently we are considering to have the ASN.1 changed to allow Base64 encoding of a BIT STRING to allow a Base64 encoding instead of the long strings of 0 and 1 bits as in the public key and signature example below. We are also considering whether some XML encoding instructions in the ASN.1 definition would optimise the XML encoding.   Any comment will be welcome.
>>> Erik Andersen
>>> Andersen's L-Service
>>> Elsevej 48,
>>> DK-3500 Vaerloese
>>> Denmark
>>> Mobile: +45 2097 1490
>>> e-amail: [email-masked]
>>> Skype: andersen-erik
>>> http://www.x500.eu/
>>> *Fra:* [email-masked] <mailto:[email-masked]> [mailto:[email-masked]] *På vegne af *Russ Housley
>>>  <version>2</version>   <serialNumber>00:CB:21:CA:1C:36:21:13:D7</serialNumber> - <signature>
>>>  <algorithm>1.2.840.113549.1.1.5</algorithm>   <parameters>05 00</parameters>   </signature>
>>> - <issuer>
>>> - <rdnSequence>
...

---

From: Steven Legg <[email-masked]>
Date: Thu, 17 Dec 2009 15:03:07 +1100

Hi Andrea,

Andrea Caccia wrote:
> - to transform the asn.1 definition in asn.x.

There's no need to do that. RXER is defined in terms of ASN.1 rather than ASN.X,
though ASN.1 and ASN.X are essentially equivalent. Therefore, for your purposes,
you can ignore RFC 4912 and use the PKIX or X.500 ASN.1 specifications directly.
Since those specifications don't use any RXER encoding instructions you can ignore
RFC 4911 as well.

 > This is done following some guidelines and could be done e.g. by PKIX to have available the same definition of a certificate 
and its extensions or a timestamp or whatever information specified in asn.1
> Is any compiler that support RXER generation available?

Currently none publicly available.

I noticed that the XER-encoded example that has appeared in this thread was not
a valid XER encoding (it skimped on the encoding of the open types) so perhaps
there isn't a freely available conformant XER encoder either (though there are
some commercial XER tools).

A complete RXER encoder is not necessarily what you need anyway. I expect some
routines to translate the in-memory representation of a decoded DER Certificate
into the in-memory XML Infoset representation of its RXER encoding is sufficient.
That could be hand-written without much effort.

Regards,
Steven