Subject: Problems with 3280 Bis

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 13 Feb 2006 06:16:57 -0800

I have been reviewing Section 6 of the RFC.

The RFC is in great shape thanks to the editors.  I do have some
comments though.

None of these comments in my opinion are a material change to the
standard, except one.  For that one, if the community is averse to the
change, I have provided some alternatives.  Some of the changes (while
they do not change the standard) are important in my view to eliminate
misinterpretation of the standard.

A.  Section 6.1.2, item j, the working issuer name should be initialized
to the subject DN in the trust anchor information, just in case the
trust anchor is not self-issued or does not contain issuer DN.

B  Section 6.1.3, item c, excluded subtree check, the phrase "is not
within one" appears in two places.  The intent of both checks is "is not
within any" or "is within none".  This must be rectified.  The current
language is open for insecure interpretation and implementation.
Furthermore, the current language can be used successfully to defend
erroneous implementations.

C  Section 6.1.3, item d (2), text above Figure 6, add "with no policy
qualifiers"

D  Section 6.1.3, Text above Figure 7, the sentence "The following
application of the rule does not cause any nodes to be deleted, and this
step is complete."  should be replaced with "The application of the rule
does not cause any more nodes to be deleted, and this step is complete"

E  There is an error in processing policy mapping in the last
certificate.  If the last certificate had policy mapping in it, this
certificate will be erroneously accepted.  That was not the intent of
the policy mapping flaw and fix.  The step b (2) from 6.1.4 should be
added to 6.1.5.  In addition, since anyPolicy may be present in the end
certificate, deletion of anyPolicy is also warranted.

It is recognized this flaw only manifests itself when end certificate is
a CA certificate.  If there is a great deal of reticence on the part of
the community to add this extra check, the issue should be described in
the security considerations and implementers who consider this to be a
problem, should be advised of the fix.

Further details on the concern are provided at the end of this e-mail.

F.  CRL Certification Path requirement stated in Security Considerations
section about certificate certification path and CRL certification path
emanating from the same root should also be included somewhere in
Section 6.  This will make the RFC more user-friendly.  Also, note that
there are many "SHALL" and "MUST" in the RFC that do not apply to
consumers.  It will nice to have consumer requirements in Section 6
(Certification Path Validation).

G  The CRL processing rules imply that base and delta must be signed
using the same key.  Do we want this constraint?  If so, this should be
made explicit in the trust model and other relevant parts of the
standard.

MORE ON ITEM E.

Let us say that there are three domains: X, Y and Z and let us say that
CAs with the same names in the respective domains have cross certified
as shown below.

X --> Y --> Z

Let us say that Certificate (X, Y) has policy A and maps A = B and sets
skipCerts = 0 for inhibitPolicyMapping

Let us say that Certificate (Y,Z) has policy B and maps B to C.

The way the logic is, users in domain X will accept cross certificate Y
--> Z for policy A.  The intent of the policy mapping flaw and fix was
to reject this certificate for policy A in addition to the certificates
issued by domain Z.

Santosh Chokhani 
Orion Security Solutions, Inc. 
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101 
(703) 917-0060  Ext. 35 (voice) 
(703) 917-0260 (Fax) 
[email-masked] 
Visit our Web site 
http://www.orionsec.com <http://www.orionsec.com>

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 23 Feb 2006 12:26:20 -0500

Santosh,

My responses are in-line.

Santosh Chokhani wrote:

A.
Section 6.1.2, item j, the working issuer name should be initialized to
the
subject DN in the trust anchor information, just in case the trust
anchor is
not self-issued or does not contain issuer DN.

I agree that if the trust anchor information may be provided in the
form of a certificate that is not self-signed and that one would want
to set the working_issuer_name to the subject field from the
certificate in that case.  However, if any clarification needs to be
made, it cannot be made by simply changing section 6.1.2, item j.

