Subject: RE: Problems with 3280 Bis

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 27 Feb 2006 05:08:28 -0800

Tom,

My concern is that if the trust anchor is a certificate, the language can be misconstrued to mean to initialize to the issuer of the certificate and that would be wrong unless the trust anchor was self-signed or self-issued.  Actually, a positive statement such as when the trust anchor is in the form of a certificate working_issuer_name is initialized to the subject field in the certificate since the trust anchor subject is the issuer of the first certificate in the certificate chain.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Sunday, February 26, 2006 10:50 PM
To: Santosh Chokhani
Cc: David A. Cooper; pkix
Subject: RE: Problems with 3280 Bis

        Santosh:

        You could take out the "issuer" in "separately provided issuer DN" 
if you wanted to.  I guess the point I'm trying to make is that while 
trust anchor information is usually provided as a certificate and IMO 
should usually be provided thus, it never has been mandatory to do so and 
an anchor's DN and public key may (not should) be provided as separate 
data fields in a database or a configuration file.

Tom Gindin

"Santosh Chokhani" <[email-masked]>
02/24/2006 06:40 AM
 
        To:     Tom Gindin/Watson/IBM@IBMUS, "David A. Cooper" 
<[email-masked]>
        cc:     "pkix" <[email-masked]>
        Subject:        RE: Problems with 3280 Bis

Tom,

The phrase "issuer DN" might be misconstrued.  You alternative wording 
should be revised to "separately provided issuer DN of the first 
certificate in the certification path" will also work.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Thursday, February 23, 2006 10:51 PM
To: David A. Cooper
Cc: Santosh Chokhani; pkix
Subject: Re: Problems with 3280 Bis

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,

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: Mon, 27 Feb 2006 21:12:12 -0500

Santosh:

        So we're in agreement on the meaning, and reasonable wording goes 
as follows: The working issuer name should be initialized to the DN used 
by the trusted issuer as his issuer name.  In cases where much of the 
trust anchor information is provided in the form of a certificate, the 
working issuer name should be initialized to the subject DN of the 
certificate containing the trust anchor information.

                Tom Gindin

02/27/2006 08:08 AM
 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     "pkix" <[email-masked]>
        Subject:        RE: Problems with 3280 Bis

Tom,

My concern is that if the trust anchor is a certificate, the language can 
be misconstrued to mean to initialize to the issuer of the certificate and 
that would be wrong unless the trust anchor was self-signed or 
self-issued.  Actually, a positive statement such as when the trust anchor 
is in the form of a certificate working_issuer_name is initialized to the 
subject field in the certificate since the trust anchor subject is the 
issuer of the first certificate in the certificate chain.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Sunday, February 26, 2006 10:50 PM
To: Santosh Chokhani
Cc: David A. Cooper; pkix
Subject: RE: Problems with 3280 Bis

        Santosh:

Tom Gindin

Tom,

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Thursday, February 23, 2006 10:51 PM
To: David A. Cooper
Cc: Santosh Chokhani; pkix
Subject: Re: Problems with 3280 Bis

David:

        Tom Gindin

Santosh,

Santosh Chokhani wrote: 

deleted.

 

Dave
MORE ON ITEM E.

X à Y à Z