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 15:14:07 -0500

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: "Anders Rundgren" <[email-masked]>
Date: Wed, 11 Feb 2004 21:49:47 +0100

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/CertPathProgGuide.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, Richard [JJCUS] 
  To: 'Anders Rundgren' ; 'Santosh Chokhani' ; [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 

  Johnson & Johnson 
  Room GS8217 
  410 George Street 

    -----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, Richard [JJCUS] 
      To: 'Anders Rundgren' ; 'Santosh Chokhani' ; [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 

      Johnson & Johnson 
      Room GS8217 
      410 George Street 

      -----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, 

      Anders

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Feb 2004 16:59:20 -0500

At 21:49 +0100 2/11/04, Anders Rundgren wrote:
>Richard,
>before you add this "simple code" 
>(<http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertPathProgGuide.html>http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertPathProgGuide.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
>

Now Anders, despite what others may have said, there is no need to 
openly self-criticize in this way, especially to the extent implied 
by comparing yourself to VeriSign.  After all, when was the last time 
you personally issued a software signing cert to a bogus requester, 
or caused havoc by under provisioning CRL services, etc?

Steve