Subject: RE: Undefined combinations of extensions

From: Sharon Boeyen <[email-masked]>
Date: Wed, 23 Aug 2000 13:07:44 -0400

The defect report is clarifying, not changing, the way criticality
is treated for certificate extensions. Criticality applies to each 
extension independent of all others. Clearly, if one extension is 
included in a certificate as critical (e.g. certificate policies)
and another is included as non-critical (e.g. policy mappings), then 
there will be different results by relying party systems that do 
support policy mappings and ones that do not. However, there should 
be no difference in relying party systems that do support the extensions
regardless of their criticality. 

A CA sets the criticality flag for each and every extension as it sees 
fit. By setting an extension non-critical, the CA is accepting the fact 
that relying party systems that do not understand this extension will ignore
it when processing the certificate and relying party systems that do 
understand it will process it. When it sets the flag critical it is 
limiting the relying parties to ONLY those that understand the extension.

Any semantic relationship between two or more extensions (e.g. among the 
policy related ones) needs to be addressed by the issuer (for instance 
it doesn't make a lot of sense to issue a certificate with critical 
policy mappings but non-critical certificate policies). This is a policy 
issue though not one that the criticality flag should be used to solve.

If there is a situation where two extensions may cause conflicting 
impacts (e.g. the issuingDistributionPoint extension and the crlScope
extension), then the definition of the extensions themselves should 
contain the semantics of what is to be done (see the definition of 
crlScope which states that these 2 are not intended to be used together
but states what the rule is if both happen to be present). 

If the problem you are trying to solve is that extensions have not 
been properly or fully defined, then that problem should be fixed in 
the extension definitions themselves, not by trying to invert the meaning 
of critical and non critical in the standard.

Is there a concrete example you can share, that might bring to light some 
point I'm missing?

Sharon  

> -----Original Message-----
> From: David Chadwick [mailto:[email-masked]]
> Sent: Wednesday, August 23, 2000 12:36 PM
> To: [email-masked]
> Cc: Kurt D. Zeilenga; [email-masked]
> Subject: Undefined combinations of extensions
> 
> 
> 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: "Hoyt L. Kesterson II" <[email-masked]>
Date: Thu, 24 Aug 2000 23:55:18 -0700

i want to support sharon on her statement on the intent of the DR. 
the text that will be added to the standard to resolve the defect 
report will make it clear that if an implementation "recognizes" an 
extension, then that implementation shall support THAT extension 
according to the syntax and procedures specified in the clauses 
defining THAT extension. one of the problems of viewing the x.509 
standard by itself is that we have lost the valuable concept of the 
statement of conformance. i hope that the approved text will correct 
this lack.

this concern about relationships between extensions can be addressed 
in a variety of ways. for example, an environment, such as a vertical 
sector, could decide that certain extensions must be present 
(regardless of criticality settings) before a certificate is 
acceptable. in addition, permitted and disallowed combinations of 
extensions, or values within those extensions, could also be 
specified in a profile for that environment. only implementations 
with statements of proper conformance would be deployed into that 
environment.

however, the reason for extensibility, including criticality, must 
always be kept in mind - correct interoperation using an acceptable, 
commonly understood subset of information in a certificate.

one is permitted to define a new extension,X, that, if present, 
influences the interpretation of one or more other extensions, Y. 
however, if the issuer of a certificate wants to ensure that Y will 
always be interpreted in the new fashion, it must declare X critical 
(or know that the certificate will only be used within an environment 
that understands, and requires the presence of, X). if the issuer 
does not adhere to this principle, an implementation that is unaware 
of the definition of X will ignore X but will process Y according to 
the rules the implementation understand, i.e. without the nuances 
associated with the presence of X.

     hoyt