Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)

From: Peter Gutmann <[email-masked]>
Date: Tue, 17 Feb 2004 02:24:06 +1300

Stephen Kent <[email-masked]> writes:

>I'm tempted to view this comment as consistent with the vast majority of your
>comments, which seem to be described as "if a vendor screws up in
>implementing a standard, then if the vendor achieves sufficient market share,
>let's change the standard to match the vendor's screwed up implementation."

The issue of what to do with policies doesn't have a right or wrong answer,
there are many different ways of doing this and all (well, at least many) of
them are acceptable for different scenarios.  In this case if the majority of
the market (presumably acting under the advice of lawyers or applying some
similar analysis) has decided that the most prudent way to handle policies is
to do X when PKIX (more or less arbitrarily, see Santosh' comments that
there's nothing preventing you from doing this) says Y, then it's a sign that
PKIX needs to address X.

>I'm tempted to view this comment as consistent with the vast majority of your
>comments

I'm tempted to view this comment as consistent with the vast majority of your
comments, which seem to be described as:

"Gosh, look at all these idiots going the wrong way down the motorway!  I'm
 the only person who's going in the right direction.  Since I know what I'm
 doing is right, I'll just keep going in this direction even if it kills me.
 They can use 'But I was right, dammit!' as my epitaph".

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Feb 2004 09:42:25 -0500

>there's nothing preventing you from doing this) says Y, then it's a sign that

I am less convinced that use of "CA = policy" is a result of any 
careful deliberation, legal advice, etc. It seems as likely that 
adooting this trivial model is a result of carrying forward the only 
policy management capability that was present in X.509 v1, plus the 
limited (practically non-existent) policy management UIs that vendors 
have typically offered.

>  They can use 'But I was right, dammit!' as my epitaph".

When I last visited New Zealand I did mange to drive on the locally 
proper side of the road, accommodating local "policy" conventions 
that are certainly not mainstream when viewed on a global basis. 
Maybe that's the basis of your skewed viewpoint on this and other PKI 
subjects, Peter: you live in a country that drives on the opposite 
side of the road from the vast majority of the rest of the world, and 
as a result you tend to be overly sensitive to the notion that the 
majority must always be right, despite your experience to the 
contrary.

More seriously, if mere prominence of a given product or mode of use 
were the primary factor in determining what is "right" then we would 
all use only MS software, running on x86 processors, only eat fast 
food, watch reality television, ...   Good standards require more 
that merely endorsing trends, especially when the trends are short 
sighted.

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 16 Feb 2004 19:34:28 +0100

>limited (practically non-existent) policy management UIs that vendors 

To be able to administer policies in a (G)UI that has any similarity
to other security related administration tools, you should at least know
which policies that are supported by a CA and what they mean.
There is no such data available in X509.v3.  To build 21st century
systems using a Neanderthal type of UI is not going to "sell" PKI.

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 17 Feb 2004 08:55:50 +0100

http://www.ietf.org/rfc/rfc2246

TLS and SSL which are very popular security protocols
do not support client certificate filtering using policy OIDs.

And what does that mean?

The example that David Cross mentioned, having two
different policies for "soft" and "hard" keys would in a
multi-policy-CA scheme in some cases show up as two
choices for the user but only one may actually work.  Using
discrete CAs supporting different policies, users will only
get valid options to select from.

Current multi-policy-CA incompatibility list:
- Major off-the shelf software (IE, Outlook, IIS)
- TLS
- Most trust store management systems
- Common PKI knowledge level
- Streamlined administration support

Ladies & Gentlemen, the choice is yours.

Anders

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Tue, 17 Feb 2004 12:39:45 +0100 (CET)

In message <005601c3f52b$77192000$0500a8c0@arport> on Tue, 17 Feb 2004 08:55:50 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> http://www.ietf.org/rfc/rfc2246
anders.rundgren> 
anders.rundgren> TLS and SSL which are very popular security protocols
anders.rundgren> do not support client certificate filtering using policy OIDs.
anders.rundgren> 
anders.rundgren> And what does that mean?
anders.rundgren> 
anders.rundgren> The example that David Cross mentioned, having two
anders.rundgren> different policies for "soft" and "hard" keys would in a
anders.rundgren> multi-policy-CA scheme in some cases show up as two
anders.rundgren> choices for the user but only one may actually work.  Using
anders.rundgren> discrete CAs supporting different policies, users will only
anders.rundgren> get valid options to select from.

So, let's see, you're talking about having a whole site (say, if we're
talking HTTPS) that would only accept "hard" people, where the
"soft"ies wouldn't have access at all (as an example)?  Although I
find very little use for that idea, I can see that it should be
addressed in some way from a principle point of view, and perhaps to
minimise the users' trauma for being rejected when the choose the
wrong cert.

anders.rundgren> Current multi-policy-CA incompatibility list:
anders.rundgren> - Major off-the shelf software (IE, Outlook, IIS)
anders.rundgren> - TLS
anders.rundgren> - Most trust store management systems
anders.rundgren> - Common PKI knowledge level
anders.rundgren> - Streamlined administration support
anders.rundgren> 
anders.rundgren> Ladies & Gentlemen, the choice is yours.

I choose to develop for tomorrow.  You?

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

---

From: "Al Arsenault" <[email-masked]>
Date: Tue, 17 Feb 2004 08:16:29 -0500

Actually, RFC 2246, TLS 1.0 protocol spec, says:

 All certificate profiles, key and cryptographic formats are defined
   by the IETF PKIX working group [PKIX].

(That's in section 7.4.2, towards the bottom of page 38.)  The reference,
[PKIX], points to RFC 2459.

In this area, then, TLS supports what PKIX supports.

So Anders' statement that "TLS and SSL which are very popular security
protocols do not support client certificate filtering using policy OIDs" is
incorrect.  It may be the case that one or more popular implementations of
TLS/SSL do not support such certificate filtering, but that's not the same
as the protocol not supporting it.

(And I'll go even farther and point out that we've heard some vendors of
popular software that their code does in fact support such filtering.  I'd
accept that it's not turned on by default and may not be "easy" to turn on,
but that's not the same as not supporting it.)

As far as choosing what options to support/who to support, well, we
generally choose to provide our customers what they want and are willing to
pay for.  If we believe that our customers don't really understand what
they're asking for, we'll try to educate them and make them understand what
the issues really are and what they are/should be asking for; and in extreme
cases we might even decline a commission if the customer insists on
something that's really wrong, but in general the customer is right.

The fundamental issue here is that different customers want different
things.  The fact that Anders' customer base (or anybody else's, for that
matter) seems to want one set of things is fine; it does not make that the
only customer base in the world nor the only set of requirements in the
world.  For that reason, PKIX (and most other standards) has options that
can be tailored to the specific needs of the specific customer.

(As a concrete example: in a previous life I had a customer who insisted
that subscribers' national ID numbers had to be encoded in a specific form
and then inserted into an X.509v3 certificate, in the subjectAltName field
as type dNSName.  Wouldn't have been my first choice, but hey, the customer
paying the bills is always right. Okay, we can support that in PKIX, but we
certainly aren't going to mandate it.)

			Al Arsenault

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Anders Rundgren
> Sent: Tuesday, February 17, 2004 2:56 AM
> To: [email-masked]
> Cc: [email-masked]; Santosh Chokhani; David Cross
> Subject: TLS: No policy OID. Was: Policy User Interfaces (was RE:
> Setting X.509 Policy Data in IE, IIS, Outlook)
>
>
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Feb 2004 09:37:30 -0500

>do not support client certificate filtering using policy OIDs.

SSL is an "industry standard," a polite way of saying that one vendor 
created it in a closed context and other vendors copied that 
implementation in an effort to capitalize on an extent market. SSL, 
as published in an IETF Informational RFC, doesn't even discuss how 
to process certs, only to convey them.
Cert processing is a matter covered under HTTPS, which was not 
addressed by any standards document until fairly recently. So, is 
this yet another example from you of "products implementing protocol 
Y don't do X, so X can't be important?" Products implementing SSL 
also didn't do any form of cert status checking for years. Did that 
mean that such checking was unimportant?

Anders, when are you going to realize that working backwards from 
what IS available in products is a bad way to determine what SHOULD 
be available.

Steve

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Tue, 17 Feb 2004 16:11:22 +0100 (CET)

In message <[email-masked]> on Tue, 17 Feb 2004 08:16:29 -0500, "Al Arsenault" <[email-masked]> said:

aarsenau> Actually, RFC 2246, TLS 1.0 protocol spec, says:
aarsenau> 
aarsenau>  All certificate profiles, key and cryptographic formats are defined
aarsenau>    by the IETF PKIX working group [PKIX].
aarsenau> 
aarsenau> (That's in section 7.4.2, towards the bottom of page 38.)
aarsenau> The reference, [PKIX], points to RFC 2459.
aarsenau> 
aarsenau> In this area, then, TLS supports what PKIX supports.
aarsenau> 
aarsenau> So Anders' statement that "TLS and SSL which are very
aarsenau> popular security protocols do not support client certificate
aarsenau> filtering using policy OIDs" is incorrect.  It may be the
aarsenau> case that one or more popular implementations of TLS/SSL do
aarsenau> not support such certificate filtering, but that's not the
aarsenau> same as the protocol not supporting it.

Uhmm, I think you misunderstood what Anders asked about.  The part of
TLS that governs what certificates a client will try to use for
authenticate is the ClientCertificateRequest message.  That message
can only contain requests on certificate types and issuer DNs.  The
way I understand what Anders asks for, he complains about the absence
of policy OIDs in that message, thereby indicating to the client what
policies are accepted, and thereby limiting the choice of certificates
that is presented to the user of said client software, perhaps even
down to 1 certificate.

Anders asserts the absence of anything policy-related in
ClientCertificateRequest is yet another proof that multi-policy CAs
are just awkward.

Seen from Anders' point of view (as I understand it, it's about
minimising the amount of stuff a user has to keep track of), I
perfectly undrstand what he talks about.  I don't share his view,
though.  My view is that if a user has enough trust to be handed more
than certificate, he should have enough knowledge to use them
properly.  The flaw really lies in client software that currently do
not show policy information in any kind of way (uhmm, except if you
choose to look at a complete view of the certificate in question,
where you must search manually for the policy extensions and know how
to extract the data you need from them).  Client software could show
the policies associated with each certificate, perhaps with some
friendly name, to make it easier for the user to make an appropriate
choice.

-----

---

From: Eric Rescorla <[email-masked]>
Date: 17 Feb 2004 07:57:23 -0800

> do not support client certificate filtering using policy OIDs.

Actually, TLS is totally agnostic on this front, since it just
incorporated PKIX by reference. It's true that I don't
know of any TLS implementation that makes this easy
(though you can generally extract the cert and check for
yourself).

What doesn't work is that there's no way for peer A to signal
peer B that it wants a specific policy. Is that what you're 
talking about?

-Ekr

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 17 Feb 2004 17:09:35 +0100

Eric.
Richard Levitte wrote:

"The part of TLS that governs what certificates a client will try to use for
authenticate is the ClientCertificateRequest message.  That message
can only contain requests on certificate types and issuer DNs"

This is what we are talking about.

BTW, why didn't you include policy OIDs?

Anders

----- Original Message -----
From: "Eric Rescorla" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Santosh Chokhani" <[email-masked]>; "David Cross"
<[email-masked]>
Sent: Tuesday, February 17, 2004 16:57
Subject: Re: TLS: No policy OID. Was: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)

-Ekr

---

From: Eric Norman <[email-masked]>
Date: Tue, 17 Feb 2004 12:36:24 -0600 (CST)

> do not support client certificate filtering using policy OIDs.

But they do.  Well somewhat at least.

The give you the ability to say in the client certificate request,
"please send me a certificate that has one of these CAs in the chain".
If you adopt the policy = CA notion, this provides what you seem to
be asking for (like I said, somewhat).

Eric Norman

	"Congress shall make no law restricting the size of integers
	that may be multiplied together, or the number of times that
	an integer may be multiplied by itself, or the modulus by
	which an integer may be reduced".

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 17 Feb 2004 17:09:35 +0100

Eric.
Richard Levitte wrote:

Anders

----- Original Message -----
From: "Eric Rescorla" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Santosh Chokhani" <[email-masked]>; "David Cross"
<[email-masked]>

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 17 Feb 2004 08:44:00 -0800

> This is what we are talking about.

Ok. that wasn't entirely  clear from your message.

> BTW, why didn't you include policy OIDs?

TLS is a lineal descendent of SSL, which predates PKIX by quite some
time. The certificate request syntax in SSL didn't contain any support
for auxiliary information and it just never got added to TLS.
Remember that TLS client authentication is a fairly unwidely used
feature in any case.

-Ekr

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 17 Feb 2004 17:58:02 +0100

Eric,

>for auxiliary information and it just never got added to TLS.

I sort of guessed that.

>Remember that TLS client authentication is a fairly unwidely
>used feature in any case.

I believe the full message is rather that client certificates are still
uncommon.

This will however change but it is possible that TLS' client-auth
will not be used as most of the systems I have seen, rather use Java
applets for authentication.  This is due to the fact that the client-side
PKI in browsers is generally not that useful anyway, as browsers
cannot sign web content. 

It really looks like client-side PKI is still in its infancy.

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 17 Feb 2004 23:01:13 +0100

Hi again Eric,

We met at PKI Workshop 2003 if you remember.

> Eric Norman  wrote:

>be asking for (like I said, somewhat).

Yup, this is the essence of policy=CA, it works all the time!

I noted that you have chosen this approach as well in Internet2,
as there were not a sign of any policy OIDs in the cert you signed
with.  Personally, I have no problem with the OID itself as long
as it stays fixed within a CA.

Anders

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 18 Feb 2004 11:10:46 +0100

Anders Rundgren wrote:

>This will however change 
Hey, maybe it's not very widely used in the public, but as a 
professional involved in the domain most anything of what I deploy 
involves using this.

>but it is possible that TLS' client-auth
And again from my professional point of view, the java applet domain has 
it's own problem, because it's just as difficult to get them to interact 
with the locally available certificates.

The java applet ends up using it's proprietary certificate store, so it 
will only have the exact needed certificate(s). As a result, we don't 
have to worry about sophisticated methods to choose the proper one.

You end up with a one cert per application model, but this is not much 
of interoperability and quite an obstacle to wider scale deployments.

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 18 Feb 2004 14:58:43 +0100 (CET)

In message <028701c3f577$34cc1850$0500a8c0@arport> on Tue, 17 Feb 2004 17:58:02 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> It really looks like client-side PKI is still in its
anders.rundgren> infancy.

Entirely depends on what you look at.  If you look at http thingies,
then yes, it seems like PKI has been mostly a server certificate
thingy (with a few exceptions, like SkandiaBanken that makes use of
client certificates).  However, if you look at things like S/MIME, you
see a lot more use of client certificates (you basically can't use
S/MIME without your own certificate).

-----

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 18 Feb 2004 20:32:30 +0100

>of interoperability and quite an obstacle to wider scale deployments.

Agreed.

But since digital signatures in browsers is not on any organizations
public agenda, Java is what we will deal with.   This excludes the 
standard client-side PKI support entirely as you cannot really have
two different crypto store systems (auth+sign).

So those who claim that Microsoft can't do crypto[1], don't worry,
CryptoAPI will soon do very little on the Internet w.r.t. clients certs.

Anders

1] I don't.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Feb 2004 09:37:30 -0500

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 17 Feb 2004 17:58:02 +0100

Eric,

I sort of guessed that.

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 17 Feb 2004 17:09:35 +0100

Eric.
Richard Levitte wrote:

Anders

----- Original Message -----
From: "Eric Rescorla" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Santosh Chokhani" <[email-masked]>; "David Cross"
<[email-masked]>

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 17 Feb 2004 08:44:00 -0800

-Ekr

---

From: Eric Norman <[email-masked]>
Date: Tue, 17 Feb 2004 12:36:24 -0600 (CST)

Eric Norman

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Tue, 17 Feb 2004 16:11:22 +0100 (CET)

-----