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

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 13 Mar 2003 23:45:02 +0800

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

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 14 Mar 2003 15:50:17 -0500

I haven't had a chance to think about all of the possible consequences 
of additional fields in the issuingDistributionPoint extension, but I 
will try to address the comments below in light of the current PKIX 
standards.

See comments below.

>of SOAs. Since these are PMI-related flags, the change of them are less
These may be a problem, but if I understand correctly, it will not be an 
issue if certificate issuers limit themselves to the features of the 
PKIX profiles.

First, PKIX does not include the SOAIdentifier extension.  If no 
certificates are issued with the SOAIdentifier extension, it would make 
no sense to have a CRL that only covered certificates that include this 
extension.

The PKIX attribute certificate profile, RFC 3281, discourages the use of 
delegation.  If I understand correctly, conformance to this profile 
would mean that there would be no AA certificates, only user attribute 
certificates.  If this is the case, then the change from 
onlyContainsAttributeCerts to containsUserAttributeCerts should not be a 
problem since all attribute certificates are user attribute certificates.

>set to TRUE at the same time. It seems that the semantics of these flags is
While one can now set more than one flag to TRUE, it should not be a 
significant problem.   If you are checking the status of an end entity 
public key certificate and the 
onlyContainsUserCerts/containsUserPublicKeyCerts flag is TRUE or if all 
of the contains... flags are FALSE, then the certificate is covered. 
 This is the same general rule as before.

>2. The containsCACerts flag indicates "whether the CRL scope covers CA
I believe you are misquoting TC3 to X.509. The text states:

        If containsUserPublicKeyCerts is true, the CRL contains 
revocations for end-entity public-key
        certificates. If containsCACerts is true, the CRL contains 
revocations for CA certificates.

The text above does not say what it means if these flags are false. 
 That is covered elsewhere and the text clearly states that if all of 
the flags are false then all types of certificates are covered.

>3280 and the original X.509 standard.
As I stated above, this is not what TC3 states.  If all of the 
contains... are false, then all types of certificates are covered just 
as before.

>CRL scope covers both EE certificates and CA certificates".
>
Exactly, so there is no conflict.

>Unfortunately, that is conflict with X.680 and X.690 standards. The ASN.1 rule is
There is no conflict with X.680/X.690.  It has always been the case for 
the IDP extension that if the value of one of the flags if FALSE (the 
default) then it does not appear in the encoding.  TC3 does not 
contradict this.  TC3 states that if all of the values are FALSE, then 
it means that the CRL covers all types of certificates.  You are 
confusing the encoding of the values (if FALSE then absent as mandated 
by DER in X.690) with the semantics (meaning) of a particular value.

TC3 states what it MEANS when all of the flags are set to false, X.690 
states how to ENCODE these values.  The two are not related.

>both set to TRUE at the same time since they are exclusive to each other.
TC3 is very clear that one does not need to set both flags to TRUE.  If 
all flags are false then all types of certificates are covered. While 
the TC3 does allow for more than one flag to be set, one should continue 
for set all flags to false to indicate that all types of certificates 
are covered.

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Sat, 15 Mar 2003 16:51:25 +0800

Hi, David,

> will try to address the comments below in light of the current PKIX
Actucally, the change of extending PMI-related fields to the IDP
extension is fine to me. I believe that the PMI-related field,
onlyContainsAttributeCerts, has not been widely
used yet. Therefore, if you want to extend it, please hurry up. It is better
to be done before the PMI is widely deployed. What I worry is that the
remove of the adverb "only" from some fields of the IDP extension.
Especailly I am worrying about the change of onlyContainsUserCerts and
onlyContainsCACerts fields, which are now widely use to distinguish CARL
and EPRL. IMO, the remove of the adverb "only" will introduce some conflicts
with the original definition of the IDP extension. See my comments below.

> problem since all attribute certificates are user attribute certificates.
Extending PMI-related fields is fine for me. However, if the adverb "only"
is to
be remove from onlyContainsAttributeCerts, the consequence of changing the
semantics should be also carefully evaluated.

