Re: [dane] "Name Checks are not appropriate for CU=3"

[[e-mail] (Martin Rex)]

Viktor Dukhovni wrote:
> On Thu, Jan 16, 2014 at 11:45:56AM -0500, Stephen Kent wrote:
> 
> > Martin is correct. This is not well-formed cert as per RFC 5280:
> > 
> > 4.1.2.4.Issuer
> > The issuer field identifies the entity that has signed and issued the
> > certificate.The issuer field MUST contain a non-empty distinguished
> > name (DN)
> >
> > [...]
> >
> > We issued 5280bis in part to accommodate DANE's use of ss certs.
> > Please don't provide examples that are obviously non-complaint relative
> > to basic PKIX and X.509 specs.
> 
> Are you referring to RFC 6818?  If so, what is the impact of Section
> 2 of that document?
> 
>     2.  Update to RFC 5280, Section 3.2: "Certification Paths and Trust"
> 
>        Add the following paragraph to the end of RFC 5280, Section 3.2:
> 
>     | Consistent with Section 3.4.61 of X.509 (11/2008) [X.509], we note
>     | that use of self-issued certificates and self-signed certificates
>     | issued by entities other than CAs are outside the scope of this
>     | specification.  Thus, for example, a web server or client might
>     | generate a self-signed certificate to identify itself.  These
>     | certificates and how a relying party uses them to authenticate
>     | asserted identities are both outside the scope of RFC 5280.
> 
> If a self-signed EE (i.e. not a CA) certificate is outside the
> scope of 5280, it might seem that the issuer constraint of 5280
> need not apply.

I think you're misinterpreting this.

TLS typically comes with an software module for processing X.509
certificates that is (supposed to) follow either ITU-T X.509 or PKIX or both,
and TLS is going to be used for processing PKIX-conforming certificates
and certification pathes for quite some time to come.

The idea of DANE's use of X.509 was not to come up with a different
and incompatible interpretation of what and what not is a well-formed
X.509 certificate.  The intention (at least for some of those involved)
of DANE was to standardize a use of X.509 certificate and
certificate path validation for authentication of communication peers
as an alternative to what X.509/PKIX specifies.

Historically, how X.509 certificates that are issued by an entity
other than a CA are used by relying parties to authenticate peer
is outside of the scope of PKIX (rfc5280) essentially means, that
the exact behaviour is implementation-defined.

But when you start feeding X.509 certificates to a PKIX implementation
that are non-compliant with X.509/PKIX at the PDU level, rather than
differing only in the semantics of how to verify authenticity of
the certificate or cerification path), then you are squarely in
territory of undefined behaviour.


> 
> This does not mean that it is a good idea to push one's luck, but
> I am curious as to whether the 5280 constraints in this thread are
> or are not in scope for self-signed EE certificates?
> 
> It is perhaps the case that the question of whether a certificate
> is self-issued or not is not well-formed when both the issuer and
> subject fields are empty?


Doing stuff that is in obvious conflict with X.509 and/or PKIX is
almost unconditionally a bad idea, because it may require
modifying existing code to tolerate bogus information, which may
create/open new vulnerabilities and will result in interop problems.

There are a number of things that PKIX/rfc5280 has declared out-of-scope
(i.e. left to implementations, resulting in implementation-defined
behaviour).  One example is the presence and honoring of attributes
beyond the public key and the associated name(s) in so called
"trust anchors", in case trust anchors are distributed as X.509
certificates with attributes in them.  Some PKIX implementations will
honor (enforce) the notbefore/notafter of TrustAnchors, some may
ignore it.  Neither is PKIX-incompliant.

Your example populated the "notbefore" and "notafter" members with
conflicting values (i.e. notafter>notbefore).  This may needlessly
create a problem with implementations that check notbefore/notafter
even for trust anchors.


If you at your example with empty issuer from a programmers/API perspective
there are other potential problems.  X.509 has traditionally guaranteed
that an X.509 certificate can be (uniquely) identified by the pair
(issuer-name/serial number).  So some APIs that manage stores for certs
may be using issuer&serial as a handle to store or retrieve certs,
and the lack of an issuer name may represent an invalid function parameter
to such an API.


My recommendation is to avoid using obviously bogus examples of X.509
certificates when illustrating the use of DANE, because that is going
to cause unnecessary pain and confusion among users and implementors.


-Martin