On Mon, Oct 20, 2014 at 03:24:07PM +0000, Osterweil, Eric wrote:
> For example, a single DANE TA could be used to authorized all of an
> organization?s S/MIME users, and selective ``user-no-longer-valid'' (i.e.
> revocation) entries could override this.
The preferred way to "revoke" a DANE-TA(2) binding for a single
end-entity is to publish a DANE-EE(3) binding for that entity until
the previously issued certificate has expired.
Where normally one would have:
_smimea._dane.example.com. 1H IN SMIMEA 2 0 1 {blob}
<entity1-smimea-label>.example.com. 1H IN CNAME
_smimea._dane.example.com.
<entity2-smimea-label>.example.com. 1H IN CNAME
_smimea._dane.example.com.
....
<entity100000-smimea-label>.example.com. 1H IN CNAME
_smimea._dane.example.com.
When the keys for entity42 are compromised, you publish:
<entity42-smimea-label>.example.com. 1H IN SMIME 3 1 1 {blob}
(or perhaps "3 0 0" instead of "3 1 1" if that's more appropriate
for SMIME). Once the compromised certificate has expired back to:
<entity42-smimea-label>.example.com. 1H IN CNAME
_smimea._dane.example.com.
This is fine for validating sender presented chains. When looking
for a recipient key to encrypt to, an end-entity binding is
unavoidable.
> I think we are all on the same page, and perhaps the text was not clear
> enough? Maybe it's also possible there was some misunderstanding from
> the protracted email discussion? The revocation discussion (IIRC) really
> had to do with an assertion that TLS did not have revocation needs.
My view is that revocation is not terribly useful without accurate
signalling of when something was revoked, and whether the revocation
applies to content validated prior to the revocation. Just publishing
a binary "revoked" bit in DNS would I think be a mistake (do more
harm than good).
With SMIME used so little, there has been little investment in
figuring out how to do revocation correctly. Reasoning by analogy
with interactive protocols encrypting data in motion is deeply
flawed when applied to data at rest.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
