Subject: RE: Will IDP syntax and semantics be changed in the future?

From: Sharon Boeyen <[email-masked]>
Date: Fri, 14 Mar 2003 09:38:34 -0500

There are a number of Defect Reports that have approved TCs that I believe 
need to be taken into consideration if RFC 3280 evolves from its current
state and 
I was planning to put together a summary of the differences for
consideration (however 
I haven't been able to get it together yet). I have been thinking about this
one 
in particular however very recently and am concerned that when we progressed
the 
TC in the 509 group we may not have worked through migration scenarios as
thoroughly 
as perhaps we might have. While it is true that the syntax (bits on the
wire) are the 
same, the semantics have definitely changed and I'm struggling to come up
with a 
reasonable migration strategy to suggest to profile groups such as PKIX. I'm
wondering 
if we shouldn't have actually changed the OID when the semantic changes were
made to 
the extension and am just beginning to investigate whether a) that is the
course of 
action that should be taken to enable profiles to include this revision and
b) what 
the process would be to achieve that if it is determined that it is needed. 

Other thoughts?

Sharon

-----Original Message-----
From: Wen-Cheng Wang [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 10:45 AM
To: [email-masked]
Subject: Will IDP syntax and semantics be changed in the future?

Hi,

Recently, I download the pre-published Technical Corrigendum 3 of X.509
4th edition (the prepublished X.509 TC3) from ITU-T website. The content
of the prepublished X.509 TC3 is mainly for correcting defect related to
CRL processing/validation. I do not know how soon the prepublished X.509
TC3 will come in force. However, I believe that, once it become in force, it
will introduce some conflicts between RFC 3280 and X.509 standards.
The syntax and semantics of Issuing Distribution Point
extension are different between RFC 3280 and the prepublished X.509
TC3 .

In RFC 3280, the definition of the IssuingDistributionPoint is as follows:
    IssuingDistributionPoint ::= SEQUENCE {
         distributionPoint    [0] DistributionPointName OPTIONAL,
         onlyContainsUserCerts    [1] BOOLEAN DEFAULT FALSE,
         onlyContainsCACerts    [2] BOOLEAN DEFAULT FALSE,
         onlySomeReasons    [3] ReasonFlags OPTIONAL,
         indirectCRL    [4] BOOLEAN DEFAULT FALSE,
         onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
(Note there is a typo in RFC 3280, the beginning "i" of
"issuingDistributionPoint" should be capitalized.)

In the prepublished X.509 TC 3 , the new definition is as follows:
    IssuingDistPointSyntax ::= SEQUENCE {
        distributionPoint   [0] DistributionPointName OPTIONAL,
        containsUserPublicKeyCerts [1] BOOLEAN DEFAULT FALSE,
        containsCACerts   [2] BOOLEAN DEFAULT FALSE,
        onlySomeReasons   [3] ReasonFlags OPTIONAL,
        indirectCRL    [4] BOOLEAN DEFAULT FALSE,
        containsUserAttributeCerts [5] BOOLEAN DEFAULT FALSE,
        containsAACerts   [6] BOOLEAN DEFAULT FALSE,
        containsSOAPublicKeyCerts [7] BOOLEAN DEFAULT FALSE }
(Note that the data type name is different, but it represents the same
thing.)
The most obvious change made by the prepublished X.509 TC 3 is that it
expands the onlyContainsAttributeCerts flag to two flags, namely
"containsUserAttributeCerts" and "containsAACerts", and it add another flag

named "containsSOAPublicKeyCerts" specifically for indicating whether the
set of certificates covered by the CRL contains the public-key certificates
of SOAs. Since these are PMI-related flags, the change of them are less
related to RFC 3280.
What we should note is that the remove of the adverb "only" from the
"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag. IMHO, the
remove of the adverb "only" from these flags not only changes the syntax but
also only changes the semantics. In RFC 3280, since the exist of the adverb
"only", these flags are exclusive to each other. That is, the
"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag cannot be
both set to TRUE at the same time. However, in the new definition, these
flags are not exclusive to each other anymore. That is, the
"containsUserPublicKeyCerts" flag and the "containsCACerts" flag can be both
set to TRUE at the same time. It seems that the semantics of these flags is
changed.

In RFC 3280, the semantics of these flags is as follows:
1. The onlyContainUserCerts flag indicates "whether the CRL scope ONLY
    covers EE certificates".
2. The onlyContainsCACerts flag indicates "whether the CRL scope ONLY
    covers CA certificates".
However, in the new definition, the semantics of these flags is as follows:
1. The containUserCerts flag indicates "whether the CRL scope covers EE
    certificates".
2. The containsCACerts flag indicates "whether the CRL scope covers CA
    certificates".
Fortunately, the default value of these flags are both FALSE, so that the
effect of letting one flag set to TRUE and the other flag set to FALSE or be
absent seems to be backward compatible to RFC 3280 and the original X.509
standards because:
1. a CRL with containUserCerts flag set to true and with containsCACerts
    absent means that its scope covers EE certificates but does not cover CA
    certificates; (That is, its scope only covers EE certificates.)
2. a CRL with containCACerts flag set to true and with containsUserCerts
    absent means that its scope covers CA certificates but does not cover EE
    certificates. (That is, its scope only covers CA certificates.)

The problem is that if containUserCerts flag and containsCACerts flag are
both absent, the accoding to the new semantics that will means the the scope
of the CRL does not cover both EE certificates and CA certificates since the
default value of these two flags are both FALSE. That is conflict with RFC
3280 and the original X.509 standard.

However, I believe that the author of the prepublished X.509 TC 3
also noticed the problem so that for maintaining back compatibility with
RFC 3280 and the original X.509 standard, the prepublished X.509 TC 3
specially specifies "if all these flags are absent, it indicates that the
CRL
scope covers both EE certificates and CA certificates". Unfortunately,
that is conflict with X.680 and X.690 standards. The ASN.1 rule is
"if the field has DEFAULT value and the field is absent, the DEFAULT
value is applied to the field".

With the new definition of IDP extension, to indicate that the CRL
scope covers both EE certificates and CA certificates, both flags
need to be set to TRUE. However, the the original definition, the
"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag cannot be
both set to TRUE at the same time since they are exclusive to each other.

Any comment?

-----
Wen-Cheng Wang
Project Researcher
Telecommunication Laboratories
Chunghwa Telecom Co., Ltd