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

From: "Guida, Richard [JJCUS]" <[email-masked]>
Date: Wed, 11 Feb 2004 16:50:02 -0500

I took it as a given that of course cert path discovery and processing per
DPD/DPV/RFC3280 would first be done (or a relying party trust list would be
managed).  Then the simple "if" conditions would be tested by the relying
party software.  As for bizarre worlds, well, does that not describe
virtually everything we do in information technology?

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: Anders Rundgren [mailto:[email-masked]]
Sent: Wednesday, February 11, 2004 3:50 PM
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,
before you add this "simple code" (
http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertPathProgGuid
e.html
<http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertPathProgGui
de.html> ) you might want to check that your partners are ready for this as
well.  I would not be surprised if you rather end-up implementeting a
gateway to the bizarre world defined by "morons" like VeriSign, Peter G, and
yours truly :-)
 
Anders

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

Sorry, Anders, but I don't send screen scrapes to anyone.  And you should
not trust me if I did - they are too easily spoofed.  The answer to your
question is: it is not difficult at all to check OIDs under different roots
- a simple "if" conditions suffices.  If Root A and OID A.1, success; if
Root B and OID B.1, success, etc.  We do not yet have a business need to do
so with other CAs, but we see that need arising in the future and are
prepared to deal with it - and in a simple fashion.

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: Anders Rundgren [mailto:[email-masked]]
Sent: Wednesday, February 11, 2004 2:09 PM
To: Guida, Richard [JJCUS]; 'Santosh Chokhani'; [email-masked]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)

Agnosticism?
Not me!
 
But I seriously doubt that you in your current relying party software are
able to set different policy OIDs per trust anchor which is what your
proposal requires, becuase that would be pretty messy.  In case you really
can, please send me a screen-dump as proof so we finally get all the gory
details of the subject line :-)
 
Regarding non-critical policy extensions I really don't see the point of
having possibly entirely different policies and marking them (or at least
treating them) as non-critical, because that would trick relying party
software into potentially bad trust decisions.  If OTOH the policies are
more or less identical, why not reduce them to just one?
 
But to be frank, we are not at all talking about the same usage scenario
which is the reason TTP CAs stick to one scheme and you and a lot of other
PKIXer promote another scheme.
 
Anders

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

Anders - you have not answered the questions I posed.  What is the harm to
you, or anyone else, caused by OIDs in a certPolicies extension that is not
marked critical?  Or, a CA that issues more than one OID?  Separately, I do
not buy your premises.  If I build in the capability (in my relying party
software) to process OIDs, I can accept OIDs put in certs by some other
company's PKI; indeed I would be foolish to just build the capability to
accept my own OIDs (i.e., to hard code my own OIDs with no easy ability to
adjust later).  As for cross-certing, the ability to accept OIDs in some
other entity's certs does NOT require you to cross-cert (of course,
cross-certing with policyMapping may be beneficial, but I'll leave that for
another religious debate at some future time...).  So I again fail to see
the problem here.  You are arguing that some people should not do X; those
people think X is just fine and intend to/are pursuing it; yet you appear to
persist in trying to stop them from doing X when X does not appear to create
any harm to you or others.  I am perplexed by this.  But no need to answer,
I think we have reached the point of agnosticism.  Very best regards -- Rich

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: Anders Rundgren [ mailto:[email-masked]
<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. 

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: [email-masked]
Date: Thu, 12 Feb 2004 09:51:45 +0000

> So you really mean that there WILL be a LIMITED SET of
> UNIVERSALLY globally accepted policy OIDs that effectively
> replaces CP documents?  And COTS application will be
> pre-programmed accordingly?

Absolutely not.

(( BTW, is there any difference between a universal CP and
   Policy Certificates ? It would appear to me that they
   are one and the same. ))

> And there are MANY communities and businesses!

Agreed, and consumers have the power of choice to buy into a
policy that meets thier needs or to pay a provider to create
a policy for them that meets thier needs. Either that or
they build thier own CA and create thier own policies.

Chris

**********************************************************************
This email and any attachments are confidential and intended for the
addressee only. If you are not the named recipient, you must not use,
disclose, reproduce, copy or distribute the contents of this communication.
If you have received this in error, please contact the sender and then
delete this email from your system.
**********************************************************************