[ I am hoping everyone is taking a bit of time to think through the agility
issue. We do however need to get it resolved one way or other, so if
possible please post concluding comments today or early next week. ]
I believe we have reached consensus on DANE-EE(3) end-entity X.509
cert verification:
- No name checks based on certificate content (TLSA base domain sufficient)
- No expiration checks based on certificate content (DNSSEC sufficient)
It is time to consider the issues for DANE-TA(2). The first issue
is:
With records of the form:
_25.mx.example.com. TLSA DANE-TA(2) <selector> <some-digest-alg> {blob}
where the matching type is really a digest, not Full(0), we've
observed that the server operator had better include the matching
certificate in his TLS handshake certificate (chain) message,
because the verifying client can't match a digest against a
certificate it does not have.
What do we want to say about:
_25.mx.example.com. TLSA DANE-TA(2) SPKI(1) Full(0) {DER-encoded key}
In this case the client still typically has no corresponding
certificate in hand, and so, if the server does not provide a
matching certificate in the TLS handshake, the client cannot
"compare" the TLSA record with the server's chain.
However, if the server's chain starts with a certificate signed
with the trust anchor key in question (obtained from the TLSA
record), the client can in principle verify the chain.
The Postfix SMTP client in fact does exactly this, uses any "IN
TLSA 2 1 0" trust anchor keys to verify "signed-by" even when the
server does not present a corresponding TA issuing certificate in
his chain.
So the question is:
- Are clients expected to do this? In other words can servers
expect to be able to elide TA certs from their chains when
the TA key is in a "2 1 0" TLSA record?
- If clients are not expected to do this, there is little point
in "IN TLSA 2 1 0", with the key also inside a certificate in
the server's chain, it makes a lot more sense to publish
"IN TLSA 2 1 X" for some suitable set of digests X.
A related question is whether with "DANE-TA(2) Cert(0) Full(0)",
there is again a practical need to duplicate the certificate in
the server's chain "for matching", or whether this time the server
really can avoid duplication, because the client has the cert in
hand.
Note: The OPS draft discourages "Full(0)" due to potential issues
with DNS payload bloat, but these are nevertheless valid, and it
would be good to settle on the semantics.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
