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

From: [email-masked] (Peter Gutmann)
Date: Tue, 3 Feb 2004 18:51:22 +1300

"David P. Kemp" <[email-masked]> writes:

>When you are outfitting 4.3 million people, you don't buy them all $25 fuzzy
>dice if a plain $5 cert is good enough.  Do you suppose the people who make
>DoD policy might have some cyber threat information that makes them believe
>the extra cost is worth it?

Oops, I forgot my traditional request for people not to dig up the US DoD as a
representative example, since they could also be used as an example of the
need for X.400 and other oddities that the rest of the world has ignored.  No
offence to people working in that environment, but it's not even remotely
representative of real-world usage (if the US DoD did set the pace for the
rest of the world, we'd all be driving olive-drab 4WDs with pushbutton
ignition and no suspension).

>Do you suppose "policy=CA" just won't cut it in an interoperable environment
>unless you force all of your information owners to become high priests?

In that case publish all the details in SDN.706 (which means you can set
things up exactly the way you want it), and include a note in bride-of-3280 to
say that this area is subject to application-specific standardisation by
specific industry bodies.  This saves people reading the RFC having to spend a
lot of time figuring out that they should ignore that part of the spec because
it doesn't apply to them.

Peter.

---

From: "Al Arsenault" <[email-masked]>
Date: Tue, 3 Feb 2004 10:04:55 -0500

Okay, then how about the Canadian Government?  See
http://www.cio-dpi.gc.ca/pki-icp/guidedocs/cert-policy/aboutCP_e.asp

Some selected quotes:

"This document defines eight certificate policies for use in the Government
of Canada Public Key Infrastructure (GoC PKI), representing four different
assurance levels (Rudimentary, Basic, Medium, and High) for both Digital
Signature and Confidentiality public key certificates. "

"GoC PKI certificates contain a registered certificate policy object
identifier (OID), which may be used to decide whether or not a certificate
is trusted for a particular purpose."

"Each CA is accredited to support one or more CPs, which it proposes to
implement."

Seriously, ignoring bashing of any particular organization (US DoD, VeriSign
or Microsoft, for example), the bottom line is that different organizations
have different requirements.  Some want or need multiple-policies-per-CA,
while others don't.  Some need interoperability (like, say, the US and
Canadian Government PKIs), while others don't. That's fine - it's a big,
diverse world and we don't all have the same requirements.

The controversy seems to be that 3280 requires that CAs and RPs support the
Cert Policies extension. Okay, if somebody wants it to be optional, that
could be a change made.   However, what I've seen in this thread is that
both Microsoft and Sun support the extension already.  A lot of custom RP
apps support it as well.  And in general it's just not that big a deal for
most environments, despite the protestations of a few.

So - is there support (other than Anders and Peter) for changing 3280 to
make support for Cert Policies optional instead of required?

		Al Arsenault

And I know I shouldn't, but I can't help myself, so a few responses:

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Peter Gutmann
> Sent: Tuesday, February 03, 2004 12:51 AM
> To: [email-masked]; [email-masked]
> Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data
> in IE, IIS, Outlook)
>
>
>
> need for X.400 and other oddities that the rest of the world has
> ignored.

As opposed to "how (insert-name-of-company-or-academic-institution-here)
does it"? Look, no organization has ever made all the right technology
choices, and the US Government does have a tendency to sometimes hang on to
bad decisions far longer than it should, but there's a lot that was done
right.

>No

Umm, two things. First, HUMVEEs aren't the only thing in the US DoD fleet;
but it's just not sexy to show a clip on TV of a Ford Taurus driving down
the street.  Second, HUMMERs are starting to sell reasonably well, just as
Jeeps always have.  They're not for everybody, but they're out there. My
point being that different people have different requirements, but it's not
a case of "those guys over there aren't in the real world".  They're in the
real world, it's just a different part of the  real world than you inhabit.

> it doesn't apply to them.

Or maybe just change 3280 to make cert policies optional vice mandatory, so
those people who need policy!=CA but aren't subject to SDN.706 can still
find the information?

---

From: Michael Ströder <[email-masked]>
Date: Wed, 04 Feb 2004 07:06:18 +0100

> make support for Cert Policies optional instead of required?

Yes.

Ciao, Michael.

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 11 Feb 2004 21:33:40 +0100 (CET)