When section 6.1.2, item j states that "[t]he working_issuer_name is
initialized to the trusted issuer provided in the trust anchor
information", it is not referring to the issuer field of a certificate
but rather to the "trust anchor information" as defined in section
6.1.1 (Inputs), item d.  Section 6.1.1, item d indicates that "trust
anchor information" includes the trusted issuer name.  It is explained
that "trust anchor information may be provided to the path processing
procedure in the form of a self-signed certificate", but it does not
describe from where in the certificate the information should be
extracted.

In this light, please let me know if you have any suggestions for how
the text could be made more clear.

B
Section 6.1.3, item c, excluded subtree check, the phrase “is not
within
one” appears in two places.  The intent of both checks is “is
not within any” or “is within none”.  This must be
rectified.  The current language is open for insecure interpretation
and
implementation.  Furthermore, the current language can be used
successfully to defend erroneous implementations.

I have changed both occurrences to "is not within any".

C
Section 6.1.3, item d (2), text above Figure 6, add “with no policy
qualifiers”

Done.

D
Section 6.1.3, Text above Figure 7, the sentence “The following
application of the rule does not cause any nodes to be deleted, and
this step
is complete.”  should be replaced with “The application of the
rule does not cause any more nodes to be deleted, and this step is
complete”

I disagree.  The word "following" is included to indicate that the
third application of the rule does not cause any nodes to be deleted.
Without the word "following", the sentence would be stating that the
second application of the rule does not cause any more nodes to be
deleted, even though the second application resulted in the node marked
with a "Y" being deleted.

E
There is an error in processing policy mapping in the last
certificate.
If the last certificate had policy mapping in it, this certificate will
be
erroneously accepted.  That was not the intent of the policy mapping
flaw
and fix.  The step b (2) from 6.1.4 should be added to 6.1.5.  In
addition, since anyPolicy may be present in the end certificate,
deletion of
anyPolicy is also warranted.

It is
recognized this flaw only manifests itself when end certificate is a CA
certificate.  If there is a great deal of reticence on the part of the
community to add this extra check, the issue should be described in the
security considerations and implementers who consider this to be a
problem,
should be advised of the fix.

Further
details on the concern are provided at the end of this e-mail.

It should be noted that RFC 3280 is consistent with X.509 on this.  So,
any changes to the processing logic in 3280bis without a similar change
to X.509 would result in the two standards being inconsistent.

Santosh and I have discussed this issue off-line, and I have told him
my opinion on this issue, but I would like to know if others believe
that the current processing rules are consistent with or inconsistent
with their expectations for how certification paths such as the one
that Santosh describes should be processed.

F.
CRL Certification Path requirement stated in Security Considerations
section
about certificate certification path and CRL certification path
emanating from
the same root should also be included somewhere in Section 6.  This
will
make the RFC more user-friendly.  Also, note that there are many
“SHALL” and “MUST” in the RFC that do not apply to
consumers.  It will nice to have consumer requirements in Section 6
(Certification Path Validation).

I'll look into adding something to section 6.3.3, step f.  However, it
should be noted that there are many requirements that apply to relying
parties that do not appear in section 6.  For example, section 6.1.4,
step (a)(4) requires the comparison of two names, but section 4.1.2.4
specifies the set of attributes that relying parties MUST be able to
support and section 7 provides the detailed rules for comparing names.
Similarly, one needs to read section 4.2.1.10 to determine the set of
name forms for which relying parties are required to be able to process
name constraints.  Section 4.2.1.10 also includes all the information
on how to process name constraints for each name form.

G
The CRL processing rules imply that base and delta must be signed using
the
same key.  Do we want this constraint?  If so, this should be made
explicit in the trust model and other relevant parts of the standard.

As noted in a subsequent email, this aligns with the requirement in
section 5.2.4 that conforming CRL issuers "MUST use the same private
key to sign the delta CRL and any complete CRL that it can be used to
update."  While this is not an X.509 requirement, and so the algorithm
in section 6.3 may reject delta CRLs that are valid, there was a
decision made when RFC 3280 was written to write a simplified CRL
validation algorithm (section 6.3) that would only be guaranteed to
accept CRLs if they were issued in conformance with RFC 3280.  So,
section 6.3.3 specifies how to validate the signature on a delta CRL in
the case that it was issued in conformance with 3280bis and is silent
on the extra steps that would be required if the complete and delta
CRLs were signed with different keys.  However, section 6.3 does
indicate that a conforming relying party does not have to implement the
algorithm specified in that section and could accept CRLs that would
not validate using the algorithm in section 6.3 (as long as they are
valid according to X.509).