I know that you do not agree that the remove of the adverb "only" will
change
the semantics. However, please see my comments below.

> revocations for CA certificates.
I did not quote the text from TC3 to X.509, I just tried to state my
interpretation of it.
Doesn't my interpretation agree with you? I said "In the new definition, the
containUserCerts flag indicates "whether the CRL scope covers EE
certificates",
and the containsCACerts flag indicates "whether the CRL scope covers CA
certificates".
Please note that I did not say "ONLY" in my interpretation.

> the flags are false then all types of certificates are covered.
......
> contains... are false, then all types of certificates are covered just

I do not understand your logic. What kind of logic you are following?
Shouldn't it be
the Boolean logic? Since I am a follower of the Boolean logic, my
interpretation is as
follows.

Since

"If containsUserPublicKeyCerts is true, the CRL contains revocations for EE
public-key
certificates." (That is what you said.)

Doesn't it imply that

"If containsUserPublicKeyCerts is fasle, the CRL DOES NOT contains
revocations for EE
public-key certificates."

And since

"If containsCACerts is true, the CRL contains revocations for CA
certificates."
(That is also what you said.)

Doesn't it imply that

"If containsCACerts is false, the CRL DOES NOT contains revocations for CA
certificates."

Now you are telling us that

"If containsUserPublicKeyCerts is fasle(the default), the CRL contains
revocations for EE
public-key certificates."

and

"If containsCACerts is false(the default), the CRL contains revocations for
CA certificates."

Are you telling us that the Boolean logic does not apply to the X.509
standard?

In the original definition, the Boolean logic still works.

Since

"If onlyContainsUserCerts is true, the CRL ONLY contains revocations for EE
public-key
certificates."

it implies that

"If onlyContainsUserPublicKeyCerts is false, the CRL does not ONLY contains
revocations
for EE public-key certificates."

And since

"If onlyContainsCACerts is true, the CRL ONLY contains revocations for CA
certificates."

it implies that

"If onlyContainsCACerts is false, the CRL does not ONLY contains revocations
for CA
certificates."

Therefore, if onlyContainsUserCerts and onlyContainsCACerts are both false,
the CRL does
not ONLY contains revocations for end-entity public-key certificates and
does not ONLY
contains revocations for CA certificates.

The interpretation of this is "if onlyContainsUserCerts and
onlyContainsCACerts are both false
(the default), the CRL MAY contains revocations for both EE and CA
certificates". IMO, the
interpretation is not perfect, but it is acceptable.

Now you removed the adverb "only" from the definition, the story is
different.

> states how to ENCODE these values.  The two are not related.
If we follow the Boolean logic, I believe that the X.509 encoding rule to
the
default value really matters.

> for set all flags to false to indicate that all types of certificates
Again, if we follow the Boolean logic, I believe that

"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."

-----
Wen-Cheng Wang
Project Researcher

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 17 Mar 2003 07:19:36 -0500

Sharon:

I do not know if I have the answer to your question about how to do the
transition.  But, I note that following factors that should be considered in
making that determination.

1.  If a generator produces an IDP in accordance with the current syntax and
semantics, both processors (compliant with the current or compliant with the
proposed syntax and semantics) will process is correctly, except in one
case.  If the any subset (a set is also its own subset) of the three tags
([1], [2], [5]) is present and all values are set to false, neither the
current nor the proposed semantics clearly state if this is permitted and/or
what it covers.  That should be clarified in both the current and proposed
standard.  BTW, current X.509 Annex B and RFC 3280 Section 6.3.3 b (2) imply
that this CRL (meaning with any subset of the three tags present and set to
false) will cover all types of certificates issued by the CA.

2.  If a generator produces an IDP in accordance with the proposed syntax
and semantics, the proposal should state if the subset of all five ([1],
[2], [5], [6], [7]) tags are present and all set to false, and no tag is
present set to true, what the CRL covers or whether it is a valid CRL.