In message <[email-masked]> on Tue, 3 Feb 2004 10:04:55 -0500, "Al Arsenault" <[email-masked]> said:

aarsenau> So - is there support (other than Anders and Peter) for
aarsenau> changing 3280 to make support for Cert Policies optional
aarsenau> instead of required?

No.  That would make policies thoroughly unusable, since everyone
would be able to ignore them anyway (in practice, many still are
today, but lets look at the future, eh?).

-----
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: Steve Hanna <[email-masked]>
Date: Wed, 11 Feb 2004 16:39:53 -0500

Al Arsenault wrote:
> So - is there support (other than Anders and Peter) for
> changing 3280 to make support for Cert Policies optional
> instead of required?

No. Implementing support for certificate policies
is not that hard. If a user or application doesn't
want to use policies in their PKI, they don't have to.
But leave in the requirement to implement so that people
who want to use policies can do so using COTS software.

One other thing. We're starting to see RFC 3280
compliant path validation libraries come out.
PLEASE stop moving the target by tweaking the
standards (or proposing to do so). At this point,
we shouldn't change RFC 3280 except for clarifying
things and fixing serious errors. Otherwise, we'll
NEVER get things working.

Thanks,

Steve

---

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

In message <[email-masked]> on Wed, 11 Feb 2004 21:33:40 +0100 (CET), Richard Levitte - VMS Whacker <[email-masked]> said:

levitte> 
levitte> In message <[email-masked]> on Tue, 3 Feb 2004 10:04:55 -0500, "Al Arsenault" <[email-masked]> said:
levitte> 
levitte> aarsenau> So - is there support (other than Anders and Peter) for
levitte> aarsenau> changing 3280 to make support for Cert Policies optional
levitte> aarsenau> instead of required?
levitte> 
levitte> No.  That would make policies thoroughly unusable, since everyone
levitte> would be able to ignore them anyway (in practice, many still are
levitte> today, but lets look at the future, eh?).

I need to comment on this: policy extension may be marked critical or
may not.  When it's non-critical, it's already optional (as long as
support for certificatePolicies isn't implemented in your software).

So the question is, Al, what exactly are you asking for?  That
certificatePolicies should be possible to ignore even if your software
has implemented support for it?  Some kind of "Extra Non-Critical"
bit?  Sounds like a kludge big time to me.

The way I see it, what you're asking for is already there, just don't
set the critical bit on the cerificatePolicies extension.  Of course,
as someone has already said, that would mean that some software would
consider some invalid paths valid, which is a problem.

Let me ask you this: if your software already supports treatment of
certificatePolicies, why should it avoid handling that extension in a
proper way?  You don't want to insult your programmers by not using
the code they've put joy, tears, blood and whatnot in, do you?

So my answer is still no, mostly because what you ask for is already
there...

-----

---

From: "Al Arsenault" <[email-masked]>
Date: Thu, 12 Feb 2004 08:35:30 -0500

> [mailto:[email-masked]]On Behalf Of Richard Levitte - VMS
> Whacker
> Sent: Wednesday, February 11, 2004 4:55 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Policy User Interfaces
>
>

Well, "world peace" and "the winning lottery ticket" are always nice things
to ask for.  :-)

Seriously, my question was posed based on my understanding of what it means
when an RFC like 3280 requires support for a feature.  That is, the feature
is required to be present in the code; it is not necessary that it be used
in any given instantiation (unless that is specified).

So, when RFC 3280 requires that conforming CAs MUST support (among others)
cert policies, a conforming CA must contain code which can create a
certificate with a valid Cert Policies extension. It does not mean that a
particular user of that CA product must create certificates with that
extension present; OR that certificates with the cert policies extension
present must mark it critical or non-critical.

(Note that since certificatePolicies is a SEQUENCE SIZE (1..MAX) OF
PolicyInformation, this necessarily means that the code can support >1
policy per CA.  It doesn't mean any given customer ever has to use that in
practice, just that the code has to be able to support it if somebody wants
to build a system that way.)

Similarly for relying party software.  Right now, a conforming application
must recognize (among others) the certificate policies extension.  That does
not mean that all certificates the application will process have the
extension in them; just that if there is such a certificate with the
extension marked critical, the application can't reject the certificate for
lack of recognizing the extension.

So, if support for the cert policies extension is made optional, this means
it would be okay:

	- to build a CA implementation that is not capable in any circumstance of
