Subject: RE: Certificate policy question

From: [email-masked] (Peter Gutmann)
Date: Thu, 12 Dec 2002 14:56:35 +1300

"Fillingham,  David W." <[email-masked]> writes:

>I don't believe that there is anything in any of the applicable standards
>that would suggest a certificate can only comply with a single policy, or
>only assert one policy.

I can't really see the point of having a policy extension (in an EE cert) if
you can have more than one, and they conflict.  It's like having a posted
speed limit of 60 and 70 and 100 kph in the same location, you may as well not
post anything because no-one knows what they need to comply with.  In other
words, having > 1 (incompatible) policy in an EE cert is of no value to
relying parties because they don't know what to rely on.

Actually that probably provides the answer to the question: > 1 policy in an
EE cert, where one policy isn't a subset/refinement/compatible version of the
other [0], demonstrates that the issuer is sufficiently confused over policy
issues that the cert should be regarded as following no policy at all :-).

>I hope that application developers will adhere closely to what X.509 and RFC
>3280 have to say about certificate policy processing.

s/hope/wish/
s/will/would/
d/about certificate policy processing/

Peter.

[0] Figuring out how to check for this is left as an exercise for the reader.

---

From: "Peter Hesse" <[email-masked]>
Date: Wed, 11 Dec 2002 23:36:11 -0500

> I can't really see the point of having a policy extension (in an 
> EE cert) if you can have more than one, and they conflict.  It's 
> like having a posted speed limit of 60 and 70 and 100 kph in the 
> same location, you may as well not post anything because no-one 
> knows what they need to comply with.  In other words, having > 1 
> (incompatible) policy in an EE cert is of no value to relying 
> parties because they don't know what to rely on.

I am confused as to how an application is expected to determine whether
or not one policy is incompatible with another.  Incompatibility would
only be determinable if the application had access to the CP (and
possibly the CPS) and performing a thorough audit of their similarities
and differences.  Of course this is not what should happen.  The
policies should be processed in accordance with X.509 or RFC 3280; to
try and make some guesses about policies being incompatible or mutually
exclusive would be counterproductive.

I could foresee a situation in which multiple policies could be used
within the same end-entity certificate.  The policies could specify
subsets of what is commonly viewed as one policy.  One policy OID would
mean a hardware device was used to protect the private key, another
policy OID specifies that in-person proofing is performed, and a third
policy OID specifies the certificate and CRL profile (etc).  (Of course,
this concept would lead to policies not entirely in conformance with RFC
2527...)  This might also be true not with individual policy components,
but policies that were not mutually exclusive, such as this example:
policy A is valid for protecting data which is internal to Organization
A, policy B is valid for protecting data sent external to Organization
A.  

I think of multiple policy OIDs not so much as speed limit signs
designating different speeds to travel, but rather like menus at a
restaurant.  The foods you like might not all appear on one menu - you
might have to visit more than one restaurant.  (OK not the best analogy
but it's late!)

--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: Richard Levitte - VMS Whacker <[email-masked]>
Date: Thu, 12 Dec 2002 12:13:48 +0100 (CET)

In message <[email-masked]> on Thu, 12 Dec 2002 14:56:35 +1300, [email-masked] (Peter Gutmann) said:

pgut001> Actually that probably provides the answer to the question: >
pgut001> 1 policy in an EE cert, where one policy isn't a
pgut001> subset/refinement/compatible version of the other [0],
pgut001> demonstrates that the issuer is sufficiently confused over
pgut001> policy issues that the cert should be regarded as following
pgut001> no policy at all :-).

So, out of curiosity, would you regard that cerificate as valid or
invalid (I hope to code better validation into OpenSSL, and handling
of policies is certainly a large part, so I'm interested as well :-))?
I'd opt for invalid unless someone can tell me I should regard as
valid and why.  I'd even go one step further and regard an EE
certificate with more than policy as suspicious, at least.

pgut001> [0] Figuring out how to check for this is left as an
pgut001> exercise for the reader.

:-)

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 12 Dec 2002 10:32:44 -0500

Peter, Peter, Dave and Sharon:

Good discussion.  I am confused by [0].  What is that for.

I would like to add to what you all have said.

1.  As Sharon pointed out, the certificatePolicies should only contain
one CPS pointer (if any) in the policyQualifiers field since a CA
operates with a single CPS.

2.  Generally, we recommend putting multiple policy OID in the CA
certificates (as Dave has pointed out) so that the CA can issue
certificates for the various policies to subordinate CAs or end
entities.  This is required for path validation.  The other alternative
will be to issue the CA multiple certificates (one for each policy)

3.  I recommend putting multiple policies in the end entity certificate
if the policies are hierarchically organized.  In that case, the higher
water mark and all policies with lower assurance should be asserted in
the end entity certificate.  Please not that when the policies are
hierarchically organized, there is no issue of conflict.  That addresses
Peter's concern.  The reason for asserting multiple policy is again path
validation.  The application that finds lower assurance policy
acceptable should not reject the higher assurance certificate.  The
alternative will be for the application to include in its acceptable
policy set the lower assurance policy and all the policies above it from
the application (meaning relying party) domain.  The reason I recommend
infrastructure and application both to do this is to me it is akin to
defensive programming (I call it defensive system engineering).  This
way, if either the infrastructure or the application did its job, valid
certificates will not be rejected.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Hesse
Sent: Wednesday, December 11, 2002 11:36 PM
To: 'Peter Gutmann'; [email-masked]; [email-masked]
Subject: RE: Certificate policy question

--Peter

---

From: Steve Hanna <[email-masked]>
Date: Thu, 12 Dec 2002 11:16:35 -0500

I will add my voice to the growing crowd emphasizing that
there are many good reasons to have multiple certificate
policies in a single certificate (EE or CA). Sharon gave
several good examples.

Asserting "conflicting" policies is bad, but there's no
way for software to determine whether two policies conflict.
It would need to download the CP and/or CPS and interpret
the language there to decide whether the policies conflict.
Heck, most humans can't do that!

The best thing is for relying party software to follow
the algorithm in RFC 3280 and X.509. Doing otherwise will
cause interoperability problems.

Thanks,

Steve Hanna

---

From: "Ambarish Malpani" <[email-masked]>
Date: Thu, 12 Dec 2002 09:42:32 -0800

Richard,
    You might want to regard the certificate as being compatible
with *both* the policies specified. If either of the policies
is acceptable for your needs (and you can create a valid path),
feel free to accept the certificate. That is the best you can
do as certificate processing software.

If the CA should not have issued a cert with both policies (because
they a incompatible, etc.), that is a problem you should let the CA
deal with.

My 2c.
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [email-masked]
http://www.malpani.biz

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Richard Levitte - VMS
> Whacker
> Sent: Thursday, December 12, 2002 3:14 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Certificate policy question
> 
> 
> 
> In message <[email-masked]> 
> on Thu, 12 Dec 2002 14:56:35 +1300, [email-masked] 
> (Peter Gutmann) said:
>

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Thu, 12 Dec 2002 20:16:56 +0100 (CET)

In message <[email-masked]> on Thu, 12 Dec 2002 09:42:32 -0800, "Ambarish Malpani" <[email-masked]> said:

ambarish>     You might want to regard the certificate as being compatible
ambarish> with *both* the policies specified. If either of the policies
ambarish> is acceptable for your needs (and you can create a valid path),
ambarish> feel free to accept the certificate. That is the best you can
ambarish> do as certificate processing software.
ambarish> 
ambarish> If the CA should not have issued a cert with both policies (because
ambarish> they a incompatible, etc.), that is a problem you should let the CA
ambarish> deal with.

As I understand Peter, the two policies weren't compatible.  So OK,
the way to deal with it would then be to speak with the CA in
question, and then set them up in my own software as untrusted, at
least until they've dealt with the situation and reissued the
offending certificate.

After all, this is about trust, and I can't see how I can trust
anything from a CA that the kind of certificate I believe Peter is
talking about.

Harsch?  Tough!

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Thu, 12 Dec 2002 20:35:37 +0100 (CET)

In message <[email-masked]> on Thu, 12 Dec 2002 11:16:35 -0500, Steve Hanna <[email-masked]> said:

steve.hanna> I will add my voice to the growing crowd emphasizing that
steve.hanna> there are many good reasons to have multiple certificate
steve.hanna> policies in a single certificate (EE or CA). Sharon gave
steve.hanna> several good examples.

I know I suggested some programatic assertions, and some of them
weren't the wisest, I'll admit that.  Of course I'll follow the
RFC 3280 algorithm.

I believe that when I get started on the code I plan, I will add the
option to have warnings issued when multi-policy EE certs appear, so
the right person gets some kind of notification about that being
something to look into.  Then is the question if that option should be
enabled by default or not.  Additionally, it could be a good thing to
have the possibility to distrust certain CAs (no, I don't believe a
CRL entry is the right thing, or is there a reason code that means
"the CA made a fool of itself"?  Either way, that would also only be
possible in a mesh-type PKI, I think).
I believe such extra options is still perfectly compatible with the
RFC 3280 algorithm.  All it does is give the user of my code a level
of control over trust that can't really be handled with CRLs or other
standard means that I can recall right now.

---

From: "Christopher S. Francis" <[email-masked]>
Date: Thu, 12 Dec 2002 14:31:09 -0500

I completely agree with Ambarish's interpretation.  

Chris
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ambarish Malpani
Sent: Thursday, December 12, 2002 12:43 PM
To: Richard Levitte - VMS Whacker; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Certificate policy question

Richard,

My 2c.
Regards,
Ambarish

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 12 Dec 2002 16:57:20 -0500

Richard:

If the CA is asserting conflicting policies, do you trust it to operate
properly in other areas?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Richard Levitte - VMS Whacker
Sent: Thursday, December 12, 2002 2:17 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Certificate policy question

In message <[email-masked]> on Thu,
12 Dec 2002 09:42:32 -0800, "Ambarish Malpani" <[email-masked]>
said:

ambarish>     You might want to regard the certificate as being 
ambarish> compatible with *both* the policies specified. If either of 
ambarish> the policies is acceptable for your needs (and you can create 
ambarish> a valid path), feel free to accept the certificate. That is 
ambarish> the best you can do as certificate processing software.
ambarish> 
ambarish> If the CA should not have issued a cert with both policies 
ambarish> (because they a incompatible, etc.), that is a problem you 
ambarish> should let the CA deal with.

As I understand Peter, the two policies weren't compatible.  So OK, the
way to deal with it would then be to speak with the CA in question, and
then set them up in my own software as untrusted, at least until they've
dealt with the situation and reissued the offending certificate.

After all, this is about trust, and I can't see how I can trust anything
from a CA that the kind of certificate I believe Peter is talking about.

Harsch?  Tough!

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Thu, 12 Dec 2002 23:02:25 +0100 (CET)

In message <008c01c2a229$72ac5290$05825b0c@Chokhani> on Thu, 12 Dec 2002 16:57:20 -0500, "Santosh Chokhani" <[email-masked]> said:

chokhani> If the CA is asserting conflicting policies, do you trust it
chokhani> to operate properly in other areas?

Probably not.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 13 Dec 2002 13:31:35 +0100

Peter Gutmann wrote:
> you can have more than one, and they conflict.

I strongly agree with that.

Ciao, Michael.