On Thu, Mar 21, 2013 at 10:06:57AM -0400, Scott Schmit wrote:
[ Quoting your last paragraph first: ]
> So I can't see any reason to reject this certificate, even being
> spec-pedantic.
>
> Does that help?
Yes, thanks, I think I can largely go with what I have, what remains
to verify is the first part of the side question from my original post:
[ I guess I should also ask whether the expiration dates of
non-degenerate TA certificates matter with "IN TLSA 2 x y"
resource records. At the moment I don't accept expired TA certs. ]
So, with certificate usage 2, should I allow "expired" TA certs at
depth > 0? If the TA is to be viewed as just a public-key in X.509
garb, and in view of the fact that the expiration times are set by
some entity I may not trust (trust starts at the TA), perhaps not?
On the other hand if the TA is actually self-signed, then its own
statement about expiration times could be taken at face value (as
OpenSSL does with self-signed trust anchors in its trust store).
Bottom line, should I allow expired TA certs, and does it matter
whether they are self-signed.
> > which is hypothetically also the server certificate, so the "and"
> > above is a conjunction of two references to the same thing).
>
> Right, but certificate processing/TLS code will treat different cases of
> that differently, depending on how they interpreted the PKIX & TLS
> specs. And there *is* more than one case of that:
Checking the OpenSSL x509_vfy.c source I find that:
- The expiration time of a self-signed issuer certificates (at any
depth including 0) is *not* ignored. So with a typical trust chain
starting at a public root CA, the root CA's expiration time is
honoured.
- OpenSSL ignores the "CA:true" vs. "CA:false" for depth 0 self-signed
certificates. I'll go along with that.
> If the CA flag is set, some (most?) TLS software will reject it because
> it's not an EE cert.
FWIW, OpenSSL (which Postfix uses for TLS+X509 support) does not care
at the leaf.
> It's an EE certificate, because there's no basic constraint saying that
> this is a CA (and the certificate is X.509v3), so it's legal for a
> server named mail.example.com to use as its certifiate in TLS.
I'm going to let OpenSSL ignore the CA bit for me. That way I
don't have to parse the X509 cert myself in the verification
callback. And name checks will still apply.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
