Subject: Clarifications on SubjectAltNameExtension handling in RFC3280 / X509

From: "Julien Stern" <[email-masked]>
Date: Wed, 23 Aug 2006 14:38:40 +0200

Folks,

Sorry to bother if the topic is very familiar to some of you,
but I failed to find definitive answers in the RFCs or in X.509.

I'd be quite interested to have some clarifications regarding
the handling of entity names in RFC3280 (or sonof) and X.509.

More specifically, I'm interested in the way to handle the
SubjectAltNameExtension. This extension allows to give several
alternative names to an entity.

When RFC3280/X509 talk about the "same" entity, does this mean
i) The same certificate
ii) Two certificates with the same SubjectDN
iii) Two certificates with the same SubjectDN and the same
     SubjectAltNameExtension
iv) Two certificates with at least one identifier in
    SubjectDN/SubjectAltNameExtension that match
v) Something else

Also, do RFC3280 and X.509 really have the same semantic on that matter? 
Is RFC3280 putting additional constraints (Trust Anchors?) on the match?

Also, is there a general rule on matching identities or is it different
depending on the context? Some more specific questions on that matter:

* Is it allowed to have a DN in the SubjectDN field AND a different
DN in SubjectAltNameExtension? If so, should we check both for name
equality?

* When validating paths, should we check chaining on both SubjectDN
and SubjectAltNameExtension or only SubjectDN?

* When both SubjectDN are empty, how do we chain certificates?
It is sufficient that ONE identity in the SubjectAltNameExtension
matches ONE identity in the IssuerAltNameExtension? Or should ALL
identities match?

* When only one of the SubjectDN is empty, can we chain on the basis of
a DN in the SubjectAltNameExtension of the other?

* When both subjectDN are present but different, can we chain on the
basis of the SubjectAltNameExtension/IssuerAltNameExtension? Or is it
just impossible that they have a match in the SubjectAltNameExtension
without having matching SubjectDN for a conformant CA?

* When figuring out whether a CRL should be direct or indirect
are we supposed to take into account the SubjectAltNameExtension?
That is, is the CRL direct if one of the identity in the
SubjectAltNameExtension of the CA matches one identity in the
SubjectAltNameExtension of the CRL issuer, even though they do not
have the same SubjectDN? Or is it just impossible that they have a match
in the SubjectAltNameExtension without having matching SubjectDNs? What
if one of the SubjectDN is empty? Or both?

* Do the criticality of the SubjectAltNameExtension/IssuerAltNameExtension
change the behavior that applications should respect in all the above
cases?

Thank you very much for any insight.

--
Julien

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 23 Aug 2006 11:24:09 -0400

Julien,

See responses in-line.

Dave

>     SubjectDN/SubjectAltNameExtension that match
The term "entity" refers to a person or object.  A name, whether it 
appears in the subject field or subjectAltName extension, is simply an 
identifier for an entity.  Here is what X.509 says in clause 8.3.2.1 
(Subject alternative name extension):

    For every name form used in the GeneralName type, there shall be a 
name registration
    system that ensures that any name used unambiguously identifies one 
entity to both
    certificate issuer and certificate users.

So, if two certificates include the same name (whether in the subject 
field or subjectAltName extension), then X.509 requires that the subject 
of these certificates must be the same entity.
> Is RFC3280 putting additional constraints (Trust Anchors?) on the match?
There is no difference between RFC 3280 and X.509 on this matter.  
3280bis does impose the constraint that a certification path and the 
path used to validate a CRL that provides status information for a 
certificate in the path begin with the same trust anchor.  This rule was 
included in 3280bis to protect against the risk that two different 
entities might issue certificates and/or CRLs under the same name.  This 
would be a violation of both 3280bis and X.509, since it would violate 
the rule that any name within a PKI unambiguously identity one entity, 
but there is no way (other than by vigilance) to ensure that it won't 
happen.  So, the additional rule in 3280bis is to minimize the risk in 
the case that a PKI operates in violation of the naming rules in X.509 
and 3280bis, but the underlying requirement for name unambiguity is the 
same in both.
> depending on the context?
>   
I believe that X.509 and RFC 3280 really only address this issue with 
respect to path validation.  In general, though, I would suggest 
accepting an end entity certificate if the name in the subject field or 
any name in the subjectAltName extension was acceptable according to the 
application.
> Some more specific questions on that matter:
>
A certificate may have a DN in both places.  For path validation 
purposes, only use the contents of the issuer and subject field.
> and SubjectAltNameExtension or only SubjectDN?
Only the subject DN.
> matches ONE identity in the IssuerAltNameExtension? Or should ALL
Technically, if the subject DN is empty and the issuer DN in the 
subsequent certificate is empty, then the names chain.  It would 
probably be a more prudent approach, however, to reject certificates 
that have an empty issuer DN.
> a DN in the SubjectAltNameExtension of the other?
No.
> without having matching SubjectDN for a conformant CA?
No.  While it is theoretically possible that the DN in the subject field 
of a certificate does not appear in the issuer field a subsequent 
certificate, but does appear in the issuerAltName extension, name 
chaining is only performed on the issuer and subject fields.
> if one of the SubjectDN is empty? Or both?
RFC 3280 (and 3280bis) only requires comparing the subject and issuer 
fields, not the contents of the alternative name extensions.  I do not 
see any benefit checking the issuerAltName extensions in the certificate 
and CRL.
> change the behavior that applications should respect in all the above
I don't think so.  Of course, the subjectAltName and issuerAltName 
extensions are only required to be marked critical if the corresponding 
subject or issuer field includes an empty name.  Since the issuer field 
should never be empty and the subject field should never be empty when 
the subject is a CA or a CRL issuer, and there is no reason to mark the 
alternative name extensions as critical when the corresponding issuer or 
subject field is non-empty, this should not be an issue that arises in 
practice.

