Subject: issuerAltName and path construction

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 14 Jul 2005 10:21:34 +0400

Hi,

I have probably very simple question. If certificate contains
both non-null issuer and issuerAltName extension, should
the latter take part in path construction, or not? It is clear from 
RFC3280 anf X.509 that in case certificate contains no isuuer
(null sequence), issuerAltName must be used instead for path building, 
but it is unclear what should be done if both are present and populated.

In other words, when RP tries to find an issuer for given certificate
containing both non-null issuer and issuerAltName extension, should
he/she check that not only issuer field in the certificate matches
subject field in issuer certificate, but also issuerAltName matches
subjectAltName in issuer certificate?

Or, should it be done only when issuerAltName is marked critical,
and RP is free to ignore issuerAltName completly when it is
marked non-critical?

Regards,
Valery Smyslov.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 14 Jul 2005 12:15:33 -0400

>and RP is free to ignore issuerAltName completly when it is
Valery,

Is the question about path construction or path validation?

For path construction, you are free to use whatever means you want to 
try to build a certification path.

For path validation, as I read X.509 and RFC 3280, the issuerAltName and 
subjectAltName should NEVER be used (except checking the subjectAltName 
against name constraints).

In X.509, perhaps the clearest language on this subject appears in the 
FPDAM Enhancements to Public-Key and Attribute Certificates 
(ftp://ftp.bull.com/pub/OSIdirectory/Orlando2004Output/6N12793CertificateEnhancementDAM.pdf):

            7 Public-keys and public-key certificates

    /Add the following at the beginning of the paragraph that currently
    begins with "A certification path logically
    forms an unbroken chain ..."/.

    The *issuer* and *subject* fields of each certificate are used, in
    part, to identify a valid path.  For each pair of adjacent
    certificates in a valid certification path, the value of the
    *subject* field in one certificate shall match the value of the
    *issuer* field in the subsequent certificate.  In addition, the
    value of the *issuer* field in the first certificate shall match the
    DN of the trust anchor.  Only the names in these fields are used
    when checking validity of a certification path.  Names in
    certificate extensions are not used for this purpose.

I could not find any text in the 4th edition of X.509 that is this 
clear, but the path validation algorithm in clause 10 simply imposes the 
requirement:

    a) Check that the signature verifies, that dates are valid, that the
    certificate subject and certificate issuer names chain correctly,
    and that the certificate has not been revoked.

I believe that this text was intended to mean that only the names in the 
issuer and subject fields are compared and not the names in the 
alternative name extensions.

In RFC 3280, comparisons of issuer and subject names in consecutive 
certificates is addressed in section 6 through the use of the 
working_issuer_name variable.   The working_issuer_name is defined as 
"the issuer distinguished name expected in the next certificate in the 
chain", it is set to the subject name from each certificate and compared 
against the issuer name in each certificate.  As with X.509, I read this 
language to mean that only the issuer and subject fields are compared 
and not the alternative names.

Dave

---

From: Tom Gindin <[email-masked]>
Date: Sat, 16 Jul 2005 10:30:07 -0400

Dave:

        I think it's simpler to point out that while RFC 3280 section 
4.1.2.6 permits the subject to be omitted ("The subject name MAY be 
carried in the subject field and/or the subjectAltName extension"), 
section 4.1.2.4 does not permit the issuer to be omitted ("The issuer 
field MUST contain a non-empty distinguished name (DN).").  Section 
4.1.2.6 also requires that the subject DN not be empty if the subject is 
either a CA or a CRL issuer.  X.509 section 8.3.2.2 does point in the 
opposite direction, allowing null issuer names if the issuer alternative 
name is critical.
        Thus, part of Valery's premise is not relevant for PKIX - the 
issuer name must not contain a null sequence.  It is relevant to X.509, 
though.  The text you cite is unambiguous, but I don't see anything which 
revoked the note to X.509 8.3.2.2 permitting null issuer DN's if the 
alternative name is critical, and for a CA (although not for a CRL) a null 
issuer name is worthless if you can't match it against the subject of the 
issuing certificate.  This could be cleaned up, in conformance to the 
apparent intent of the FPDAM, by restricting the note to 8.3.2.2 to CRL 
issuers.

                Tom Gindin

"David A. Cooper" <[email-masked]>
Sent by: [email-masked]
07/14/2005 12:15 PM
 
        To:     Valery Smyslov <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: issuerAltName and path construction

Valery Smyslov wrote: 
Hi,

 
Valery,

For path construction, you are free to use whatever means you want to try 
to build a certification path.

In X.509, perhaps the clearest language on this subject appears in the 
FPDAM Enhancements to Public-Key and Attribute Certificates (
ftp://ftp.bull.com/pub/OSIdirectory/Orlando2004Output/6N12793CertificateEnhancementDAM.pdf
):
7 Public-keys and public-key certificates
Add the following at the beginning of the paragraph that currently begins 
with ?A certification path logically
forms an unbroken chain ??.
The issuer and subject fields of each certificate are used, in part, to 
identify a valid path.  For each pair of adjacent certificates in a valid 
certification path, the value of the subject field in one certificate 
shall match the value of the issuer field in the subsequent certificate. 
In addition, the value of the issuer field in the first certificate shall 
match the DN of the trust anchor.  Only the names in these fields are used 
when checking validity of a certification path.  Names in certificate 
extensions are not used for this purpose.
I could not find any text in the 4th edition of X.509 that is this clear, 
but the path validation algorithm in clause 10 simply imposes the 
requirement:
a) Check that the signature verifies, that dates are valid, that the 
certificate subject and certificate issuer names chain correctly, and that 
the certificate has not been revoked.
I believe that this text was intended to mean that only the names in the 
issuer and subject fields are compared and not the names in the 
alternative name extensions.

In RFC 3280, comparisons of issuer and subject names in consecutive 
certificates is addressed in section 6 through the use of the 
working_issuer_name variable.   The working_issuer_name is defined as "the 
issuer distinguished name expected in the next certificate in the chain", 
it is set to the subject name from each certificate and compared against 
the issuer name in each certificate.  As with X.509, I read this language 
to mean that only the issuer and subject fields are compared and not the 
alternative names.

Dave