Subject: Combination of policy OID:s

From: Stefan Santesson <[email-masked]>
Date: Thu, 17 Jun 1999 11:56:36 +0200

X.509 does not allow inclusion of several policy OID:s in a certificate
with the meaning that the relying party MUST accept more than one.

X.509, section "12.2.2.6  Certificate policies field" states:

"If the extension is flagged critical, it indicates that the certificate
shall only be used for the purpose, and in accordance with the rules
implied by ONE of the indicated certificate policies. The rules of a
particular policy may require the certificate-using system to process the
qualifier value in a particular way."

First of all... This logic is not clearly stated in RFC 2459  section
4.3.1.5. This is a problem since RFC 2459 implicitly requires this logic in
order to comply with the basic path validation logic stated in section 6.1 

Secondly... This logic may impose a problem under some circumstances.

This cause problems for the EU-standardization initiative as they have
discussed a solution with a EU-defined policy OID stating that the
certificate is a "Qualified Certificate" according to the EU-directive.
Such statement would then have to be combined with a CA specific policy OID.

This is not the only field where there has been discussions related to
"combine" several policy OID:s in order to formulate the complete policy
statement by the CA. The advantage of this could be the fact that some
policy OID's could be well defined and commonly understood (as some EU
defined statements)

One general solution to this problem could be define a policy qualifier
where the CA can enter policy OID:s that have to be accepted in combination
with the "parent" policy.

This could then be processed within the current path logic of X.509 and
RFC2459.

My questions related to this solution is:

- Would this be a desired solution to the problem?
- If so, where should it be specified?

It could be specified in the QC draft, but since this is a general problem,
it could be better to define it in RFC 2459 (next issue).

Comments?

/Stefan

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 17 Jun 1999 13:34:46 +0200

Denis,

I hope you don't mind that I copy this to the list, but I think this
clarification may be of public interest. 

The problem has nothing to do with criticality.

The only way to communicate (from a CA) to a relaying party (according to
the semantics of the policy extension) that he/she must "verify that the
expected OID is present" is by ONLY including that policy OID in the
certificate.

Further, the client of a relying party can't use the logical AND function
when examining combinations of policies (regardless or criticality)

I.e. follwoing X.509 and RFC 2459 path validation logic, you cant say to
the client:

1) The policy OID xxyy-qc-eu (EU QC OID) MUST be present AND;
2) One of the policies xx-1, xx-2, xx-3, xx-4 or xx-5 (accepted
CA-policies) MUST be present.

Today, the only thing you can say to a client is:

- Make sure that at least one of the policies xx-yy-eu, xx-1, xx-2, xx-3,
xx-4 or xx-5 is present in each certificate in the validated path.

So if you want to mandate presence of xx-yy-eu, you can't at the same time
require presence of any other policy.

/Stefan

At 01:07 PM 6/17/99 +0200, you wrote:
>Stefan,
>
>This is response where I have NOT copied the PKIX mailing list.
>
>Nothing in the Directive mandates that the certificate shall only be used for
>the Directive.
>The Policy OID does not need to be made critical. However the receiver must
>verify that the expected OID is present.
>
>This solves the problem, in a fairly different way. :-)
>
>Denis
>
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 Jun 1999 12:29:46 -0400

Stefan & Denis:

Persoanally, I really dislike policy qualifiers.  They have a negative
imapct on interoperability.  If a policy is specified by an OID, then the
cert path validation does not need to know any details of that policy.  On
the other hand, when qualifiers are used, cert path validation must
understand the syntax and possibly the semantics of the qualifier.

How does one get every implementation, especially mass market software
implementations, to support a particular policy qualifier?  Beats me.  That
is why they cause interoperability problems.

In drafting RFC 2459, I suggested that policy qualifiers be forbidden.
Others disagreed, so we have a compromise position documented in RFC 2459.
It says:

   To promote interoperability, this profile RECOMMENDS that policy
   information terms consist of only an OID.  Where an OID alone is
   insufficient, this profile strongly recommends that use of qualifiers
   be limited to those identified in this section.

A small set of policy qualifiers was included with the hope that all
implementations would include support for them.