3. We all know that a processor compliant with current syntax and semantics
will have problems with the CRL generated using the proposed syntax and
semantics.  It might choke on tags [6] and/or [7].  It will reject a CRL
that is relevant since it may not like multiple of the tags set to true.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wen-Cheng Wang
Sent: Saturday, March 15, 2003 3:51 AM
To: [email-masked]
Cc: [email-masked]; Sharon Boeyen
Subject: Re: Will IDP syntax and semantics be changed in the future?

Hi, David,

> will try to address the comments below in light of the current PKIX 
Actucally, the change of extending PMI-related fields to the IDP extension
is fine to me. I believe that the PMI-related field,
onlyContainsAttributeCerts, has not been widely used yet. Therefore, if you
want to extend it, please hurry up. It is better to be done before the PMI
is widely deployed. What I worry is that the remove of the adverb "only"
from some fields of the IDP extension. Especailly I am worrying about the
change of onlyContainsUserCerts and onlyContainsCACerts fields, which are
now widely use to distinguish CARL and EPRL. IMO, the remove of the adverb
"only" will introduce some conflicts with the original definition of the IDP
extension. See my comments below.

> These may be a problem, but if I understand correctly, it will not be 
> an issue if certificate issuers limit themselves to the features of 
> the PKIX profiles.
>
> certificates are issued with the SOAIdentifier extension, it would 
> make no sense to have a CRL that only covered certificates that 
> include this extension.
>
> The PKIX attribute certificate profile, RFC 3281, discourages the use 
> of delegation.  If I understand correctly, conformance to this profile 
> onlyContainsAttributeCerts to containsUserAttributeCerts should not be 
> a problem since all attribute certificates are user attribute 
> certificates.
>
Extending PMI-related fields is fine for me. However, if the adverb "only"
is to be remove from onlyContainsAttributeCerts, the consequence of changing
the semantics should be also carefully evaluated.

I know that you do not agree that the remove of the adverb "only" will
change the semantics. However, please see my comments below.

I did not quote the text from TC3 to X.509, I just tried to state my
interpretation of it. Doesn't my interpretation agree with you? I said "In
the new definition, the containUserCerts flag indicates "whether the CRL
scope covers EE certificates", and the containsCACerts flag indicates
"whether the CRL scope covers CA certificates". Please note that I did not
say "ONLY" in my interpretation.

......

I do not understand your logic. What kind of logic you are following?
Shouldn't it be the Boolean logic? Since I am a follower of the Boolean
logic, my interpretation is as follows.

Since

"If containsUserPublicKeyCerts is true, the CRL contains revocations for EE
public-key certificates." (That is what you said.)

Doesn't it imply that

"If containsUserPublicKeyCerts is fasle, the CRL DOES NOT contains
revocations for EE public-key certificates."

And since

"If containsCACerts is true, the CRL contains revocations for CA
certificates." (That is also what you said.)

Doesn't it imply that

"If containsUserPublicKeyCerts is fasle(the default), the CRL contains
revocations for EE public-key certificates."

and

Since

it implies that

"If onlyContainsUserPublicKeyCerts is false, the CRL does not ONLY contains
revocations for EE public-key certificates."

And since

it implies that

for CA certificates."

Therefore, if onlyContainsUserCerts and onlyContainsCACerts are both false,
the CRL does not ONLY contains revocations for end-entity public-key
certificates and does not ONLY contains revocations for CA certificates.

The interpretation of this is "if onlyContainsUserCerts and
onlyContainsCACerts are both false (the default), the CRL MAY contains
revocations for both EE and CA certificates". IMO, the interpretation is not
perfect, but it is acceptable.

> >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
> There is no conflict with X.680/X.690.  It has always been the case 
> for the IDP extension that if the value of one of the flags if FALSE 
> (the
If we follow the Boolean logic, I believe that the X.509 encoding rule to
the default value really matters.

> >"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag 
> >cannot be both set to TRUE at the same time since they are exclusive 
> >to each other.
> >
> TC3 is very clear that one does not need to set both flags to TRUE.  
> If all flags are false then all types of certificates are covered. 
> While the TC3 does allow for more than one flag to be set, one should 
> continue for set all flags to false to indicate that all types of 
> certificates are covered.
>

"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."

-----
Wen-Cheng Wang
Project Researcher