Subject: Re: [pkix] Best practices for Certificate Policy OIDs in certificates

From: David CARELLA <[email-masked]>
Date: Wed, 01 Jun 2011 16:00:07 +0200

Nobody to answer my questions?
Links or documents are welcome.

Are my questions not clear? or too long?

Regards,
David

On 05/30/2011 05:56 PM, David CARELLA wrote:
> Hi all,
> 
> After reading RFC 5280, § 4.2.1.4 Certificate Policies, I have several 
> questions about the best practices on certificate policies:
> - certificate policies writing (number of documents),
> - setting the certificate policy OIDs (and qualifiers) in CA and end 
> entities certificates.
> 
> I suppose that I have:
> - entities and theirs certificates:
>     - Root CA,
>     - Sub CA 1 (Intermediate CA), issued by Root CA,
>     - Sub CA 2 (End CA), issued by Sub CA 1,
>     - End entities (EE), issued by Sub CA 2;
> - certificate policies:
>     - Root CA certificate policy (describe Root CA and Sub CA 1): OID-0,
>     - Sub CA 1 certificate policy (describe Sub CA 1 and Sub CA 2): OID-1,
>     - Sub CA 2 certificate policy (describe Sub CA 2 and End entities): 
> OID-2.
> 
> 
> Which is the best practice, for certificate policies writing?
> 1. One certificate policy (CP) by CA (cf. above),
>    i.e.:
>    - one CP for Root CA,
>    - one CP for each level 1 Sub CA,
>    - and one CP for each level 2 Sub CA,
> 2. One certificate policy for Root CA and level 1 Sub CA,
>    and one certificate policy for each level 2 Sub CA (as End CA),
> 3. Other case?
> 
> 
> Which is the best technical practice, among the following examples, or 
> other cases?
> 
> --- Example 1
> According to RFC 5280, and strictly respected.
> 
> Root CA: Certificate policy:
> - policyIdentifier: anyPolicy [2.5.29.32.0]
> - policyQualifiers: - cPSuri: URI
> 
> Sub CA 1: Certificate policy:
> - policyIdentifier: anyPolicy [2.5.29.32.0]
> - policyQualifiers: - cPSuri: URI
> 
> Sub CA 2: Certificate policy:
> - policyIdentifier: anyPolicy [2.5.29.32.0]
> - policyQualifiers: - cPSuri: URI
> 
> End entity: Certificate policy:
> - policyIdentifier: OID (OID-2)
> 
> --> E.g. URI = http://pki.project.org/cps/
> 
> 
> --- Example 2
> According to RFC 5280, and according to what I saw in Firefox 
> ("conformed" built-in CAs).
> 
> Root CA: Certificate policy:
> - policyIdentifier: anyPolicy [2.5.29.32.0]
> - policyQualifiers: - cPSuri: URI
> 
> Sub CA 1: Certificate policy:
> - policyIdentifier: anyPolicy [2.5.29.32.0]
> - policyQualifiers: - cPSuri: URI
> 
> Sub CA 2: Certificate policy:
> - policyIdentifier: OID (OID-2)
> - policyQualifiers: - cPSuri: URI
> 
> End entity: Certificate policy:
> - policyIdentifier: OID (OID-2)
> - policyQualifiers:
>     - cPSuri: URI
>     - userNotice: - explicitText: text (if need)
> 
> --> E.g. URI = http://pki.project.org/cps/
> 
> 
> --- Example 3
> Sometimes, I saw the following case (for the Sub CA 2, from my example 
> 2), but it isn't conformed to the recommendations described in RFC 5280, 
> because there are two OIDs, and cPSuri isn't needful for OID!=anyPolicy.
> Is it still a good practice?
> 
> Sub CA 2:
> Certificate policy:
> - policyIdentifier: OID (OID-2)
> - policyQualifiers: - cPSuri: URI
> Certificate policy:
> - policyIdentifier: anyPolicy [2.5.29.32.0]
> 
> --> E.g. URI = http://pki.project.org/cps/
> 
> 
> Best regards,
> David CARELLA
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Russ Housley <[email-masked]>
Date: Wed, 1 Jun 2011 10:11:54 -0400