So, my advice is to avoid policy qualifiers.

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 17 Jun 1999 22:01:43 +0200

Russ,

I agree in principle, but maybe not totally.

Unless the policy extension is critical, it is perfectly OK for a client to
ignore any qualifier. And qualifiers may have some advantages if used
properly. They will however most certainly only make sense to those
applications who are specifically trained for them.

In Qualified Certificates we have discussed inclusion of a monetary value
(to be used to specify a max reliance limit). It is proposed that this MAY
be specified by a qualifier , defined by a ISO defined ASN.1 field.

In this case the qualifier may make sense. It will only have to be
understood by those application who have been trained to react upon this
information. Further, the CA can see through that only specifically trained
clients will accept the certificates by setting this extension to critical.

Stephen Kent has expressed his preliminary support for this solution. At
least our conclusion has been that qualifier is the only possible way if we
should do anything at all. An extension can't be defined since it would be
to complex to define the semantics of such extension anyway, plus the fact
that policy information in additional extensions is generally deprecated.
So a qualifier is the only possible solution, if defined by PKIX, since the
semantics then is defined by the associated policy and not by the
specification.

But, what you say also makes sense and maybe we should not do anything at all.

At least... for the purpose of combining policy OID:s, I agree that using
policy qualifiers is NOT a good idea. I never really liked it but I wanted
comments on this in order to see it straight. 

Steve, do you have any comment on this as well?

/Stefan

---

From: "Charles Moore" <[email-masked]>
Date: Fri, 18 Jun 1999 07:57:41 +1000

----- Original Message -----
From: Russ Housley <[email-masked]>
To: Denis Pinkas <[email-masked]>; Stefan Santesson
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, June 18, 1999 2:29 AM
Subject: Re: Combination of policy OID:s

Stefan & Denis:

Persoanally, I really dislike policy qualifiers.  They have a negative
imapct on interoperability.

cm> Interoperability is a two edged sord, higher semantics can be benifital
to interoperability, but is a bit like a VPN it can limit the scope f
interoperabiltiy, but in many business situations this is the norm.

If a policy is specified by an OID, then the
cert path validation does not need to know any details of that policy.

cm> Would disagree, on this point, if you dont know the rules to process the
path you realy dont know what you are accepting as"valid".  Once again
depends on the scope of interoperability, the no rules approach is fine for
most of the non value transations that are more privacy based than anything
else.

On
the other hand, when qualifiers are used, cert path validation must
understand the syntax and possibly the semantics of the qualifier.
cm> See above, for anything usefull this is needed anyway.

cm> We have been isusing certs with policy qualifiers for some time, the
results... almost all end applications dont understand policy OID so happly
pass qualifier OIDs without problem. b) for those that care these have
policy enforcement processing that takes care of the policy and qualifier
issues. As product mature more semantic content and hence syntax can be
useful within communties, thse communities may start out small and grow as
required ( how interoperability actually happens).

cm> I would STRONGLY disagree with this approach, we ahve deployed
implementations that make use of these, and candemonstarte this does not
limit or degrade your view of ineroperabiltiy, but allows us and our
customers to support their business needs.

cm> Disagree as above.....

cm> My advise is to use what supports the business need, the technology s
NOt the driver here, dont confuse a lack of product and market maturity with
infrastruture support. This is not the time to limit functionality, when the
applications for this stuff is just begining to happen, especially when it
has not negative aspects for ineroperability...

Russ

---

From: "Nick Pope" <[email-masked]>
Date: Fri, 18 Jun 1999 11:20:36 +0100

Given that we cannot say whther a particular policy will be critical on not,
the problem with qualifiers applies to work on qualified certificates.

Nick

> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: 17 June 1999 21:02
> To: Russ Housley; Stephen Kent
> Cc: [email-masked]
> Subject: Policy Qualifierts Was: Re: Combination of policy OID:s
>
>
> Russ,
>
> >>>> Such statement would then have to be combined with a CA
> specific policy
> >OID.
> >>>>

---

From: "Todd S. Glassey - ELN" <[email-masked]>
Date: Fri, 18 Jun 1999 06:42:22 -0700

