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.
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?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
