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

From: "Guida, Richard [JJCUS]" <[email-masked]>
Date: Tue, 10 Feb 2004 20:07:16 -0500

I second Santosh's point.  For those of us who believe policy OIDs will
indeed become an important tool in many regulatory environments at a
minimum, what is wrong with preserving the extension to support such
anticipated uses (which are actually beginning to materialize - at least
within enterprises)?  Is anyone marking the certPolicies extension critical?
If not, then relying party software is free to ignore it.  Policy OIDs for
the masses may be "an OID too far" but policy OIDs in specific communities -
and within enterprises - are useful.  We issue hardware and software
signature certificates but only allow the former for remote access; how do
we tell which is which?  Different policy OIDs in the certPolicies
extension.

Richard A. Guida
Director, Information Security

Johnson & Johnson
Room GS8217
410 George Street
New Brunswick, New Jersey  08901
Phone:  732 524 3785

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Santosh Chokhani
Sent: Tuesday, February 10, 2004 2:11 PM
To: [email-masked]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data
in IE, IIS, Outlook)

To All Those who want to simplify 3280 and get rid of policy stuff:

What problems are your applications encountering with the certificates in
the area of policy processing?  Specific examples only.

Based on the knowledge I have of some of the PKIs and based on your
statements that no one wants to use this stuff, and your applications do not
prime the path validation engine with any policy (no pun intended), the only
likely failure I see is the one for require explicit policy.  For that, I
have told X.509 folks that a better design will be to output the value of
require explicit policy to the application without causing a failure.

If that is done and you do not care about policies, certification path
validation engine could be 3280 and X.509 compliant and you can ignore all
policy related inputs and output and go on you merry way doing PKI and
policy geeks can dance with their policy crap.

Sounds like a great solution (not even compromise) to make both camps happy.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean Pawluk
Sent: Tuesday, February 10, 2004 6:42 AM
To: 'Lars Johansson'; 'Peter Gutmann'
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)

Bravo

 Practical PKI as a goal should to be encouraged as much as possible.

 The sheer complexity and awesome flexibility of the many standards in this
area is limiting the everyday use of PKI technology in new application
areas.

Jean

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Lars Johansson
Sent: Tuesday, February 10, 2004 3:53 AM
To: Peter Gutmann
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)

Dear list,

Let me add my 0.01 euros to this thread...

Several people have argued that a CA <-> Policy paradigm would be much
simpler for most PKI users (specifically outside the government sector) to
grasp and use. However I object that this paradigm would be the most simple
one. Stated formally, what I claim is the following:

Claim: There exists a PKI paradigm that is simpler than the CA <-> Policy
paradigm. In particular the specific PKI paradigm requires that the
correspondence between CA and Policy mustn't be 1-1 (injective).

Proof: The proof works by giving a counterexample. Consider
an "utopic" world in which all existing CA:s have agreed on a common single
Policy. Clearly this PKI paradigm would be much simpler to grasp and use for
all relying parties in all sectors! However this implies a many-to-one
mapping between CA:s and the single policy, a mapping which is impossible to
achieve with the CA <-> Policy paradigm. QED.

Conclusion: If simplicity is a goal (and I agree that it should) then let's
focus on standardisation of practical certificate- policies which can be
shared by several different CA:s instead of debating wheather policy-OID:s
should exist or not.

That's my opinion! _________________________________________________
Lars Johansson M.Sc.| Consultant
[email-masked] | www.omegapoint.se
phone +46 70 915 88 40 | fax +46 8 545 106 93
Omegapoint AB

-------------------
>
> "Al Arsenault" <[email-masked]> writes:
>
> >Okay, then how about the Canadian Government?  See
>
>http://www.cio-dpi.gc.ca/pki-icp/guidedocs/cert-policy/aboutCP_e.asp
>
> The problem is that at the moment we're stuck with having to support
an
> extremely complex and awkward mechanism to accomodate a vanishingly
small
> number of users at the expense of a large majority who don't want to
know or
> care about it, being quite happy with policy=CA.  The "vanishingly
small"
> number currently stands at two, in theory there'd be at least a
third,
> Gatekeeper, but since the government department in charge of it has
had a
> spokesman announce that "I am very grateful for the fact that, at
the moment,
> none of my colleagues has come up with a good use for it. When they
do, I will
> have to do something about it" we'll call it two, and maybe even one 
> eventually depending on whether the Canadian work has reached the
Gatekeeper
> stage yet or not.
>
> >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?
>
> Exactly.  So in order to be useful (and applicable) to all users,
the RFC
> could say something like:
>
>   There's an easy way and a hard way to do this.  The easy way
involves
>   CA=policy.  The certificatePolicies MUST contain a single policy
entry with
>   a policy URL or text, MUST NOT contain user notices and notice
numbers and
>   whatnot, and DEFINITELY MUST NOT involve policy constraints,
policy
>   mappings, fuzzy dice, and two-tone paint jobs.  The hard way
involves multi-
>   policy CAs and a lot of Tylenol, for which see the current text.
>
> That way the majority of users can pick the straightforward option
that does
> what they want, and everyone who wants to do it the complex way can
also do
> that.
> Peter.

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 11 Feb 2004 08:42:47 +0100

Richard,  Santosh et al,

The only real compromise satisfying those who "believe" in policy
OIDs and those who don't is to gradually begin deploying CA
roots supporting a single policy.  That is, if you need another
policy you should create an additional independent CA root.

Why?  Community PKIs using multiple policies work just fine
as long as you:

1) mainly build your own relying party software.
2) know that you will only expose the PKI within that specific
    community. 
3) assume that cross-certification is something that works
    on a many-to-many basis potentially involving thousands of
    often volatile business relationships.

That is, the decision to use multiple policies per CA, MAY prove
to be a bit problematic in the long run.

*I* do NOT AT ALL suggest modifying RFC3280, but maybe creating
a profile and extension explicitly supporting single policy CAs.

As I have also written numerous times, such schemes offer a
metadata possibility that can make policies from unknown CAs
easier to deal with.

I would be interested to get a list of disadvantages of single-
policy CAs.  Particularly with respect to relying parties here
constituting of end-users, administrators and ISVs.

Anders

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 11 Feb 2004 09:50:18 -0500

Anders:

You can do that now without changing 3280.

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]] 
Sent: Wednesday, February 11, 2004 2:43 AM
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [email-masked]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)

Richard,  Santosh et al,

The only real compromise satisfying those who "believe" in policy OIDs and
those who don't is to gradually begin deploying CA roots supporting a single
policy.  That is, if you need another policy you should create an additional
independent CA root.

That is, the decision to use multiple policies per CA, MAY prove to be a bit
problematic in the long run.

*I* do NOT AT ALL suggest modifying RFC3280, but maybe creating a profile
and extension explicitly supporting single policy CAs.

As I have also written numerous times, such schemes offer a metadata
possibility that can make policies from unknown CAs easier to deal with.

I would be interested to get a list of disadvantages of single- policy CAs.
Particularly with respect to relying parties here constituting of end-users,
administrators and ISVs.

Anders