----- Original Message -----
From: Russ Housley <[email-masked]>
To: Denis Pinkas <[email-masked]>; Stefan Santesson
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 17, 1999 9:29 AM
Subject: Re: Combination of policy OID:s

> is why they cause interoperability problems.

Seems to me that there are many parts of the process that are application
depedent Russ - leave it up to the apps that use the data fioelds

> So, my advice is to avoid policy qualifiers.

From the purist's point I agree with you, but there is also the issue of
creating functional services that address commercial requirements, and
becuase that is what pays the bills I suggest that perhaps there is a class
of OIDs that can support Policy.

One of the policy control OID Structures I would like to see is a mechanism
to indicate a legal hierarchy. That is to say a representation of mechanism
for legal jusridictions.

This may be a subset of the policy OID concept but would be of tremendous
value in the world of Online EC enabled business, and while it is strictly a
"non challenging" technical aspect of EC it is a requirement none the less.

Todd

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 18 Jun 1999 17:24:05 +0200

I would like to discuss another solution which has surfaced during some
internal discussions.

We can conclude that there are several clear requirements statetd from the
"non-technical" society (mostly related to Qualified Certificates), which
demands inclusion of small explicit policy-related statements. The most
important one is "This is a Qualified Certificate according to EU-directive
Annex I and II"

They will just not go for the current policy oriented solution where everything
is said in just one OID, specific to the CA.

Putting additional OID:s in a policy qualifier can make a mess, so lets try to
avoid that.

Lets also assume that the policy OID:s used will be identifiers of COMPLETE
policy statements. I.e. they will work to support path validation as intended.

So additional OID-statements for speciffic policy related info would be
"redundant" but important by practical reasons (e.g. a common OID would cause
all compliant clients to express that "This is a Qualified Certificate
according to ......) 

So the alternative solution would be to create a new general extension for
"Qualified Certificate Statements" as follows:

   QualifiedCertifcateStatement  EXTENSION ::= {
      SYNTAX             QCStatementSyntax
      IDENTIFIED BY      id-qext-qCStatement }
 
    id-qext-qCStatement    OBJECT IDENTIFIER  ::= {id-qext xx}
  
    QCStatementSyntax ::= SEQUENCE OF QCStatement
   
    QCStatement ::= SEQUENCE {
        qCStatementId        OBJECTIDENTIFIER
        qCStatementInfo      ANY DEFINED BY qCStatementId OPTIONAL}

Within this extension it would be a free market to define and include
"redundant" explicit statements without detsroying path validation
interoperability.

Comments ?

Suggestions ?

/Stefan

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Jun 1999 13:42:39 -0400

Stefan:

If you have already determined that a separate extension is not a viable
alternative, then I suggest that you do nothing.  I do not think that you
can be sure that the certificate policies extension will always be
non-critical.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Jun 1999 10:57:45 -0400

Todd:

I believe that your proposal is in conflict with RFC 2459.  It says:

   4.2.1.5  Certificate Policies

      The certificate policies extension contains a sequence of one or more
      policy information terms, each of which consists of an object
      identifier (OID) and optional qualifiers.  These policy information
      terms indicate the policy under which the certificate has been issued
      and the purposes for which the certificate may be used.  Optional
      qualifiers, which may be present, are not expected to change the
      definition of the policy.

I think that the use of certificate policy qualifier you are proposing does
change the definition of the policy.  In my view, that means that a new
certificate policy OID should me assigned.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Jun 1999 15:59:13 -0400

Stefan:

First, I want to understand a bit more about your assumptions.  In
>is said in just one OID, specific to the CA.

Why do you say that the certificate policy (CP) OID is specific to a CA?  I
see several large communities defining a CP that will be used by many
different CAs.  The Certification Practice Statement (CPS) will be specific
to the CA; it documents how the CA practices meet the requirements in the
community-wide CP.

Russ

---

From: "Todd S. Glassey - ELN" <[email-masked]>
Date: Fri, 18 Jun 1999 18:29:21 -0700

Russ, I agree with you.
It does violate the 2459 rule model, but I also think it is a valid use
model and we should indeed issue the new policy OID.

