Subject: Three short fixes

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 4 Jun 2007 10:36:50 -0700

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.

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 4 Jun 2007 14:44:28 -0400

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

  _____  

From: [email-masked] [mailto:[email-masked]] 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:

    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 

    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.

    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.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 4 Jun 2007 12:22:27 -0700

No, in case I am not being clear here,
 
The assumption is that we issue a certificate with the FDIC and Equal Opportunity lender LOGOTYPE images as community logos.
 
Now how do I provide the same information to a non sighted reader? For Issuer and Subject logos I just pull the info out of the cert issuer and subject. I need a way to express the same info in text as the LOGOTYPE contains.

________________________________

	From: Turner, Sean P. [mailto:[email-masked]] 
	Sent: Monday, June 04, 2007 2:44 PM
	To: Hallam-Baker, Phillip; 'pkix'
	Subject: 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: [email-masked] [mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
	Sent: Monday, June 04, 2007 1:37 PM
	To: pkix
	Subject: Three short fixes

---

From: Trevor Freeman <[email-masked]>
Date: Mon, 4 Jun 2007 12:39:06 -0700

Yes, RFC3709 already supports audio formats which was specifically added for accessibility scenarios such as visually impaired users.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Turner, Sean P.
Sent: Monday, June 04, 2007 11:44 AM
To: 'Hallam-Baker, Phillip'; 'pkix'
Subject: RE: Three short fixes

Phil,

spt

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 4 Jun 2007 17:01:39 -0400

Although RFC3709 currently has no support for ALT text,
LogotypeImageInfo and LogotypeAudioInfo could easily be modified to
include a text description field after the language field.  Although
audio could be used for visually impaired users, I agree with also
having a text option usable with screenreaders (and Lynx).

No objections to creating a PKIX OID for this.  Where would it be used -
as a directory attribute for subject alternative name?  A new PKIX
private extension seems like overkill for this purpose.

I do not believe PKIX should sponsor an attribute that tells a
certificate user to "ignore this certificate", e.g. "accept this
certificate even if it cannot be validated".  I don't object to
applications supporting unauthenticated encryption while making no
security claims.  But if the application is not going to authenticate an
encryption key, then the application should not be transmitting or
consuming certificates in the first place.  Saying "but TLS won't work
without certificates" is not a convincing argument - the TLS working
group has made decisions regarding unauthenticated (and/or unencrypted)
ciphersuites, and the place to revisit those decisions is there, not
PKIX.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 4 Jun 2007 15:39:05 -0700

Talking to folk it appears that audio is useful but not enough. 
 
How do I develop authentication criteria for audio? I am having a difficult enough time with images. And it also tips into the language issue.
 
I can't render audio in braille for example. If it is in text or an X.500 DN I can render it in any medium I need.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Trevor Freeman
	Sent: Monday, June 04, 2007 3:39 PM
	To: [email-masked]; Hallam-Baker, Phillip; 'pkix'
	Subject: RE: Three short fixes

	Phil,

	spt

---

From: Trevor Freeman <[email-masked]>
Date: Mon, 4 Jun 2007 16:42:10 -0700

I would have thought audio is a more constrained problem for verification than images. Saying you can build a procedure which verifies the rights someone to assert "foo bar" but you have difficulty building a procedure where someone verifies a wav file contains someone reading the text "foo bar" seems hard to believe. However the set of logotypes defined by 3709 is extensible so you can define whatever logotypes you want for the audio browsers and it does not need workgroup input.

From: Hallam-Baker, Phillip [mailto:[email-masked]]
Sent: Monday, June 04, 2007 3:39 PM
To: Trevor Freeman; [email-masked]; pkix
Subject: RE: Three short fixes

Phil,

spt

---

From: Thomas Pornin <[email-masked]>
Date: Tue, 5 Jun 2007 08:46:32 +0200

On Mon, Jun 04, 2007 at 05:01:39PM -0400, Kemp, David P. wrote:
> certificate even if it cannot be validated".

In all generality, the public key represented in a certificate is
obtained as a byproduct of path validation: for DSA-like public keys,
the public key parameters may be inherited from certificates higher in
the path. A stand-alone certificate may not contain by itself enough
data to represent a complete and usable public key. Of course, most
certificates in the wild contain RSA public keys, which are
self-contained. Nonetheless, using the contents of certificates outside
of the context of a certificate path is a kind of paradigm shift from
what X.509 usually does.

> Saying "but TLS won't work without certificates" is not a convincing
> argument - the TLS working group has made decisions regarding
> unauthenticated (and/or unencrypted) ciphersuites, and the place to
> revisit those decisions is there, not PKIX.

TLS 1.1 (RFC 4346) still documents the "DH_anon" ciphersuites which
allow for unauthenticated key exchange. They are marked as deprecated
because they are vulnerable to man-in-the-middle attacks (and you have a
quite unusual attack model if encryption is needed by active attacks are
not to be feared). But they still exist. Ideally, additional "RSA_anon"
cipher suites would be added, because RSA key exchange makes it much
easier for megahertz-impaired clients.

	--Thomas Pornin

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 6 Jun 2007 09:57:31 -0700

I already have an authentication process for an X.500 DN. Seems like that is going to be the most efficient scheme.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Trevor Freeman
	Sent: Monday, June 04, 2007 7:42 PM
	To: Hallam-Baker, Phillip; [email-masked]; pkix
	Subject: RE: Three short fixes

	 

		Phil,

		spt

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 6 Jun 2007 10:07:14 -0700

If you have a certificate that does not have sufficient information to establish encryption then you can't use encryption. I don't see the relevance of that fact. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thomas Pornin
> Sent: Tuesday, June 05, 2007 2:47 AM
> To: pkix
> Subject: Re: Three short fixes
> 
> 
> In all generality, the public key represented in a 
> certificate is obtained as a byproduct of path validation: 
> for DSA-like public keys, the public key parameters may be 
> inherited from certificates higher in the path. A stand-alone 
> certificate may not contain by itself enough data to 
> represent a complete and usable public key. Of course, most 
> self-contained. Nonetheless, using the contents of 
> certificates outside of the context of a certificate path is 
> a kind of paradigm shift from what X.509 usually does.
> 
> 
> TLS 1.1 (RFC 4346) still documents the "DH_anon" ciphersuites 
> which allow for unauthenticated key exchange. They are marked 
> as deprecated because they are vulnerable to 
> man-in-the-middle attacks (and you have a quite unusual 
> attack model if encryption is needed by active attacks are 
> cipher suites would be added, because RSA key exchange makes 
> it much easier for megahertz-impaired clients.
> 
> 
> 	--Thomas Pornin
> 
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 6 Jun 2007 10:05:40 -0700

I do not believe PKIX should sponsor an attribute that tells a certificate user to "ignore this certificate", e.g. "accept this certificate even if it cannot be validated".  I don't object to applications supporting unauthenticated encryption while making no security claims.  But if the application is not going to authenticate an encryption key, then the application should not be transmitting or consuming certificates in the first place.  Saying "but TLS won't work without certificates" is not a convincing argument - the TLS working group has made decisions regarding unauthenticated (and/or unencrypted) ciphersuites, and the place to revisit those decisions is there, not PKIX. 

The point here is precisely to allow a certificate to state 'there are no security claims being made here'. 

The user does not accept the certificate, the client application does. No user has ever checked a certificate path and no user ever will. The question is whether the client application should be telling the user that it is 'safe' or not.

I don't see why we need to tell the user that encryption is being used unless they have explicitly said that they need confidentiality. Telling the user that there is encryption means also telling them about a whole range of failures and other error conditions.

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 6 Jun 2007 14:26:42 -0400

And my point is that there is no reason to use a certificate to say "no
security claims are being made".  You achieve the identical result (an
encrypted channel that makes no security claims) by using DH_ANON
encryption without transmitting, validating, or even issuing a
certificate.

In other words, it is up to applications and encryption protocols to
support unauthenticated and unannounced encryption if they so desire.
Because no certificates are needed to support such applications, there
is no requirement for PKIX to profile such certificates.

[phill]: If you have a certificate that does not have sufficient
information to establish encryption then you can't use encryption. I
don't see the relevance of that fact.

A certificate only needs to have sufficient information to
"authenticate" encryption, not establish.  The amount of certified
information needed to "establish" an unauthenticated encryption key is
zero.    DH or RSA public keys and parameters can be made up on the fly
(ephemerally) or pre-stored (statically) and handshaked without ever
touching a CA.

  _____  

From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Wednesday, June 06, 2007 1:06 PM
To: Kemp, David P.; pkix
Subject: RE: Three short fixes

The point here is precisely to allow a certificate to state 'there are
no security claims being made here'. 

The user does not accept the certificate, the client application does.
No user has ever checked a certificate path and no user ever will. The
question is whether the client application should be telling the user
that it is 'safe' or not.

I don't see why we need to tell the user that encryption is being used
unless they have explicitly said that they need confidentiality. Telling
the user that there is encryption means also telling them about a whole
range of failures and other error conditions.

---

From: Thomas Pornin <[email-masked]>
Date: Thu, 7 Jun 2007 08:56:13 +0200

On Wed, Jun 06, 2007 at 10:07:14AM -0700, Hallam-Baker, Phillip wrote:
> If you have a certificate that does not have sufficient information to
> establish encryption then you can't use encryption. I don't see the
> relevance of that fact. 

The point is that certificates are meant to be used only after a
complete path validation, and the "sufficient information to establish
encryption" is computed by the validation procedure. It so happens that
for some public key types, you may extract the public key from a lone
certificate, but nothing in X.509 was optimized for such usage.

Another way to see your proposal is the following: what you suggest is
that the server encodes its public key into something which looks like a
certificate. The server adds issuer and subject X.500 names, a serial
number, validity dates, a signature, and a bunch of extensions,
including one which states that all this added information is rubbish
and the client should just extract the public key and ignore everything
else in that "certificate". This strikes me as unnecessarily
inefficient: the server adds several layers of data, making the whole
object fatter and more complex, just so that the client gets rid of that
extra data. It would be much more efficient, especially network-wise, to
just send the server public key without bothering at all with encodings
which look like certificates and hundreds of bytes whose sole fate is to
be utterly ignored by the receiver.

And, lo and behold, SSL/TLS already has cipher suites where a simple
public key is transmitted, with no X.509 implication at all. These are
named "DH_anon". These cipher suites do what you ask for, and do it
faster and better than what your proposal would imply.

	--Thomas Pornin

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 07 Jun 2007 21:19:31 +1200

>security claims being made here'.

So is the intent to create an attribute that says "This certificate is merely
a convenient universally-accepted blob for communicating a public key and a
name/email address/URL"?  In other words it's not really TLS-specific?

Peter.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 11 Jun 2007 07:23:56 -0700

I don't see why I should appologize for a fix for being 'centered' on the only X.509 prototocol that can be regarded as a real success. 

The reason for using a certificate is to allow for backwards compatibility with a billion installed browsers. The dilution of trust is inevitable, all it takes to get a WebTrust audit is to do what you say. Eventually someone is going to get a WebTrust audit on the null CPS.

I want to be able to issue device SSL certs. People want to buy them. All that I want to do here is to make sure that they can be distinguished from certs people are using to take credit cards.

I can give you a cast iron chain for an EUI48 MAC address. But it says nothing that should give an end user warm fuzzies.

'This cert makes no security claims that are worth display to an end user'.

> From: pgut001 [mailto:[email-masked]] 
> Sent: Thursday, June 07, 2007 5:20 AM
> To: [email-masked]; [email-masked]; Hallam-Baker, Phillip
> So is the intent to create an attribute that says "This 
> certificate is merely a convenient universally-accepted blob 
> for communicating a public key and a name/email address/URL"? 
>  In other words it's not really TLS-specific?
> 
> Peter.
> 
> 
>

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 12 Jun 2007 03:45:22 +1200

"Hallam-Baker, Phillip" <[email-masked]> writes:

>I don't see why I should appologize for a fix for being 'centered' on the
>only X.509 prototocol that can be regarded as a real success.

Uhh... who was that intended for?  It doesn't seem to be a response to my
message that you've quoted.

>'This cert makes no security claims that are worth display to an end user'.

As it turns out I've already got an OID out there for just such an extension,
which I added after constant user requests (that is, they didn't specifically
ask for this, but said that all they needed from a cert was a universally-
recognised bit bag for public keys, and they needed some way to tag it so that
relying parties could tell that it was just a no-semantics-attached bit bag).
So if Verisign needs a vendor-neutral OID, you can use mine, assuming that's
what you want (you didn't really answer my question below).

> for communicating a public key and a name/email address/URL"?

In response to that I got several private-mail comments saying things like
"That's the default action for certificates isn't it?" and "How does this
differ from the current situation" :-).

Peter.

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 11 Jun 2007 12:06:22 -0400

More to the point, the intent is to create an attribute that says:

  "This certificate is merely a convenient universally-accepted
   blob for communicating a public key and a name/email address/URL"
*AND*
  "There is no claim that the public key and the name/email/URL
   have any relationship whatsoever"

In other words, the name/email/URL could belong to Bank of America
but the key pair and certificate request could have been created by
Phish-R-Us, and no claims to the contrary are made by the issuer.
Unfortunately, the mere existence of a certificate implies such
a claim even if it is disclaimed by an extension.

Saying "CAs want to sell no-claim certificates and server operators
want to buy them" ignores the societal cost of issuing certificates
that can be used to promote phishing.

If the extension MUST be marked critical, and if the certificate
MUST be rejected if subject name is non-null, and if the certificate
MUST be rejected if any other extension (including SAN) is present,
then perhaps there is less danger that current TLS applications
would be misled by the existence of such certificates.  But the
safer approach is to not issue them in the first place, particularly
since alternatives (anonymous ciphersuites) already exist.

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Thursday, June 07, 2007 5:20 AM
To: Kemp, David P.; [email-masked]; [email-masked]
Subject: RE: Three short fixes

>The point here is precisely to allow a certificate to state 'there are
no
>security claims being made here'.

So is the intent to create an attribute that says "This certificate is
merely
a convenient universally-accepted blob for communicating a public key
and a
name/email address/URL"?  In other words it's not really TLS-specific?

Peter.

---

From: Thomas Pornin <[email-masked]>
Date: Mon, 11 Jun 2007 18:11:39 +0200

On Mon, Jun 11, 2007 at 07:23:56AM -0700, Hallam-Baker, Phillip wrote:
> I don't see why I should appologize for a fix for being 'centered' on
> the only X.509 prototocol that can be regarded as a real success. 

This is a technical debate on a technical mailing-list. This is not a
trial and there is nothing to apologize about yet.

> The reason for using a certificate is to allow for backwards
> compatibility with a billion installed browsers. The dilution of trust
> is inevitable, all it takes to get a WebTrust audit is to do what you
> say. Eventually someone is going to get a WebTrust audit on the null
> CPS.

For backward compatibility, SSL/TLS already has a beautiful scheme which
is called "cipher suite selection" and it works. Basically, the client
sends a message ("ClientHello") where it states which cipher suites it
supports, and then the server selects one which it also supports. The
cipher suite defines how the session will be protected. For DH_anon
cipher suites, both client and server know that there is no X.509
certificate involved, only a public key.

Let's assume that we have a server which wishes to use encryption but
needs not any kind of authentication(*). This server will be fine with
a DH_anon suite. A client comes along:

-- Either this is a client which supports the concept of an
unauthenticated but encrypted session. That client then implements
DH_anon cipher suites, because that is exactly what these suites are
about, and they have been standard for quite a long time. The client
states that it supports DH_anon suites, the server selects one, and the
session is encrypted but not authenticated. No X.509 certificate is
involved here, and, in particular, no X.509-related warning message is
displayed to the user.

-- Or the client does not support the concept of an unauthenticated but
encrypted session. This means that the client does not support DH_anon
cipher suites (because DH_anon suites are meant for one thing and one
thing only: unauthenticated but encrypted session). The client will send
a ClientHello message which will not contain a DH_anon suite, but other
cipher suites which expect a X.509 certificate from the server. The
server sends a certificate which cannot be authenticated by the client.
The client displays a warning to the user, but we cannot do better than
that since the client does not support unauthenticated sessions: this is
the "backward compatibility" situation.

What could be done here to makes things even better would be the
following:

-- Make DH_anon suites more "supported" (newer TLS specifications tell
that DH_anon suites are obsolescent due to the involved security
issues(**)).

-- Define RSA_anon suites which should provide better performance for
computationaly challenged clients (RSA encryption is cheap).

Both of these are issues for the IETF TLS mailing-list, not the IETF PKIX
mailing-list.

To sum up, what you ask for _already exists_ in a better way (less
network traffic and less X.509 processing for the same functionality).
Unless what you want is something entirely different. You write:

> I want to be able to issue device SSL certs. People want to buy them.

Of course, if you sell certificates, you will not like a scheme where
nobody uses certificates and, as such, nobody buys certificates.

	--Thomas Pornin

(*) Basically, unauthenticated but encrypted session are useful only if
the security model allows only passive attacks. This is rarely a valid
assumptions, but this is not the issue in this discussion. We assume
here that there are plausible situations where unauthenticated but
encrypted sessions are what is needed.

(**) People involved in the definition of TLS do not believe in the
existence of plausible situations where unauthenticated but encrypted
sessions are what is needed. This is why DH_anon suites are currently
deprecated. But the same people, and, more importantly from your point
of view, the TLS implementors will think just the same about any way to
get unauthenticated but encryted sessions, whether by using the TLS
features which have been designed for exactly that usage (DH_anon), or
by any X.509-related trickery such as your fake certificates. So this is
not an issue in this debate.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 11 Jun 2007 10:45:29 -0700

The TLS features are irrelevant.

The information to be encoded here relates to the issue practices of the certificate. Therefore they go into the certificate.

These are not anonymous communications, they are merely communications that do not require the level of assurance that is necessary to alert the user to tell tham that the communication is secure.

> Sent: Monday, June 11, 2007 12:12 PM
> To: [email-masked]
> This is a technical debate on a technical mailing-list. This 
> is not a trial and there is nothing to apologize about yet.
> 
> 
> For backward compatibility, SSL/TLS already has a beautiful 
> scheme which is called "cipher suite selection" and it works. 
> Basically, the client sends a message ("ClientHello") where 
> it states which cipher suites it supports, and then the 
> server selects one which it also supports. The cipher suite 
> defines how the session will be protected. For DH_anon cipher 
> suites, both client and server know that there is no X.509 
> Let's assume that we have a server which wishes to use 
> encryption but needs not any kind of authentication(*). This 
> server will be fine with a DH_anon suite. A client comes along:
> 
> unauthenticated but encrypted session. That client then 
> implements DH_anon cipher suites, because that is exactly 
> what these suites are about, and they have been standard for 
> quite a long time. The client states that it supports DH_anon 
> suites, the server selects one, and the session is encrypted 
> but not authenticated. No X.509 certificate is involved here, 
> and, in particular, no X.509-related warning message is 
> displayed to the user.
> 
> -- Or the client does not support the concept of an 
> unauthenticated but encrypted session. This means that the 
> client does not support DH_anon cipher suites (because 
> DH_anon suites are meant for one thing and one thing only: 
> unauthenticated but encrypted session). The client will send 
> a ClientHello message which will not contain a DH_anon suite, 
> but other cipher suites which expect a X.509 certificate from 
> the server. The server sends a certificate which cannot be 
> authenticated by the client.
> The client displays a warning to the user, but we cannot do 
> better than that since the client does not support 
> unauthenticated sessions: this is the "backward 
> compatibility" situation.
> 
> 
> 
> -- Make DH_anon suites more "supported" (newer TLS 
> specifications tell that DH_anon suites are obsolescent due 
> to the involved security issues(**)).
> 
> -- Define RSA_anon suites which should provide better 
> performance for computationaly challenged clients (RSA 
> encryption is cheap).
> 
> Both of these are issues for the IETF TLS mailing-list, not 
> the IETF PKIX mailing-list.
> 
> 
> To sum up, what you ask for _already exists_ in a better way 
> (less network traffic and less X.509 processing for the same 
> functionality).
> Of course, if you sell certificates, you will not like a 
> scheme where nobody uses certificates and, as such, nobody 
> buys certificates.
> 
> 
> 	--Thomas Pornin
> 
> 
> (*) Basically, unauthenticated but encrypted session are 
> useful only if the security model allows only passive 
> attacks. This is rarely a valid assumptions, but this is not 
> the issue in this discussion. We assume here that there are 
> plausible situations where unauthenticated but encrypted 
> sessions are what is needed.
> 
> (**) People involved in the definition of TLS do not believe 
> in the existence of plausible situations where 
> unauthenticated but encrypted sessions are what is needed. 
> This is why DH_anon suites are currently deprecated. But the 
> same people, and, more importantly from your point of view, 
> the TLS implementors will think just the same about any way 
> to get unauthenticated but encryted sessions, whether by 
> using the TLS features which have been designed for exactly 
> that usage (DH_anon), or by any X.509-related trickery such 
> as your fake certificates. So this is not an issue in this debate.
> 
>

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 11 Jun 2007 15:42:18 -0400

In order to achieve backwards compatibility with a billion browsers,
you would have to mark any new extension as non-critical, where it
would be ignored by every single browser currently in existence.

Therefore users would be told that their communication is secure while
issuing practices permit (no, positively encourage, once the word
on this extension gets out) web site spoofing.

If you want to use Peter's OID for this, no one can stop you.  But
the PKIX WG can refuse to assign an OID whose ostensible purpose is
to enable non-advertised encryption but whose actual effect on current
browsers would be to advertise secure communications while using
null-assurance certificates.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip

These are not anonymous communications, they are merely communications
that do not require the level of assurance that is necessary to alert
the user to tell tham that the communication is secure.
 
> > compatibility with a billion installed browsers. 

-----------

P.S., the difference between anonymous communications and
communications for which the participants can claim any desired
name (e.g. my webserver operating as https://www.verisign.com)
and into which third parties (e.g. hotel wireless APs) may
insert themselves eludes me. One definition of anonymous is
"unnamed", but the second definition is "of unknown origin".
Spoofed names certainly seem to fit the second definition.

---

From: "Peter Lipp" <[email-masked]>
Date: Mon, 11 Jun 2007 23:22:58 +0200

> The information to be encoded here relates to the issue practices of
> the certificate. Therefore they go into the certificate.
Like the warning sign for an unusable safety-belt that is sewn into the belt
saying: "manufactured without care, don't use for driving"? And the belt is
applied automatically too, without the user noticing, so he wouldn't be
realizing that the belt breaks...

Earlier on you wrote:
> In many cases all that is required is to turn on encryption.
This would be the case with TLS-anon-cipher suites. Because if "all that is
required" is encryption, we don't care how it is initiated. So there must be
a use case.... 

...like a pre-manufactured bulk certificate that you ship to your customer
who puts it into one shipped appliance, so you as the issuer have no full
control on what happens with the certificate (and probably pregenerated key)
and thus can't give out any warranties, but the overall procedure may be
safe enough for its purposes? Thus, if the certificate should be misused, it
might not do any harm elsewhere if this extension is in. Then there is a
difference to the anon-cipher-suite.

Otherwise, I don't get the point... Since you want to sell your
certificates, you should first sell your story better.

Peter

---

From: Trevor Freeman <[email-masked]>
Date: Mon, 11 Jun 2007 15:15:39 -0700

I have to agree with Dave here. For HTTPS these certificates would be practically useless for at least 5 years and probably more  given the lag time on OS and browser upgrades. Now other applications of TLS already support the concept of "confidentiality only" TLS with certificates. I am thinking here of SMTP. SMTP servers use "opportunistic TLS" where the SMTP server has a policy to pick the STARTTLS verb whenever it its offered by the receiving server. When operating under optimistic mode the sending server does not validate the receiving servers certificate because the alternative course of action with validation errors is to send in the clear. Because the sending server does not validate the receiving server certificate a common practice is to use self signed certificates which clearly make no warranty about the identity of the owner. Most use of TLS with SMTP over the internet uses opportunistic TLS.  I don't see why such a strategy does not work elsewhere if all you wa!
 nt is confidentiality. An interesting side bar is that the anonymous cipher suites would not work in this scenario because these same servers have a subset of domains they do want to authenticate. There is not enough data at the time of the negotiation for the receiving server to decide they do not want to authenticate the sending server so it has to pick a cipher suite with certificates then it has the option to skip validation or not later in the session.

Trevor

* -----Original Message-----
* From: [email-masked] [mailto:owner-ietf-
* [email-masked]] On Behalf Of Kemp, David P.
* Sent: Monday, June 11, 2007 12:42 PM
* To: [email-masked]
* Subject: RE: Three short fixes
*
*
* In order to achieve backwards compatibility with a billion browsers,
* you would have to mark any new extension as non-critical, where it
* would be ignored by every single browser currently in existence.
*
* Therefore users would be told that their communication is secure while
* issuing practices permit (no, positively encourage, once the word
* on this extension gets out) web site spoofing.
*
* If you want to use Peter's OID for this, no one can stop you.  But
* the PKIX WG can refuse to assign an OID whose ostensible purpose is
* to enable non-advertised encryption but whose actual effect on current
* browsers would be to advertise secure communications while using
* null-assurance certificates.
*
*
*
*
* -----Original Message-----
* From: [email-masked] [mailto:owner-ietf-
* [email-masked]]
* On Behalf Of Hallam-Baker, Phillip
*
* These are not anonymous communications, they are merely communications
* that do not require the level of assurance that is necessary to alert
* the user to tell tham that the communication is secure.
*
* > > The reason for using a certificate is to allow for backwards
* > > compatibility with a billion installed browsers.
*
*
* -----------
*
* P.S., the difference between anonymous communications and
* communications for which the participants can claim any desired
* name (e.g. my webserver operating as https://www.verisign.com)
* and into which third parties (e.g. hotel wireless APs) may
* insert themselves eludes me. One definition of anonymous is
* "unnamed", but the second definition is "of unknown origin".
* Spoofed names certainly seem to fit the second definition.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 11 Jun 2007 14:27:11 -0700

No: like the roll cage which is stamped 'not certified for competition
use'.

There are plenty of safety measure on my cars which I am completely
unaware of which are perfectly safe for normal road driving but not
designed for competition use.

Building a certification path up from the MAC address is prefectly
sensible and an appropriate use for PKIX. But it is not by itself
sufficient to present a trust statement. There is no accountability - by
design.

What I am working towards here is a multilayer security approach and I
want to use PKIX at a lower level than the SSL folk did.

> From: Peter Lipp [mailto:[email-masked]] 
> Sent: Monday, June 11, 2007 5:23 PM
> To: Hallam-Baker, Phillip; [email-masked]
> Subject: AW: Three short fixes
> 
> saying: "manufactured without care, don't use for driving"? 
> And the belt is applied automatically too, without the user 
> noticing, so he wouldn't be realizing that the belt breaks...
> 
> Earlier on you wrote:
> This would be the case with TLS-anon-cipher suites. Because 
> if "all that is required" is encryption, we don't care how it 
> is initiated. So there must be a use case.... 
> 
> ...like a pre-manufactured bulk certificate that you ship to 
> your customer who puts it into one shipped appliance, so you 
> as the issuer have no full control on what happens with the 
> certificate (and probably pregenerated key) and thus can't 
> give out any warranties, but the overall procedure may be 
> safe enough for its purposes? Thus, if the certificate should 
> be misused, it might not do any harm elsewhere if this 
> extension is in. Then there is a difference to the anon-cipher-suite.
> 
> Otherwise, I don't get the point... Since you want to sell 
> your certificates, you should first sell your story better.
> 
> Peter
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 11 Jun 2007 17:00:16 -0700

Case in point here being your S/MIME cert which does not satisfy my
Outlook chaining so give a warning.

Yet I can get mail from plenty of places without any security and
without a warning either.

Wouldn't it be nice if a cert could say 'the correct course of action if
you don't like me is to simply show the email without any indication the
message is secure'.

Why do folk feel that the user has to be told about merely sub-standard
security when 99% of the Internet has no security at all? 

> [mailto:[email-masked]] On Behalf Of Peter Lipp

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 12 Jun 2007 13:43:58 +1200

>   have any relationship whatsoever"

Sure, the latter was implied in the former.

>In other words, the name/email/URL could belong to Bank of America but the
>key pair and certificate request could have been created by Phish-R-Us, and
>no claims to the contrary are made by the issuer. 

More or less.  As I said, there are people using certs simply as a universal
container for a public key because there's nothing else available.  They don't
care about any cert semantics, they just need a means of getting a key from A
to B in a format that B can process.  Providing some means of indicating this
in the cert would be useful.

I'm not really too fussed about it, I'll let users keep using Xyzzy certs,
however if there's no centralised record of this you end up with a pile of ad
hoc approaches instead, including the current one of taking otherwise normal-
looking certs and ignoring all the cert semantics.  The choice is really:

  1) Use null-semantics certs that look like normal certs.

  2) Use null-semantics certs but at least mark them as such.

Of these two, (2) seems to be the better approach.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 12 Jun 2007 13:47:42 +1200

>I'm not really too fussed about it, I'll let users keep using Xyzzy certs,

Oops, what I meant with "Xyzzy certs" is that that's the name of the OID used
to indicate that the cert is merely a bit-bag for a public key.  Currently
it's used as a policy OID, which seemed to be the best place to put it,
although a standard extension would be a better way to handle it.  The policy
is "This certificate isn't worth the paper it's not printed on".

Peter.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 11 Jun 2007 20:25:42 -0700

The null assurance CAs are already out there :-(

Have been for five years :-(  :-(

> [mailto:[email-masked]] On Behalf Of Kemp, David P.
> Sent: Monday, June 11, 2007 3:42 PM
> To: [email-masked]
> In order to achieve backwards compatibility with a billion 
> browsers, you would have to mark any new extension as 
> non-critical, where it would be ignored by every single 
> browser currently in existence.
> 
> Therefore users would be told that their communication is 
> secure while issuing practices permit (no, positively 
> encourage, once the word on this extension gets out) web site 
> spoofing.
> 
> If you want to use Peter's OID for this, no one can stop you. 
>  But the PKIX WG can refuse to assign an OID whose ostensible 
> purpose is to enable non-advertised encryption but whose 
> actual effect on current browsers would be to advertise 
> secure communications while using null-assurance certificates.
> 
> 
> 
> 
> [mailto:[email-masked]]
> These are not anonymous communications, they are merely 
> communications that do not require the level of assurance 
> that is necessary to alert the user to tell tham that the 
> communication is secure.
>

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 18 Jun 2007 11:39:13 +1000

I like the idea of reverting to an “unsecured” look-n-feel and avoiding nag screens when the security, though present, is not “perfect”.

It is bad that many clients treat unconfirmed security (eg signed, but not by a locally-trusted root) as worse than no security. This discourages attempts to improve security.

I am less sure that a “no padlock” attribute is the right way to achieve this.

>Wouldn't it be nice if a cert could say 'the correct course of action if you don't like me is to simply show the email without any indication the message is secure'.

Wouldn’t it be better to fix email clients so they always act this way, instead of only triggering this behaviour for certain certificates? Unless it is a tactical decision that software vendors are more likely to implement a new certificate feature than change existing behaviour (especially if the latter might be branded as worsening security).

For HTTPS connections, a certificate without a subjectAltName.dNSName field (and no domain name in a common name component of the subject field) should be sufficient for a browser to say “well I cannot do the URL-to-cert check so I will display the page just like an HTTP page”: no coloured address bar, no locked padlock, no nag screens, still using TLS on-the-wire though. No path to a trusted root (eg a self-signed cert) should be treated the same way. Unavailable CRLs could be treated the same way.

Other errors such as an incorrect signature, expired certificate, or a mismatch between URL & cert name imply the certificate holder has done something wrong. I don’t have a problem with nag screens (or outright refusal to connect) in these cases.

PROBLEM

> I don't see why we need to tell the user that encryption is being used unless they have explicitly said that they need confidentiality.

The problem is that the HTTPS scheme in a URL implies a “safe” connection, regardless of a padlock icon or address bar colour. If a user didn’t know if the URL was HTTP or HTTPS (eg their browser automatically went there after an HTTP 307 redirect) then treating “unconfirmed security” as “unsecured” would be reasonable. On the other hand, if I choose my HTTPS bookmark for my bank then I expect my browser not to process any (potentially-malicious) html/javascript/activex/flash for any other source. If my browser (perhaps due to a DNS attack) silently accepted content not from my bank I would be worse off.

Any visibility of an HTTPS URL to the user could be considered as them explicitly saying they need confidentiality: choosing an HTTPS bookmark; typing HTTPS into the address bar; clicking on an HTTPS link when the URL was shown in the status bar before the click; even seeing HTTPS in the address bar after receiving a page can be enough.

From: Hallam-Baker, Phillip
Sent: Tuesday, 5 June 2007 3:37 AM
Subject: Three short fixes: no padlock; text logo; member since

…

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
Sent: Thursday, 7 June 2007 3:06 AM
To: Kemp, David P.; pkix

_____________________________________________
From: [email-masked] [mailto:[email-masked]] <mailto:%5bmailto:[email-masked]%5d>  On Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, 12 June 2007 12:24 AM

…

 

…

_____________________________________________
From: [email-masked] [mailto:[email-masked]] <mailto:%5bmailto:[email-masked]%5d>  On Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, 12 June 2007 3:45 AM

…The information to be encoded here relates to the issue practices of the certificate. Therefore they go into the certificate.

_____________________________________________
From: [email-masked] [mailto:[email-masked]] <mailto:%5bmailto:[email-masked]%5d>  On Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, 12 June 2007 10:00 AM

Case in point here being your S/MIME cert which does not satisfy my Outlook chaining so give a warning.

Yet I can get mail from plenty of places without any security and without a warning either.

Wouldn't it be nice if a cert could say 'the correct course of action if you don't like me is to simply show the email without any indication the message is secure'.

Why do folk feel that the user has to be told about merely sub-standard security when 99% of the Internet has no security at all?

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 20 Jun 2007 08:29:50 -0700

The issue here is backwards compatibility.
 
Any certificate issued today must work accaptably with existing browsers. That means chaining up to an embedded root. Under the rules as they are today a cert issuer can issue a certificate with essentially no meaningful authentication and many do.
 
The point is to allow an issuer to differentiate between certificates that are designed to provide a meaningful degree of accountability from those which are simply designed to turn on SSL in the deployed base of a billion browsers. Over time the deployment of browsers that observe the OID would increase.

If we were designing from scratch the sensible way to do this would be to have an OID with positive semantics 'assert security to the user'. Since we don't have that luxury and since we have to deal with the billion deployed browsers we need a different approach.
 
I do not agree with the sentiment that a standards process should only deal with perfect situations and stick its head in the sand when it comes to tough deployment issues. Managing the constraints of the deployed base should be the first concern for a WG that has been in existence for ten years. 
 
At least PKIX has a deployed base to worry about.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
	Sent: Sunday, June 17, 2007 9:39 PM
	To: pkix
	Subject: RE: Three short fixes: no padlock; text logo; member since

	PROBLEM

	 

	…

	…

	 

	…

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 29 Jun 2007 15:21:59 +0100

Some general comments on the three short fixes after studying the debate.

I don't believe an update of the logotype RFC is motivated. If there is a need for a Community Attribute however is an open issue. The X.509 model is extensible and new attributes can be defined by anybody for any purpose.

This is the same as 1). If the e-commerce or other parts of any market needs a member since attribute. They could define one. The question for me is if this belongs within PKIX.

The decision to display a padlock or anything else is an application issue, under the application's control. No CA is authoritative over that decision and as such, an attribute or extension aimed to control this seems as a bad solution. I agree that this is better solved by negotiating TLS ciphersuites rather than through certificate content. I may for example want to use the same certificate for both types of sessions.

Stefan Santesson
Senior Program Manager
Windows Security, Standards