Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook

From: [email-masked]
Date: Tue, 27 Jan 2004 14:09:28 -0700

Another issue is that many of the traditional business trust models have
tended to be some sort of contract (exchange of value) between two parties;
supposedly the CA trust propogation relationship typically is between the
relying party and the CA ... while the contractual relationship is between
the public key owner and the CA (except for situations like
relying-party-only certificates .... where the same party is both
selling/issuing the certificates and also relying on the certificates) ....
aka the trust propogation relationship and the contractual trust
relationship are unrelated.

another solution has been to try and have some sort of governmental
legislative proclamation ... declaring/mandating a trust relationship ...
even if one doesn't exist from a business and/or contractual standpoint.

the gsa federal government PKI .... seems to be a variation on the
relying-party-only certificate .... the CAs appear to have a GSA contract
where they effectively are agents of the federal government (i.e. the CAs
are federal agents issuing/selling certificates on behalf of the federal
government). These certificates are then for use by the federal government
as the relying party (making them relying-party certificates).

now, the next issue is that the majority of the federal PKI programs appear
to be online operation ... which in turn would supposedly allow the
relying-party federal government ... to have online access to the original
of the information where the relying-party-only certificate represents a
stale, static copy of some such information stored in some databsse. Also,
possibly because of privacy issues, the stale, static (certificate) copy is
likely also a subset of the information that is actually stored in some
database (collected at the time the registration authority function was
performed involving the registration of the public key and information
about the owner of the public key). One possible issue is that the
operations being performed in conjunction with the federal PKI program
certificates are of such low value, that it doesn't justify having online,
timely access to the real information (even when it appears that all of the
applications in the program are otherwise online) ... aka long-time
assertion that relying-party, state, static, subset certificate information
tends to be redundant and superfluous given that there can be online access
to the original, timely information.

on 1/27/2004 12:27 pm anders.rundgren.com wrote:

May I help you with some analysis?

PKI projects historically started with the CA, and this has influenced some
PKI standards as well, the RFC3280 policy support is a prime example of
that.

However, being a CA, is being an "information producer" which is
considerably easier than being an "information consumer" as only the latter
has to "interpret" and maybe "act" upon what the information producer says.

If the designers of the policy system instead had focused on the relying
party (the "information consumer"), they had probably realized that a
relying party consists of 1) the relying party software 2) the people
depending on the relying party software.

Further analysis shows that the "people" category, except in the most
trivial scenarios, consists of  "trust administrators" and "end users".  In
the background there are also some legal folks lurking around.

If you then apply the design constraint that all these entities should have
the best possible system adapted for the entities' actual tasks and
competence, you would end-up with a very different policy scheme.

Commercial CAs know that, and therefore with few exceptions, continue to
ignore a system that was not designed with the "customer in mind".

The major difference is that policy in commercial CAs is associated with
the CA, eliminating the need for moving trust processing and trust
administration tasks into the application and user domains respectively.
This enables the creation of shrink-wrap RP software as well as shielding
end-users from too close encounters with PKI.

This also allows trust admins to anytime, using "CA properties", view what
"they actually currently trust", without having a single EE certificate!

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 28 Jan 2004 08:10:32 +0100

James,

Now you are talking!

In case nobody, in spite of Peter Gutmann's generous reward, takes on
the challenge describing how X.509 policies should be handled by
relying parties [1] based on RFC3280 "as is", I believe that the X.509
policy system should be given a deep second thought.

Best
Anders

1] Comprising of software, administrators, end-users, and lawyers.

----- Original Message ----- 
From: "James Jing" <[email-masked]>
To: <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>
Sent: Wednesday, January 28, 2004 03:58
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook

Maybe there are enough people out there who also think that PKI has
grown out of control, too hard for simple users to comprehend, even too
hard for knowledgeable implementers?

How can we return to simple and effective PKI?

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]] 
Sent: Tuesday, January 27, 2004 9:45 PM
To: [email-masked]
Subject: Setting X.509 Policy Data in IE, IIS, Outlook

It has been touted that policy OIDs are essntial for building PKIs.

However, I have not found any place where you can can set the policy
filtering in relying party apps like MSIE, IIS, or Outlook.

I would be interested to know when this feature will be available and
how the policy-OID-related processes are supposed to work from an
end-user perspective.

In case there are such application features available from other
vendors, I would be interested in how they have addresses this issue.

In particular, what you do after "installing" a trust anhcor does not
seem to be an not entirely straightforward matter unless you do a lot of
assumptions. 

Anders

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 29 Jan 2004 05:00:16 +1300

"Santosh Chokhani" <[email-masked]> writes:

>It is part of ISO/IEC JTC 1/SC 06 N12345 dated Nov. 14, 2002 working draft.
>David Cooper and Laura Boyer may be in better position to state the exact
>status.

Ahh, OK.  I sorta stopped following the drafts about a year after it was
supposed to have been finished (that's also why I wasn't quite sure whether
the drafts you referred to are still v4 drafts or the start of the v5 drafts).
The ITU web site doesn't help much either, with the main version (before the
flood of corrigenda also on the site) being dated 2000 but posted 2001, so the
official date for the final standard predates the working drafts I've got.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 29 Jan 2004 05:00:16 +1300

Peter.