Todd

----- Original Message -----
From: Russ Housley <[email-masked]>
To: Todd S. Glassey - ELN <[email-masked]>
Cc: Denis Pinkas <[email-masked]>; Stefan Santesson
<[email-masked]>; <[email-masked]>
Sent: Friday, June 18, 1999 7:57 AM
Subject: Re: Combination of policy OID:s

On

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 29 Jun 1999 00:24:17 +0200

All,

I conclude from various on-list and off-list discussions that the best way
to solve inclusion of statements related to legal frameworks in a Qualified
Certificate, is to provide this functionality in a private extension.

Three statements has been discussed related to the EU-directive:

1) Inclusion of a reliance limit (how much you should rely on the
certificate. Note that this has NOTHING to do with how much you should rely
on the certified subject).
2) Inclusion of a statement declaring that the certificate is a Qualified
Certificate according to a legal framework (In case of the EU-directive,
that the certificate meets Annex I and are issued according to Annex II)
2) Inclusion of a statement, limiting the area of use of the certificate.

I have earlier posted a proposal for such an extension. The current
proposal is:

    PolicyStatement  EXTENSION ::= {
      SYNTAX             PolicyStatementSyntax
      IDENTIFIED BY      id-pe-PolicyStatement }

    id-pe-policyStatement          OBJECT IDENTIFIER ::= { id-pe 3 }
    -- This is  only a proposed OID. It is not assigned yet.

    PolicyStatementSyntax ::= SEQUENCE OF Statement
   
    Statement ::= SEQUENCE {
        StatementId        OBJECTIDENTIFIER
        StatementInfo      ANY DEFINED BY StatementId OPTIONAL}

As these types of statements are policy statements, the QC standard SHALL
require that included statements are not in conflict with any policy
identified in the policy extension.

Stephen Kent replied to the last proposal with:

At 05:58 PM 6/18/99 -0400, Stephen Kent wrote:
>Stefan,
>
>This would make folks happy who hated the use of policy qualifiers for
>this, and address the incorporation by reference concerns too. One
>question: why do we need the "Any Defined by: here?  I'd rather not leave
>the hole for folks to incorporate text directly, instead of by pointer and
>hash.  why not replace the statement by those two data items?
>
>Please bring it to the list.
>
>Steve

The answer to this is that the StatmentInfo may be required in order to
make a good structure for several statements. I.e. one OID may define that
StatementInfo contains a reliance limit specified using the ISO structure
for monetary value  (expressed before), and another OID may define that the
StatementInfo contains information regarding restrictions of usage (e.g.
only for banking applications).

So this is a 2 step approach, but can also be used as an 1 step approach in
cases where an exact statement can be identified by a single OID. In the
latter case the StatementInfo is omitted.

Before I put this in the specification I would like some final reactions on
this.

/Stefan

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 30 Jun 1999 12:11:26 +0100

Stefan,

I need to request a change to the qualified certificate draft to allow 
the use of the localityName attribute to be used to unambiguously 
identify a subject and issuer in a DN. The UK National Health 
Service Standard for Directory Services requires the use of locality 
name to unambiguously identify different organisational units within 
the NHS. For example, there are literally dozens of St Mary's 
Hospitals within the UK NHS, so that O and OU are insufficient as 
differentiators. Consequently localityName, based on the UK Post 
Office defined localities, is used to differentiate between them (we 
do not use the full postal address as this is too cumbersome.)

As the QC draft stands at the moment, (as I read it), the use of 
localityName as currently defined by the NHS would not be allowed 
as a differentiator.

The offending sections are:

3.1.1 Issuer -  allows for state or province name but not for 
localityName. We request that localityName be added to this section.

3.1.2 Subject - allows postalAddress but not localityName and states 
"Other attributes may be present but MUST NOT be necessary to 
distinguish the subject name from other subject names within the 
issuer domain."

This effectively precludes localityName from being used to 
unambiguously differentiate between hospital. We request that 
localityName be added to the MAY list.

Regards
David

***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
*NEW* Mobile +44 790 167 0359 *NEW*
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************