Dave

MORE
ON ITEM E.

Let
us say that there are three domains: X, Y and Z and let us say that CAs
with
the same names in the respective domains have cross certified as shown
below.

X à Y à Z

Let
us say that Certificate (X, Y) has policy A and maps A = B and sets
skipCerts =
0 for inhibitPolicyMapping

Let
us say that Certificate (Y,Z) has policy B and maps B to C.

The
way the logic is, users in domain X will accept cross certificate Y à Z for policy A.  The intent
of the policy
mapping flaw and fix was to reject this certificate for policy A in
addition to
the certificates issued by domain Z.

Santosh Chokhani

Orion
Security Solutions, Inc.

1489 Chain
Bridge Road, Suite 300

McLean, Virginia
22101

(703)
917-0060  Ext. 35 (voice)

(703)
917-0260
(Fax)

[email-masked]

Visit
our Web site

http://www.orionsec.com

---

From: Tom Gindin <[email-masked]>
Date: Thu, 23 Feb 2006 22:51:16 -0500

David:

        My wording for Santosh's first point (Section 6.1.2, item j) goes 
as follows: The working issuer name should be initialized to the subject 
DN of the certificate containing the trust anchor information, or to a 
separately provided issuer DN in cases where anchor information is not 
provided in the form of a certificate.
        I think that this is approximately what he meant.  I certainly 
think that it is the right advice.

        Tom Gindin

"David A. Cooper" <[email-masked]>
Sent by: [email-masked]
02/23/2006 12:26 PM
 
        To:     Santosh Chokhani <[email-masked]>
        cc:     pkix <[email-masked]>
        Subject:        Re: Problems with 3280 Bis

Santosh,

Santosh Chokhani wrote: 
 A.  Section 6.1.2, item j, the working issuer name should be initialized 
to the subject DN in the trust anchor information, just in case the trust 
anchor is not self-issued or does not contain issuer DN.
I agree that if the trust anchor information may be provided in the form 
of a certificate that is not self-signed and that one would want to set 
the working_issuer_name to the subject field from the certificate in that 
case.  However, if any clarification needs to be made, it cannot be made 
by simply changing section 6.1.2, item j.

When section 6.1.2, item j states that "[t]he working_issuer_name is 
initialized to the trusted issuer provided in the trust anchor 
information", it is not referring to the issuer field of a certificate but 
rather to the "trust anchor information" as defined in section 6.1.1 
(Inputs), item d.  Section 6.1.1, item d indicates that "trust anchor 
information" includes the trusted issuer name.  It is explained that 
"trust anchor information may be provided to the path processing procedure 
in the form of a self-signed certificate", but it does not describe from 
where in the certificate the information should be extracted.

In this light, please let me know if you have any suggestions for how the 
text could be made more clear.
B  Section 6.1.3, item c, excluded subtree check, the phrase ?is not 
within one? appears in two places.  The intent of both checks is ?is not 
within any? or ?is within none?.  This must be rectified.  The current 
language is open for insecure interpretation and implementation. 
Furthermore, the current language can be used successfully to defend 
erroneous implementations.
I have changed both occurrences to "is not within any".
C  Section 6.1.3, item d (2), text above Figure 6, add ?with no policy 
qualifiers?
Done.
D  Section 6.1.3, Text above Figure 7, the sentence ?The following 
application of the rule does not cause any nodes to be deleted, and this 
step is complete.?  should be replaced with ?The application of the rule 
does not cause any more nodes to be deleted, and this step is complete?
I disagree.  The word "following" is included to indicate that the third 
application of the rule does not cause any nodes to be deleted.  Without 
the word "following", the sentence would be stating that the second 
application of the rule does not cause any more nodes to be deleted, even 
though the second application resulted in the node marked with a "Y" being 
deleted.
E  There is an error in processing policy mapping in the last certificate. 
 If the last certificate had policy mapping in it, this certificate will 
