Subject: Undefined combinations of extensions

From: "David Chadwick" <[email-masked]>
Date: Wed, 23 Aug 2000 17:35:40 +0100

On the LDAPExt list we have been discussing the effects of 
combinations of extensions (controls in LDAP jargon) on the LDAP 
server performing an LDAP operation, when the effects of the 
combination of one or more extensions is not understood by the 
server. The server may understand each separate extension, but 
not the semantics of them in combination.

It seems to me that PKIX/X.509 will have (or already may have 
encountered) this same problem for COMBINATIONS of certificate 
extensions (some of which may be private, some de-facto, some 
critical, some not) that are thought to be understood by the issuing 
CA, but are not fully understood by the relying party / validation 
engine.

What text does anyone have for this situation? I believe the recently 
issued X.509 defect report 244, raised by Sharon, only discusses 
the case of a single extension in isolation, and does not discuss the 
effects of combinations of extensions.

The most interesting cases are when the RP finds combinations of 
extensions, where each extension on its own is understood, but 
where the combined semantics are not fully understood (possibly 
due to incomplete or ambiguous specification of extension 
interactions when the extensions are written by different groups).  In 
this case, LDAP is suggesting that a receiver may ignore non-
critical extensions (even those it recognizes) to establish the 
semantics of the operation. This is in direct contrast to the wording 
of defect report 244, which states that an understood non-critical 
extension must be obeyed. The LDAP work would suggest an 
addition to DR244 along the lines of

" A validation engine that does not understand the interaction of a 
non-critical extension with another extension (critical or non-critical), 
may ignore the non-critical extension (even if it understands the 
semantics of the extension in isolation to the others), and accept the 
certificate (unless factors other than this extension cause it to be 
rejected).

A validation engine that does not understand the interaction of two 
critical extensions, must reject the certificate (even if it understands 
the semantics of both extensions in isolation to each other)."

David

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

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
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

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Aug 2000 15:33:47 -0400

David,

Your question about combinations of extensions, and base 
certificate/CRL fields, is a good one.  Tim Polk and I discussed this 
issue during the last PKIX WG meeting, in a more limited context. I 
proposed that we include a table that described syntactic constraints 
among all the fields in a cert or CRL, to address the question of 
which combinations of fields and values are valid.   One cannot do 
this for really private extensions, and doing it for new extensions 
that are publicly disclosed is an ongoing task.  But, at least we 
should provide folks with a base set of constraints.  I think 2459 
should do this and I volunteered to provide a draft table for this.

Steve