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

From: "David Cross" <[email-masked]>
Date: Thu, 29 Jan 2004 10:30:36 -0800

Your 2 cents may not be too far off the mark...however, some comments...

A.  Today, in a Windows XP+ and Windows Server 2003 environment, we do
have the capability to configure an Active Directory (domain)
environment as you describe.  I agree this is an example of the
direction you describe.

B.  Technically, this also exists in most chaining engines and UI,
although the policy information is not exposed as a first class citizen,
argueably for several reasons such as my grandmother just is not
interested in policy status of my signed mail to her, but I digress...

Items C. and D. are the slippery slope that have obvious utility in the
enterprise and/or high assurance environments, but not in the general
global consumer community.  My grandmother just won't understand the
meaning of "initial-policy-mapping-inhibit" no matter how much she loves
me.

David B. Cross 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Hesse
Sent: Thursday, January 29, 2004 7:05 AM
To: 'Anders Rundgren'; 'Steve Hanna'; 'Stephen Kent'
Cc: [email-masked]
Subject: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)

I'll take the bait and throw this idea out there for you all to think
about.
It's not entirely my idea, it is based on ideas discussed with Dave
Fillingham over the years.  Let's assume for the moment that you're
working with a PKI with a few different certificate policies in use;
they might be hardware/software stored keys, or high/medium/low
assurance.

It is my suggestion that for a majority of PKI-enabled products with
user interfaces, the best solution may be to do the following:

A) Provide an administrative interface to map certificate policy OIDs to
human readable names, and potentially human readable descriptions of the
policies as well.

B) When building/validating certification paths, set the
initial-policy-set to any policy.  When a path successfully validates,
display the signature and validation status to the user, along with the
human readable names for the policies in the
authority-constrained-policy-set, or an indication that the path was not
valid under any known policies.

If these steps are followed, the user can just be informed that the
message they received was valid for "Gemini medium assurance" or
something like that.  Not much difficulty to implement, nor would it be
too difficult to educate the users.

Now, assume we're dealing with a PKI larger than a single organization,
where there are differing certificate policies and appropriate
certificate policy mappings in place.  (Such as a Bridge CA
environment.)  I'm assuming in this case that all certificates that I
want my relying parties to accept would have certificate policies
asserted.  In this case, we add just two more steps:

C) When validating paths, set initial-explicit-policy to TRUE, to ensure
that only paths valid for a policy would be accepted.  (Or, set
requireExplicitPolicy through policyConstraints extensions in domain or
cross-certificates.)

D) Provide users with a switch to enable/disable
initial-policy-mapping-inhibit.  This may be referred to as "allow only
my organization" and "allow other organizations".  I'm presuming that
cross-certificates would fail to validate if require-explicit was true
and policy mappings don't take place.

Likewise, even if I received a message from a user from a different
organization, I would simply see that the message validated and that it
was valid under the "Gemini low assurance policy" or something similar.
This doesn't add much implementation difficulty (assuming a compliant
path processing system) or make it too confusing for the user.

Just my $0.02.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been a statue
set up in honor of a critic." --Jean Sibelius

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 30 Jan 2004 10:36:53 +0100

Peter,

If a sender of a signed message is using a certificate from a PKI that
requires policy filtering by the relying party (be it a server or Outlook),
then the sender creates a potential security hazard as the relying party
after trust anchor installation is likely to also "trust" what effectively
could be completely other types of certificates. 

One culprit is that there is no good universal way to communicate
CA policy information, except by requiring relying parties to decipher
CP documents, making the configuration process less user-friendly.

That is, multiple policy PKIs are not unsuitable only for consumers
like David's grandma, but in most open environments where many
relying parties are involved.

Regarding the user interface, you forgot to mention that the policy
settings must be per CA or groups of CAs further complicating matters.
But maybe, we are really talking local PKIs here?

Anders

----- Original Message ----- 
From: "David Cross" <[email-masked]>
To: "Peter Hesse" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 29, 2004 19:30
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)

David B. Cross 

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

Just my $0.02.

--Peter

---

From: "Peter Hesse" <[email-masked]>
Date: Fri, 30 Jan 2004 10:15:08 -0500

Anders,

When policy mappings are appropriately applied by the infrastructure,
relying parties need only to know about their own domain policies.  If I'm a
user at "XYZ corp", I will know that there are three XYZ policies; "XYZ
low", "XYZ medium", and "XYZ high".  Even if the signer is someone from
"Acme corp" with an "Acme External" certificate policy, the policy mappings
should cause me to see it at "XYZ low"; I don't need to look at Acme's
certificate policy document, my infrastructure has already done that and
made their decision on how "Acme External" should be mapped to an XYZ
policy.

I do not understand what you think is a potential security hazard.  The
relying party's infrastructure is responsible for what the relying party
trusts or does not trust.  The relying party's infrastructure uses technical
controls to control that trust, and the technical controls are in the
certificates issued by the relying party's trust root.  These controls
include the certificate policies, policy mappings, policy constraints, basic
constraints and name constraints extensions.

Will this be useful to David's grandmother?  No, of course not.  David's
grandmother has no need for this level of detail or assurance.  (Not to
mention she's probably using a $20 "your credit card number is good enough
identity proofing for us" certificate.)  A mutual fund manager who is
responsible for $500 million in assets, or a battlefield commander
responsible for the lives of thousands of soldiers probably *will* need this
level of detail and assurance.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anders Rundgren
Sent: Friday, January 30, 2004 4:37 AM
To: David Cross; Peter Hesse
Cc: [email-masked]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)

Peter,

One culprit is that there is no good universal way to communicate CA policy
information, except by requiring relying parties to decipher CP documents,
making the configuration process less user-friendly.

That is, multiple policy PKIs are not unsuitable only for consumers like
David's grandma, but in most open environments where many relying parties
are involved.

Regarding the user interface, you forgot to mention that the policy settings
must be per CA or groups of CAs further complicating matters.
But maybe, we are really talking local PKIs here?

Anders

----- Original Message -----
From: "David Cross" <[email-masked]>
To: "Peter Hesse" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 29, 2004 19:30
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)

David B. Cross 

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

Just my $0.02.

--Peter

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 30 Jan 2004 18:12:00 +0100

Peter,
You are talking about the relying party in end-user terms.
I am rather talking about the rp software and the rp security admin,
i.e. the entities managing the infrastructure you are talking about. 

This part gets more critical if you are a medium-sized manufacturer and
have 10000 suppliers of different sizes.  That's the kind of scenarious
I base my judgement on and also write software for.

Anders

----- Original Message ----- 
From: "Peter Hesse" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>; "'David Cross'" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 30, 2004 16:15
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)

Anders,

--Peter

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

Peter,

Anders

----- Original Message -----
From: "David Cross" <[email-masked]>
To: "Peter Hesse" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 29, 2004 19:30
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)

David B. Cross 

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

Just my $0.02.

--Peter