populating the certificate policies extension, and still call that CA
"conforming".

	- to build an RP application that does not recognize the certificate
policies extension, and still call that application "conforming".  Thus, if
such an RP application encountered a certificate with a critical
certificatePolicies extension, that application would fail to validate the
certificate, and this would be "conforming" with PKIX.

The implication is that, under the current requirement, the developer has to
write some (a lot of?) code to process those situations where somebody does
put in the full cert policies stuff, with all the chrome, tail fins, etc.
about which Peter speaks.  (And it has to be documented, tested, etc.) If we
change, the developer doesn't have to write that code.

That was the question I asked - was there any support for changing 3280 to
eliminate the need for the developers to write this code?

(Although I didn't explicitly ask this question, there probably is a "middle
option", where the definition of certificatePolicies is changed to just
allow one instance of PolicyInformation - i.e., mandate "policy = CA". That
might save some code writing.)

We haven't had a straw poll, and I think doing so would be a waste of time
and bits, but so far only Peter G., Michael Stroder, and Anders R. (sort of)
have supported this change.  There have been a number of resounding "NO"
opinions expressed, from Steve Hanna, Rich Guida, Santosh, and yourself,
Richard.

My own opinion is also to keep 3280 the way it is.  There's nothing in 3280
that requires any PKI user to implement cert policies, or that they support
>1 cert policy per CA.  Conforming products should have this code in them,
though.  We can argue all day (and it wouldn't be the first time) on how
user-friendly or not; or how elegant or not; the implementation of the code
and the user interface to these features is.  But that's not relevant to
whether or not it should be a 3280 requirement.

I base my opinion on the following:

	- there are some customers/PKI users who explicitly want and are using
these features, for sound security and efficiency reasons (the fact that
some people on this list don't interact with those PKI users isn't relevant;
they exist and proclaim to want the features)

	- a number of significant producers of PKI products, both CA and
application, have said that they already support this requirement.  Largely,
we've just discussed how elegant their user/management interfaces are, not
whether they lied when they said they supported this requirement

Now, as always, PKI has a long way to go before it can "take over the world"
as was once promised.  I think most of us know that PKI was overhyped and
overpriced, as well as misunderstood and probably targetted at the wrong
problem way too often.  But I don't think that changing 3280 to make support
for cert policies optional will help that; nor do I think changing 3280 to
modify certpolicies so that only one policy is permitted will help.

					Al Arsenault

---

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

In message <[email-masked]> on Thu, 12 Feb 2004 08:35:30 -0500, "Al Arsenault" <[email-masked]> said:

aarsenau> > So the question is, Al, what exactly are you asking for?
aarsenau> > That certificatePolicies should be possible to ignore even
aarsenau> > if your software has implemented support for it?  Some
aarsenau> > kind of "Extra Non-Critical" bit?  Sounds like a kludge
aarsenau> > big time to me.
aarsenau> 
aarsenau> Well, "world peace" and "the winning lottery ticket" are
aarsenau> always nice things to ask for.  :-)

:-) Thanks for the good laugh, Al.

Seriously, I understand better what you asked for now.

A small detail:

aarsenau> (Although I didn't explicitly ask this question, there
aarsenau> probably is a "middle option", where the definition of
aarsenau> certificatePolicies is changed to just allow one instance of
aarsenau> PolicyInformation - i.e., mandate "policy = CA". That might
aarsenau> save some code writing.)

I'm not sure how that would change things, or maybe I've just gravely
misunderstood how this is supposed to work?  The way I understand it,
the policy OID for a specific certificate is placed in the certificate
issued by the CA, not the CA certificate, so basically, you could have
the following:

+----+          +----------+
| CA |--------->| EE1      |
+----+          | Policy A |
  |             +----------+
  |
  |             +----------+
  +------------>| EE2      |
                | Policy B |
                +----------+

Those would be two EE certificates, issued with different policies and
still satisfying there only being on policy in certificatePolicies
(which then should be renamed to certificatePolicy :-)).

According to the path verification algorithm presented in RFC 3280, if
there are policies in a root certificate, they aren't even glanced at,
so that would imply there's no need to place policy certificates in
root certificates.  This is the part where I'm not 100% sure, though.
If I'm right, there's no technical way to limit a CA to only one
policy.

-----