Viktor,
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.
The wording here was a carefully crafted compromise to deal with the
reality of ss certs vs. the X.509 and 5280 rejection of them. You could
interpret the text to say that anything goes, but violating the basic
format requirements of 5280 and its predecessors) and X.509 strikes me
as a bad mashup.
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?
Self-issued is not the same same self signed, although the fine
distinction is probably not worth the list's attention.
Steve
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