Policy qualifiers are ugly.  Please do not use them.

Why not define a single policy that states the roles of the Root CA, Sub CA 1, and Sub CA 2, and then use the same OID throughout.  That avoids the need for any mappings and other complexity.

Russ

On Jun 1, 2011, at 10:00 AM, David CARELLA wrote:

>> After reading RFC 5280, § 4.2.1.4 Certificate Policies, I have several questions about the best practices on certificate policies:
>> - setting the certificate policy OIDs (and qualifiers) in CA and end entities certificates.
>> I suppose that I have:
>>    - Sub CA 2 certificate policy (describe Sub CA 2 and End entities): OID-2.
>> Which is the best technical practice, among the following examples, or other cases?
>> --- Example 1
>> According to RFC 5280, and according to what I saw in Firefox ("conformed" built-in CAs).
>> Sometimes, I saw the following case (for the Sub CA 2, from my example 2), but it isn't conformed to the recommendations described in RFC 5280, because there are two OIDs, and cPSuri isn't needful for OID!=anyPolicy.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 02 Jun 2011 15:54:17 +1200

>Nobody to answer my questions?

I think the reason no-one's replied is because the answer is "that's a policy
matter".  So you need to formulate a policy as to which policy you want to
follow.

Peter.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 02 Jun 2011 09:32:04 +0200

On 06/02/2011 05:54 AM, Peter Gutmann wrote:
> David CARELLA<[email-masked]>  writes:
>
no, I missed the message:

there is no such thing as a different policy identifier "for" a CA certificate.
policy identifier in an (intermediate) CA certificat are a filter set by
the superior CA to indicate the list of EE certficate policies that
are recognized as compatible which the superCA environment.

putting "anypolicy" somewhere indicates essentially that you accept
everything.

as in this example, the anypolicy permits that OUI-2 works,
but only if your initial policy set contains well, left as
an exercise.

      (c)  user-initial-policy-set:  A set of certificate policy
            identifiers naming the policies that are acceptable to the
            certificate user.  The user-initial-policy-set contains the
            special value any-policy if the user is not concerned about
            certificate policy.

the reason for trying to have an OID for a CA is a
very common misunderstanding in several policy documents
which confused the OIDs that one puts into certificates which
an identification of a document (seen as "Identification: oid"
in te beginning of a policy statement, or as other OIDs describing
documents with practices.

In particular, the French "PC type"s is wrong:

it says that you write in a policy statement

"Le numéro d’OID du présent document est xxxx"
"the OID number of the present document is xxxx"

which is not wrong by itself, but then it specifies that it
this number that you put into a certificate that you issue.
as a consequence, when people write
"policy statement documents" for CAs which is not an
unreasonable thing, it is a diffrent document,
it has some OID, and well, one wants to put it into
CA certificates ... into a place which is not designed for that.

in such a CA "policy document", one has to write something like
"this CA recognises the following policies (list of OID)"
these OIDs are those that are put into EE certs of
recognized CAs.

to resume the confusion:

a "policy oid" and an OID used to classify a "(policy) document"
are different things and unrelated.

Peter
PS:
2 David: greetings to William

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 02 Jun 2011 16:19:16 +0200

As Peter says,

Adding to that is that there is a common false thought that the policy in
a CA:s certificate is a statement by that CA, while in fact it is a
statement by the CA above.

There are no reasons for practices used to issue CA certificates to be
represented as a policy OID. Such OID has no function in RFC 5280 path
validation.

So simplified:
A CA may put a policy OID in the certificates they issue. The semantics
this carry is:
1) If the issued certificate is a CA certificate: "Only the listed
policies can be validated in certificates issued under this CA"
2) If the issued certificate is an EE certificate: "Only the listed
policies can be valid for this certificate"

A complicating fact is that the policy mechanism was originally designed
to be a usability declaration and not a full statement about the
procedures under which this certificate was issued. For the original
purpose, the path validation processing rules are logical. It has become
very confusing as the policy OID has become more of a statement about
issuing procedures. It has caused CA certificate to carry policy OID that
has nothing to do with usage of EE certificates, and this is in total
conflict with RFC 5280 path validation.