---

From: "Julien Stern" <[email-masked]>
Date: Wed, 23 Aug 2006 18:25:40 +0200

David,

many thanks for your prompt and clear replies.

A few more question are in-line.

Regards,

--
Julien

On Wed, Aug 23, 2006 at 11:24:09AM -0400, David A. Cooper wrote:
> [snipped crystal clear explanation on entity names]

> and 3280bis, but the underlying requirement for name unambiguity is the 

OK. Found. Point 6.3.3 (f) of 3280bis.

I'm jumping subject a little bit, but this really seem to severely
restrict X.509 on two points:

- Section 8.1.5, last paragraph where it is explicitely mentionned
that an entity can choose to have two different trust anchors for
Certificate and CRL signing

- All the indirect CRL framework (not necessarily as they could
  still chain, but likely)

Wouldn't it be better to only ask that they chain up to Trust Anchors
that have the same name instead?

> [snipped questions on chaining]

> see any benefit checking the issuerAltName extensions in the certificate 

Well, I wondered about this point because of the wording of X.509:

B.5.1.4

If the cRLIssuer field is present in the relative extension (CRL
distribution point or freshest CRL extension) of the certificate, the
CRL shall be signed by the CRL Issuer identified in the CRL distribution
point extension or freshest CRL extension of the certificate and the CRL
shall contain the indirectCRL field in the issuing distribution point
extension.

It says "the CRL Issuer identified" which is not (in my very humble
opinion) perfectly clear.

RFC3280bis says:

6.3.3

(1) If the DP includes cRLIssuer, then verify that the issuer field in
the complete CRL matches cRLIssuer in the DP and that the complete CRL
contains an issuing distribution point extension with the indirectCRL
boolean asserted. Otherwise, verify that the CRL issuer matches the
certificate issuer.

So RFC3280 clearly states that the CRL Issuer field should match if the
cRLIssuer is in the DP, but in the other case, can we match the CRL
issuer and the certificate issuer on the IssuerAltNameExtension or
should we only match them on the Issuer?

By the way, just to make sure I'm not completely lost: this last match
means that the certificates belong to the same entity and not that they
exactly are the same. Right?

> [snipped question on criticality]

To summarize:

1) When we chain, we only consider SubjectDN and IssuerDN. Period.
2) in RFC3280 (and son), a SubjectDN of a non-EE cannot be empty,
   therefore, a IssuerDN can never be empty

3) So, The only remaining issue I have is: whenever the RFC says
that we should have a match between two issuers, does this mean that
they should have the same SubjectDN or can/should we also check the
SubjectAltNameExtension ?

Like in these three snippets from 3280bis:

-----
5.2.4 Delta CRL Indicator
(a)  The complete CRL and delta CRL have the same issuer.

-----
6.3.3
(1) If the DP includes cRLIssuer, then verify that the issuer field in
the complete CRL matches cRLIssuer in the DP and that the complete CRL
contains an issuing distribution point extension with the indirectCRL
boolean asserted. Otherwise, verify that the CRL issuer matches the
certificate issuer.

-----
6.3.3
(c)  If use-deltas is set, verify the issuer and scope of the
     delta CRL as follows:

     (1)  Verify that the delta CRL issuer matches complete CRL
     issuer.