Subject: Another certificate policy question

From: [email-masked] (Peter Gutmann)
Date: Fri, 17 Jan 2003 18:21:41 +1300

Actually it's not really a question, more a thinking-out-loud: I've just been
sent yet another odd cert which has a single policy OID but two different
CPSes associated with it as qualifiers.  This is valid according to the RFC,
but seems a bit odd.

Given that the policy extension has become a kitchen-sink extension into which
people are just shovelling everything they can think of, perhaps we should
change the name to kitchenSink (to match the SINK RR) and define a new policy
extension that can't contain anything more than policy OIDs.  I shudder to
think what would be required to meaningfully process some of the kitchenSinks
I've seen if the critical flag was set on them.

Peter.

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Fri, 17 Jan 2003 12:46:14 +0100 (CET)

In message <[email-masked]> on Fri, 17 Jan 2003 18:21:41 +1300, [email-masked] (Peter Gutmann) said:

pgut001> Actually it's not really a question, more a
pgut001> thinking-out-loud: I've just been sent yet another odd cert
pgut001> which has a single policy OID but two different CPSes
pgut001> associated with it as qualifiers.  This is valid according to
pgut001> the RFC, but seems a bit odd.

That *is* odd...  Do they cover different things, or do they specify
roughly the same things but differently?

pgut001> Given that the policy extension has become a kitchen-sink
pgut001> extension into which people are just shovelling everything
pgut001> they can think of, perhaps we should change the name to
pgut001> kitchenSink (to match the SINK RR)

*laugh*

pgut001> and define a new policy extension that can't contain anything
pgut001> more than policy OIDs.

I violently disagree with the single policy suggestion.  However, I
could definitely see an extension that could contain a list of CP+CPS
pairs, where the CPS would be optional...  The reason is that a CA
cert should be possible to use under more than one policy (I'm dubious
about having EE certs running under more than one policy, but I guess
that's a question of policies...).

Now, about the reality of something like that ever turning up (what
with interoperability, or at least attempts in that direction)...

pgut001> I shudder to think what would be required to meaningfully
pgut001> process some of the kitchenSinks I've seen if the critical
pgut001> flag was set on them.

You can always invalidate the path...

-- 
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: "Joel S. Kazin" <[email-masked]>
Date: Fri, 17 Jan 2003 09:22:13 -0500

>CPSes associated with it as qualifiers.  This is valid according to the RFC,

Odd indeed!  There is a slight discrepancy between the text of RFC 3280 and 
the ASN.1 notation for the type.

"This specification defines two policy qualifier types for use by
    certificate policy writers and certificate issuers.  The qualifier
    types are the CPS Pointer and User Notice qualifiers.

    The CPS Pointer qualifier contains a pointer to a Certification
    Practice Statement (CPS) published by the CA.  The pointer is in the
    form of a URI.  Processing requirements for this qualifier are a
    local matter.  No action is mandated by this specification regardless
    of the criticality value asserted for the extension." (RFC 3280)

The RFC clearly is talking about a single CPS pointer.

A few lines down the RFC gives the following ASN.1:

PolicyInformation ::= SEQUENCE {
         policyIdentifier   CertPolicyId,
         policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                 PolicyQualifierInfo OPTIONAL }

    CertPolicyId ::= OBJECT IDENTIFIER

    PolicyQualifierInfo ::= SEQUENCE {
         policyQualifierId  PolicyQualifierId,
         qualifier          ANY DEFINED BY policyQualifierId }

    -- policyQualifierIds for Internet policy qualifiers

    id-qt          OBJECT IDENTIFIER ::=  { id-pkix 2 }
    id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
    id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }

    PolicyQualifierId ::=
         OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

Which could carry OIDs for more than one CPS.

Once in a while you have to read the text of the RFC!   I once stumbled 
into a similar ambiguity in RFC 2459 concerning UTC Time.

In any event such a certificate is an error. Perhaps they intended to list 
two CPs and made an error. Can you find both documents from the OID or URI? 
Are they both CPSs or is one a CP?

>I've seen if the critical flag was set on them.

Senior Consultant
Technical Consulting Practice, Northeast Region
Schlumberger Network Solutions

[email-masked]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  +1 914-769-8780
Mobile  +1 914-645-5598

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 17 Jan 2003 10:06:54 -0500

Peter:

I think a certificate could be valid for a variety of policies, but should
be issued under a single CPS.  Thus, there should be a single CPS pointer.

This assumes that the certificate does not have subject directory attribute
extension with different practices for validating and asserting multiple
roles and privileges.

I do not understand the CA having multiple CPS's for multiple policies.  CA
should have a single CPS for multiple policies.  But, may be the CA is using
different CPS for different policies.  Even in that case, the certificate
was generated using only one CPS.

In short, I think it should have a single CPS pointer.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Gutmann
Sent: Friday, January 17, 2003 12:22 AM
To: [email-masked]
Subject: Another certificate policy question

Actually it's not really a question, more a thinking-out-loud: I've just
been sent yet another odd cert which has a single policy OID but two
different CPSes associated with it as qualifiers.  This is valid according
to the RFC, but seems a bit odd.

Given that the policy extension has become a kitchen-sink extension into
which people are just shovelling everything they can think of, perhaps we
should change the name to kitchenSink (to match the SINK RR) and define a
new policy extension that can't contain anything more than policy OIDs.  I
shudder to think what would be required to meaningfully process some of the
kitchenSinks I've seen if the critical flag was set on them.

Peter.