Three short fixes

Turner, Sean P. | 4 Jun 2007 20:44

RE: Three short fixes

Phil,

For the logos, can't we just use the logo types RFC (http://ietf.org/rfc/rfc3709.txt).

spt

From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Hallam-Baker, Phillip
Sent: Monday, June 04, 2007 1:37 PM
To: pkix
Subject: Three short fixes

Work in the w3C Web Security Context group and elsewhere has prompted me to consider that we need to take the necessary steps to allow the following information to be encoded in certificates in a consistent manner:

1) Text Representation of Community Logos

This is an accessibility issue. If a certificate is issued with an FDIC community logo in it there has to be a way to present this information to blind users, users with an audio browser, etc. etc.

One simple fix would be to simply allow for text/plain as a community logo slot. Alternatively we could encode the information in the image itself. Alternatively we could specify an extension OID that simply takes a list of community DNs.

This is not a problem for either the subject or the issuer since there are already

2) Member Since attribute

This attribute would take a date as a parameter and would encode the first date at which the certified entity was issued a credential. The exact interpretation of this would be left to the CPS of the certificate issuer.

3) No Padlock Icon attribute

This attribute would allow a certificate to say that no user indication should be specified in the chrome, nor should any nag screens. It would be an option that the issuing CA would put in at their discretion.

The need for this is to allow a CA to support a wide range of applications which require encryption but require even less authentication than current schemes such as domain validated certs. For example self signed certificates, certificates issued to embedded hardware, etc. etc.

What I want to do is to get us to the point where the browser authors feel comfortable with a user experience that does not contain the nag screens that disfigure current schemes. In many cases all that is required is to turn on encryption. The user does not need to be told that the certificate has expired, has been issued by an unknown CA or any of the usual nonsense. just don't tell the user that its safe in the first place and the browser does not need to say that it is dangerous.

Clearly this attribute is unnecessary from a technical point of view. From a market point of view it is essential if we are going to ensure that applications are doing the right thing. The padlock icon has some pretty strong semantics. Many applications require less. We are not going to get everyone who currently has a padlock certificate to get a green bar cert. So lets serve the applications that require even less than the padlock without diluting the padlock semantics further.

Before writing up a draft I would like to guage whether folk feel there is a need for any of these and if so what the likely level of contention is, whether it can be completed within PKIX or should it be a personal submission.

Main thing I want here is the reservation of the OIDs under a neutral, non VeriSign arc. I don't think that the rest of the industry would feel comfortable using VeriSign OIDs and VeriSign might not be comfortable with them doing so either.

We are definitely going to require the first, the second seems to be considered a 'no brainer' since it is information that every CA holds, that is not currently provided to the user and is very very effective at providing security context.