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

From: "Pope, Nick" <[email-masked]>
Date: Wed, 9 Dec 2009 09:05:14 -0000

Stefan,

Firstly, thanks for sending out the example, seeing a real image makes the
case much better.

Secondly, metadata describing the displayed certificate has another related
use: when displaying data derived from the certificate as part of a visible
signature within a document such as a PDF.  This is something that is
already being considered as a possible part of the work in PDF advanced
electronic signatures: to enable the certificate information as displayed as
part of the "visible signature" in the document to be the same as displayed
when verifying a digital signature (including the certificate).

Nick

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stefan Santesson
> Sent: 09 December 2009 08:02
> To: Paul Hoffman
> Cc: [email-masked]
> Subject: [pkix] Structured UI metadata versus certificate imgae
> 
> 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:
> >> But you don't have access to the meta information contained in the
> >> certimage!
> >
> > 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.
> 
> >> 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.
> >
> > 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
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email [email-masked].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited".