Subject: RE: End-Entity Certificate Policies

From: Russ Housley <[email-masked]>
Date: Thu, 09 Sep 1999 14:00:22 -0400

I want to send a quick message to summarize the impact that this thread has 
had on my thinking.  This thoughts have not been coordinated with the other 
RFC 2459 authors.

First, I have been convinced that there are times when it is appropriate to 
include more than one certificate policy OID in an end 
entity-certificate.  However, it is clear to me that some policies should 
not be combined in one certificate.  I guess that there are many errors 
that a CA could make, and that this is just one more.  Can anyone suggest a 
subjective rule for the types of policies that might appear in one 
end-entity certificate?  If not, how about a subjective rule for the types 
of policies that should not appear in one end-entity certificate?

Second, I remain concerned about the use of qualifier with certificate 
policies in CA certificates.

The certificate policy qualifiers do not impact the certificate path 
validation algorithm.  Rather, the certificate policy qualifiers are 
provided as an output of the algorithm to the certificate user (a.k.a. 
relying party) to help determine whether or not the end-entity certificate 
is appropriate for the task at hand.

While the X.509 path validation algorithm does not prohibit an 
implementation from returning information that tells which certificate 
provided particular qualifiers, the algorithm does not require that this 
information be provided.  Therefore, we must assume that this information 
is not available to the certificate user.

I still think that it is important that the set of certificate policy 
qualifiers not include contradictions.

I belive that it is possible that two CAs can support the same certificate 
policy using different CPSs.  Thus, certificates issued by the two CAs 
would have the same certificate policy OID, but they would include 
different values for the CPS pointer qualifier.  If a path includes 
certificates from both of these CAs, the output of the certificate path 
validation algorithm would include the common certificate policy OID and 
two different CPS pointer qualifiers.

Since the certificate validation algorithm does not use certificate policy 
qualifiers, how do certificate policy qualifiers in CA certificates help 
the certificate user?

Russ

---

From: [email-masked]
Date: Fri, 10 Sep 1999 16:42:24 +0200 (CEST)

Few thoughts about this subject...
 
> of policies that should not appear in one end-entity certificate?

I think you can include every type of certificate policies, as long as
they are not in contradiction. A comparison of policies or verification that
they are not in contradiction is not an easy task, but must be done by a CA.
Even one policy can have contradicting rules, and must be carefully checked.

> two different CPS pointer qualifiers.
 
Qualifiers do not change the meaning of the policies, so I don't see the 
problem if you have a single policy and two CPSs that support this policy. 
CPSs can't be in contradiction if they support the same policy, that specifies
the rules and is the basis for evaluation of certificates. 

I find qualifiers useful to provide exact information about certain policy 
elements. CAs or other policy authorities specify (in advance) in the policy 
minimum requirements or conditions that must be met, for example minimal key 
storage quality or minimal identity verification procedures. These requirements 
do not change over time. However, with qualifiers you can include exact values 
of some elements at the time the certificate is issued, which can provide more 
information to end users for an evaluation of certificates or comparison with 
their personal security policy. Am I wrong?

Regards, Tomaz

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 10 Sep 1999 11:55:21 -0700

> qualifiers, how do certificate policy qualifiers in CA certificates help

Every so often, I receive in my S/MIME client a msg originated
by someone belonging to a certification domain that
I neither know, or trust. In general, they are RFC 2459 complying
CAs, doing what RFC 2459 seeks.

The fact that I receive these  is probably based on the fact that
I co-authored an applied digital certificates book,
suggesting people go out and deploy RFC 2459 and SET
CAs (horror!): It  helped provide lots or practical know-how
enabling cheap experimental deployment using mass-market software. People
sometimes send me their results, proudly. (I rarely,
if ever, see their names on this list.)

Anyway, my S/MIME tool (which uses a well-known mass market
certificate manager tool and crypto library) enables me to
label the inbound certificates as trusted. I can learn a
root, if you like. Some of the CA certs are self-signed, some
are intermediate  CAs in a chain that does not happen to
include the TLCA for  their domains.

To decide to trust it, I inspect the certificate.  I,
and my "auditor" make an accreditation judgment on
its trustworthiness, much like CAs confirm the identify
and obligations of CAs during PKIX3-specified
cross-certification.

Acting much as a professional security administrator in any
large enterprise, I am as capable of taking this
accreditation decision as any commercial CA might do on
my behalf.

To finalize the decision, I sign a list of my
trusted roots which controls their use in my S/MIME client.
The signed trust list acts, effectively, as my personal CA
which controls inter-domain trust; conforming path
processing ensures both trusted interworking and
policy recognition during  S/MIME msg handling, when
I choose to use conforming rules. As per 2459, I
can turn off conforming rule processing, when
required.

What use are the qualifier? Russ asks.

During inspection, the CPS pointer identifies to
me the PEM-style policy elements which I used to evaluate
the trustworthiness of the domain, as recommended by
the designers of RFC 1422, whose basic ideas are incorporated
into RFC 2459 by charter directive.

In some cases, the certificate identifies
one or more certificate policies.  In other
cases it identifies one or more combined certificate policy
and CPSs. I have to wade through the various declarations to make my
decision deciding whether or not
to extend trust, given goals of my own security program.
The know-how to do this is about as complex as designing
for NR. I use the PKIX-IV recommendations to do this,
as one would expect.

I understand from friends in companies who
use other mass-market software, and who use the
other RFC 2459 qualifier which points to
Warwick Ford's (WG-ratified) scheme for locating
policy description fragments embedded in compound
documents, that they use that facility for purposes
similar to those that I described for the CA-cert
hosted URL.

So, if nothing else, CA qualifiers are very valuable
in the actual Internet PKI for learning trust-points,
and taking accreditation decisions based on evaluation
and recognition of policy. The use of explicit
accreditation is a well-established technique,
advised by reputable organizations such as NIST.

It is true that I never use certificate path processing
during this inspection and accreditation process; but then
path processing was not designed for, and is not
useful for, such an accreditation process. I would never
use mandatory access control lattice implementation when
accrediting a certified B2 OS product for use in my site,
either!

Hope this helps; its reality, and it works using at least
two different mass-market software implementations that work
largely according to the design and specification of RFC2459.
The scheme is voluntary and optional. Only those
interworking parties that recognize the (qualified) policy
are affected. Those that do not recognize the a (qualified)
policy, are  unaffected, if they use conforming implementations.

Therefore policy controls interworking by instrumenting
the accreditation, which is aided by the qualifiers, just as
one would expect. Much of the experience of NIST (and NSA)
is now implemented in the Internet PKI environment, supporting,
as is culturally required: autonomous operations, experimentation,
and multi-vendor implementations that interwork at least
a minimal level, and by default.

"I find qualifiers useful to provide exact information about certain policy
elements." [another]

Peter.

---

From: Russ Housley <[email-masked]>
Date: Thu, 16 Sep 1999 15:57:48 -0400

Peter:

Thanks for the tutorial on the process you use to determine whether or not 
to trust a particular "new root."  Your use of qualifiers that has nothing 
to do with certificate path validation.  So, would it be fair to say they 
you believe that qualifiers in CA certificates are useful for determing 
whether or not to trust that CA, but that they have no impact on 
certificate path processing?

Russ

---

From: "Peter Williams" <[email-masked]>
Date: Thu, 16 Sep 1999 14:52:12 -0700

Russ,

The following msg is long; it should take about 5 minutes
to read. It mainly recapitulates into a more organized fashion
what has been previously stated. The cogency of the argument
is now available for acceptance or denial. Accept
it or deny it, I'm always excited to help form
and then follow the adjudged consensus.

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, September 16, 1999 12:58 PM
> To: Peter Williams
> Cc: [email-masked]
> Subject: RE: End-Entity Certificate Policies
>
>
> Peter:
>
> to trust a particular "new root."

The "tutorial" was merely the policy inspection process advised
by RFC 1422 for Internet user subscribers, and promoted today as
good consumer practice in the e-commerce PKI world. It featured as
its technical mechanism nothing but RFC 2459 standardized
elements, used as intended.

These mechanisms included using policy qualifiers as intended
by ISO and by PKIX: I merely reinforced (IMESHO) what the designers
intended, what the interested parties understood when
making the agreements to them, and upon whose agreement
millions of dollars of investment were made to implement
those standards.

My own understanding of all this, as a mere peon, is based
on having read the public disclosures and arguments on the
topics, which were voluminous. It is also based on my having
probably been the cause of the use of the qualifier
in this manner, being the person who architected
the first generation of VeriSign certificates which
featured this usage as an specific innovation. I think
these facts legitimatize my opinion. But perhaps not.

I would be highly influenced in take another position if
any of the original proponents would chime up, with
non-vacuous rationale, to repudiate their earlier
support and deployment choices : Microsoft, Netscape,
VeriSign?

Now, I pointed out that the debate on the appropriateness
of the policy qualifier techniques described has already
happened, and was agreed to by the RFC 2459 WG, and
IESG.  Apparently, from your own admission, you
voiced concerns about the very concept at the time, and
the backdoor consensus in the author group was to over-ride
your concerns  - presumably in light of other factors.

I also suggested that in fixing a bug, as a principle,
we should not indirectly or incidentally deprecate a
working, fielded and valued mechanism; nor should we in
any way disparage its value or utility. As policy rules
are intended to be a operational matter in PKIX, we should be
encouraging diversity and experimentation in PKI-based rule
systems, whilst also encouraging technical
compliance with mechanical processing algorithms.
However, fixing a bug in said algorithm should
not lose us the goal...

To conclude my recapitulation, you asked if anyone but
Michael Baum objected, and I answered yes.  The thread
shows that Michael Myers also objects. Another source
articulated the core value, without prompting.

 Your use of qualifiers that
> has nothing

Certificate path processing is but one activity performed by
a recipient. But to answer your question as posed: yes I believe
qualifiers have no impact on ISO cert path processing; and their rules
should not specify a change to that process.  ISO path
processing is a process of matching or selecting RP and CA policy id
requirements, only. Its a fancy policy id matching rule, not
a technique for security enforcement. This opinion is
based on private conversations with those who wrote it,
and edited the standard.

As we know from the standard, a set of outputs of the ISO
path processing algoirhtm are generated, to be used by the
recipient in taking a security decision. Path validity checking
using the ISO algorithm is not sufficient to use the certificate
in a manner conforming with the policies *rules*; it merely handles the
matching of policy choices. Other signals are combined with
those outputs to make a policy-based decision. As we known,
these signals may invalidate the use of the certificate, even
though the ISO processing algorithm is happy. EKU, and Key
Usage are cases in question. Other non-critical private
extension may also control; that whats the Internet PKI
is all about.

Peter.