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

From: "David Cross" <[email-masked]>
Date: Tue, 27 Jan 2004 11:47:52 -0800

Anders et al:

Microsoft supports the capability to set a policy option during the
chain building process through the CertGetCertificateChain() API as a
parameter in the  CHAIN PARA structure.  Reference:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/securit
y/security/certgetcertificatechain.asp 

At this time, Internet Explorer, Outlook, IIS etc. do not support
configuration of this policy parameter...frankly due to the fact that
there is no end user demand for such a feature.  Arguably the demand
does not exist as nobody in my family could possibly understand what a
policy OID is and what it means to them. 

However, Windows Server 2003 IAS Server component (RADIUS/Remote Access
Server) does support admin configuration of allowed policy OIDs by the
administrator on the server.  In this particular case, it is an
interesting case with quite some utility as it allows an organization to
very discretely define which authentication certs would be allowed for
VPN, etc.  For example, certificates issued to smartcards incorporates
policy OID foo while authentication certs to software based key stores
incorporates policy OID bar, the remote access server may require that
only smartcard based certs may be used for access. 

David B. Cross 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Anders Rundgren
Sent: Tuesday, January 27, 2004 2:45 AM
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: "Anders Rundgren" <[email-masked]>
Date: Tue, 27 Jan 2004 21:59:55 +0100

Thanx David,

My request should in no way be interpreted as a criticism of the
lack of policy settings in IE, Outlook and IIS, because as you
say there is no user demand for such a feature which in turn
is due to the limited utility of policy identifiers.  Assuming that
you added such support to the Windows trust anchor installation
process, I believe you would run into a little problem: How is the
trust administrator supposed to know what policy OIDs the CA uses?

Therefore the policy system is really only usable in local PKIs like
in the W2K3 VPN scenario you described.

However, a TPP CA would most likely use different logical CAs
for smart card based keys and file based keys to not get sued by
customers that did not understand that they actually trusted
(and therefore accepted) a bit more stuff than they really opted for
(or their software was designed to handle)...

Anders Rundgren

----- Original Message ----- 
From: "David Cross" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 27, 2004 20:47
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook

Anders et al:

David B. Cross 

-----Original Message-----

Anders

---

From: Steve Hanna <[email-masked]>
Date: Tue, 27 Jan 2004 16:13:27 -0500

The Java 2 Platform supports setting policy parameters
with the java.security.cert.PKIXParameters class. For
more details, see

http://java.sun.com/j2se/1.4.2/docs/api/java/security/cert/PKIXParameters.html
http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertPathProgGuide.html#PKIXParameters

-Steve

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 28 Jan 2004 16:46:06 +0100 (CET)

In message <002601c3e518$848b66d0$0500a8c0@arport> on Tue, 27 Jan 2004 21:59:55 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> Assuming that you added such support to the Windows
anders.rundgren> trust anchor installation process, I believe you
anders.rundgren> would run into a little problem: How is the trust
anders.rundgren> administrator supposed to know what policy OIDs the
anders.rundgren> CA uses?

I'm sorry, I'm not sure I understand the question.  Did you mean any
other OID than what should be found in the CA certificate?

-----
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: "Anders Rundgren" <[email-masked]>
Date: Wed, 28 Jan 2004 17:12:51 +0100

>> Assuming that you added such support to the Windows
>> trust anchor installation process, I believe you
>> would run into a little problem: How is the trust
>> administrator supposed to know what policy OIDs the
>> CA uses?

>other OID than what should be found in the CA certificate?

There are no requirements to use policy OIDs at all, making the
trust admin process rather arbitrary.

Regarding those CAs who use policy OIDs, is there a MUST
to also specify these at CA-level to make path-validation work?

Anders

---

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

In message <03c801c3e5b9$94ece750$0500a8c0@arport> on Wed, 28 Jan 2004 17:12:51 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> >> Assuming that you added such support to the Windows
anders.rundgren> >> trust anchor installation process, I believe you
anders.rundgren> >> would run into a little problem: How is the trust
anders.rundgren> >> administrator supposed to know what policy OIDs the
anders.rundgren> >> CA uses?
anders.rundgren> 
anders.rundgren> >I'm sorry, I'm not sure I understand the question.
anders.rundgren> >Did you mean any other OID than what should be found
anders.rundgren> >in the CA certificate?
anders.rundgren> 
anders.rundgren> There are no requirements to use policy OIDs at all,
anders.rundgren> making the trust admin process rather arbitrary.
anders.rundgren> 
anders.rundgren> Regarding those CAs who use policy OIDs, is there a
anders.rundgren> MUST to also specify these at CA-level to make
anders.rundgren> path-validation work?

Hmm, it seems like there is no requirement for the trust anchor to
have any policy OID, at least if I read the path validation algorithm
in RFC3280 correctly (someone correct me if I'm wrong).

But either way, the answer to your question is the human interface.
If you want to have a trust relationship with anyone, it implicitely
requires that you talk with someone (you *do* verify fingerprints,
don't you?).  So when faced with a new CA, your administrator will
probably have to call the people at that CA and ask for information,
or visit some web site and find it there (provided it can be trusted),
or...

The thing that disturbs me in these kinds of discussions is the
apparent concept of having trust done automagically from the start (it
may work automagically after some initial work, but that's different).
I've a hard time believing that's possible (I'd be happy to be proven
wrong!), at least with current technologies.

-----