On Thu, Mar 21, 2013 at 06:55:04AM +0000, Viktor Dukhovni wrote: > On Wed, Mar 20, 2013 at 11:56:41PM -0400, Scott Schmit wrote: > > > > At the moment, I am not treating depth zero specially, so a trust > > > anchor's own certificate is accepted and in that case required to > > > match the MX domain or validated MX hostname. > > > > Ah yes, this issue spawned a lengthy discussion a little over a year > > ago. The discussion starts here: > > https://www.ietf.org/mail-archive/web/dane/current/msg03997.html > > > > The direct answer to your question might be this email here: > > https://www.ietf.org/mail-archive/web/dane/current/msg04196.html > > but it's hard to say if it does or not. Exactly how to handle the chain > > in a spec-compliant way depends on specifics of the server's > > certificate and the TA and your email doesn't really specify those > ^^^ > > details. > > My question is I guess more specifically about a certusage 2 TA (
(Cutting to the chase, using the cert you provided below, I think you can defend allowing it be used with cert usage 2, read further for details.) > 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: If the CA flag is set, some (most?) TLS software will reject it because it's not an EE cert. If the CA flag is not set, some PKIX software will reject it because it requires TAs to have the CA flag set. Some PKIX software will reject the certificate because the path length is 0. Others will not because they interpreted PKIX differently. In practice, it will probably work on most clients, but not all. So if you decide to accept it, you'll likely have a lot of company. That said, this widespread confusion about what the specs say will likely drive most people who aren't interested in establishing their own certificate hierarchy to usage 3 just to be sure it'll work everywhere. > I'm not looking to reopen old wounds, [...] As I recall the discussion from last time, it's more that this is a case that seems quite straightforward, but actually turns out to be a deep corner case of the various specs (despite being really widely used). The arguments end up being very technical & nit-picky & it just makes peoples' heads hurt. :-) > Should any of the DANE WG RFCs explicitly cover this ground, rather > than just defer to the rather dense 5280? These finer points of > PKIX are not obvious when one is obtaining TAs from a new source > that has its own claim to authenticity and an independent validity > interval via signed DNSSEC RRsets? ] AIUI, the PKIX WG owns the PKIX RFCs, so only they can issue updates, clarifications, etc. If the DANE WG were to try to do what you're asking, someone would inevitably think that our interpretation is inconsistent with PKIX (and thus not an interpretation), and it would get slapped down (if it didn't get slapped down out of general principal). IIRC, the reaction when we requested clarification on how self-signed certificates are handled by PKIX was that the PKIX WG feels the specs are already perfectly clear on the matter, if you read the definitions carefully. > - Does it matter whether the TLSA record is a "2 0 0" or > are we in the same boat with any "2 x y" describing the > same self-signed leaf CA/server. Somewhat -- if the TLS server omits the TA from its certificate chain but hashes it (or only provides a SPKI), and the client doesn't already know the TA certificate, then the client will have no way to match it. Diagnostics that this is why you aren't using that record might be useful, but I don't think there's any reason to hardcode "x & y aren't 0 & 0, so reject!" into your code. If the TA certificate is included in the TLS certificate chain or it's embedded in the client's TA store, it can work. > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 1 (0x1) > Signature Algorithm: ecdsa-with-SHA256 > Issuer: CN=mail.example.com > Validity > Not Before: Mar 21 06:21:45 2013 GMT > Not After : Mar 21 06:21:45 2014 GMT > Subject: CN=mail.example.com > Subject Public Key Info: > Public Key Algorithm: id-ecPublicKey > Public-Key: (256 bit) > pub: > 04:58:4a:6a:8a:42:d6:6a:d6:33:a5:27:95:3c:8b: > a0:54:e1:9d:df:b7:99:70:76:63:7e:48:e8:d0:54: > 1a:dd:f7:69:e4:13:1e:5e:b1:13:2e:66:c6:08:4c: > 34:23:e6:84:59:e9:ec:97:fd:9b:6e:ca:e4:76:91: > 37:38:8d:6e:e9 > ASN1 OID: secp256k1 > X509v3 extensions: > X509v3 Subject Alternative Name: > DNS:mail.example.com > Signature Algorithm: ecdsa-with-SHA256 > 30:44:02:20:56:c3:44:e0:10:67:f1:97:24:fc:e5:2a:fb:55: > 70:66:2c:ef:84:b6:57:7e:1d:bc:a7:1c:06:94:51:cf:7e:5c: > 02:20:64:95:f8:fa:74:d8:b3:c1:f5:1e:54:71:45:2a:a4:ab: > 89:23:6e:1a:f6:17:a2:22:f7:50:cd:00:bc:f5:3b:de Based on my understanding of PKIX, this should work (as long as your software supports ECDSA): Only the key & name matter on a TA, but other checks are a matter of local policy. 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. It's self-signed, so if I interpret the chain as mail.example.com (as TA) -> mail.example.com (as EE), then I have a path length of 1, and it's legal. (But that might depend on specifics of how path length is determined.) Depending on how you interepret the definition of the certificate chain in the TLS RFC, maybe we're supposed to transmit both certs in the chain (i.e., the same certificate twice). But I think if the client has the full certificate via TLSA, then the TA is "well-known" to that client and can be omitted from the chain. So I can't see any reason to reject this certificate, even being spec-pedantic. Does that help? -- Scott Schmit
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