/Stefan

On 11-06-02 9:32 AM, "Peter Sylvester" <[email-masked]> wrote:

>"Le numéro d¹OID du présent document est xxxx"

---

From: David CARELLA <[email-masked]>
Date: Mon, 06 Jun 2011 17:30:25 +0200

Hi,

Thank you for your answers.

Russ:
CPS URI is useful for human.
I need several assurance levels, then I need several policy OIDs to 
identify each assurance level.

Peter G.:
My questions are about technical and practical considerations, but not 
about functional matter.

Peter S.:
To resume: several CA (probably too many) have used the OID policy 
extension to put a reference to the policy (document), and it's wrong.
Is it better to write only one policy document? And write in it all 
policy OIDs. Then if I need OID for this policy document, I create 
another OID branch: i.e. one branch for policy, and one branch for document.
P.-S.: you have greetings from William too.

Stefan:
Policy OIDs are set in CA certificate as CRL distribution points. Policy 
OIDs (as CRL DP) are set in CA or EE certificate by the CA issuer.
So, if I do not need to limit to some policies, I don't set policy OIDs 
in CA certificates. If I need, the better is to set policy OID (e.g. 
only one policy) in the end CA (which issuing end entity certificates).

Another questions:

1. If I don't set policy OID in CA certificates (and it's always right 
for Root CA), which is better to set?
- nothing (i.e. no certificate policy extension),
- anyPolicy (2.5.29.32.0).
--> If I set anyPolicy in a CA certificate, must I set anyPolicy into 
all validation path CA certificates (i.e. "from this CA to Root CA")?

2. If I write only one policy document, must I indicate in it which 
paragraph deals with which policy (e.g. by reference to its OID)?
Hypothetical example:
-----------
OID-1: this authentication certificate contains digitalSignature...
OID-2: this signature certificate contains nonRepudiation...
-----------

3. Some PKI projects are split in several parts: Part #1 Root CA and 
Server CA, Part #2 Encryption CA, Part #3 Signature CA. And these parts 
can be done during non consecutive periods: e.g. Part #1 in 2011, Part 
#2 in 2012, and Part #3 later. So what is the best practice to write the 
policy document?
   a. Always update the same document (with a new minor document OID), 
and add the new policy OIDs in it?
   b. Create several documents: one document for each CA: e.g.:
       - one document for Root CA (without policy OID)
       - one document for Server CA (with one policy OID)
       - one document for Encryption CA (with one policy OID)
       - one document for Signature CA (with one policy OID)

Best regards,
David

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 06 Jun 2011 18:52:03 +0200

David,

Unfortunately I find your reasoning very confusing and hence your
questions are hard to answer. Some generics.

- No, policy OIDs are not placed in CRL DPs, they are placed in the
certificate policies extension.
- Yes you might explain the meaning of several policy OIDs in one document.
- Yes, you need to set the anyPolicy in all CA certificates, or set
explicit policies in order to avoid the result set of valid policies to be
empty. Root certificates are excluded from this requirement.

/Stefan

On 11-06-06 5:30 PM, "David CARELLA" <[email-masked]> wrote:

>>>> matter".  So you need to formulate a policy as to which policy you
>>>>want
>>>> to
>>>> follow.

---

From: David CARELLA <[email-masked]>
Date: Tue, 07 Jun 2011 11:30:09 +0200

Hello,

Of course, CRL DPs is another subject no related to policy OIDs.
My English isn't good enough to put into words my mind.

You had answered to my questions.

Thank you.
David

-- 
David CARELLA
Ingénieur Expert PKI, Chef de projet Sécurité
LINAGORA - LGS - Pôle Sécurité
Courriel : [email-masked]
Tél. : +33 (0)1 46 96 63 63, poste 550
Fax : +33 (0)1 46 96 63 64

Groupe LINAGORA - www.linagora.com
LinPKI, offres sécurité - www.linpki.org
EJBCA-fr, PKI open source - www.ejbca-fr.org