be erroneously accepted.  That was not the intent of the policy mapping 
flaw and fix.  The step b (2) from 6.1.4 should be added to 6.1.5.  In 
addition, since anyPolicy may be present in the end certificate, deletion 
of anyPolicy is also warranted.
 
It is recognized this flaw only manifests itself when end certificate is a 
CA certificate.  If there is a great deal of reticence on the part of the 
community to add this extra check, the issue should be described in the 
security considerations and implementers who consider this to be a 
problem, should be advised of the fix.
 
Further details on the concern are provided at the end of this e-mail.
It should be noted that RFC 3280 is consistent with X.509 on this.  So, 
any changes to the processing logic in 3280bis without a similar change to 
X.509 would result in the two standards being inconsistent.

Santosh and I have discussed this issue off-line, and I have told him my 
opinion on this issue, but I would like to know if others believe that the 
current processing rules are consistent with or inconsistent with their 
expectations for how certification paths such as the one that Santosh 
describes should be processed.
F.  CRL Certification Path requirement stated in Security Considerations 
section about certificate certification path and CRL certification path 
emanating from the same root should also be included somewhere in Section 
6.  This will make the RFC more user-friendly.  Also, note that there are 
many ?SHALL? and ?MUST? in the RFC that do not apply to consumers.  It 
will nice to have consumer requirements in Section 6 (Certification Path 
Validation).
I'll look into adding something to section 6.3.3, step f.  However, it 
should be noted that there are many requirements that apply to relying 
parties that do not appear in section 6.  For example, section 6.1.4, step 
(a)(4) requires the comparison of two names, but section 4.1.2.4 specifies 
the set of attributes that relying parties MUST be able to support and 
section 7 provides the detailed rules for comparing names.  Similarly, one 
needs to read section 4.2.1.10 to determine the set of name forms for 
which relying parties are required to be able to process name constraints. 
 Section 4.2.1.10 also includes all the information on how to process name 
constraints for each name form.
G  The CRL processing rules imply that base and delta must be signed using 
the same key.  Do we want this constraint?  If so, this should be made 
explicit in the trust model and other relevant parts of the standard.
As noted in a subsequent email, this aligns with the requirement in 
section 5.2.4 that conforming CRL issuers "MUST use the same private key 
to sign the delta CRL and any complete CRL that it can be used to update." 
 While this is not an X.509 requirement, and so the algorithm in section 
6.3 may reject delta CRLs that are valid, there was a decision made when 
RFC 3280 was written to write a simplified CRL validation algorithm 
(section 6.3) that would only be guaranteed to accept CRLs if they were 
issued in conformance with RFC 3280.  So, section 6.3.3 specifies how to 
validate the signature on a delta CRL in the case that it was issued in 
conformance with 3280bis and is silent on the extra steps that would be 
required if the complete and delta CRLs were signed with different keys. 
However, section 6.3 does indicate that a conforming relying party does 
not have to implement the algorithm specified in that section and could 
accept CRLs that would not validate using the algorithm in section 6.3 (as 
long as they are valid according to X.509).

Dave
MORE ON ITEM E.
 
Let us say that there are three domains: X, Y and Z and let us say that 
CAs with the same names in the respective domains have cross certified as 
shown below.
 
X à Y à Z

 
The way the logic is, users in domain X will accept cross certificate Y à 
Z for policy A.  The intent of the policy mapping flaw and fix was to 
reject this certificate for policy A in addition to the certificates 
issued by domain Z.
Santosh Chokhani 
Orion Security Solutions, Inc. 
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101 
(703) 917-0060  Ext. 35 (voice) 
(703) 917-0260 (Fax) 
[email-masked] 
Visit our Web site 
http://www.orionsec.com