On Mar 27, 2013, at 11:19 AM, Scott Rose <[email protected]> wrote:
> I do think it might need a bit more besides just copying the TLSA RR format, > or at least a re-definition of the values since the two uses don't map > 1-to-1. The difference you have from TLSA is that the TLSA "certificate usage" field becomes the SMIMEA "key usage" field. In TLSA, certificate usage tells the receiving party how to use the certificate (as a trust anchor or end entity certificate); in your proposal, the key usage field is used to say if the certificate is a signing or encrypting certificate. This is probably a false dichotomy. Your proposal prevents people from using SMIMEA records for one of the most popular features in TLSA: specifying trust anchors. Further, your stated reason for wanting a key usage field seems unnecessary: > The idea of having a key usage field is so that those with two different > certs for digital signatures and encryption can have clients quickly > differentiate them. The key usage is contained in the certificate itself, either implicitly or because the key type can only be used for signing or encrypting. If someone has two different certs (which is likely to be common), there would simply be two SMIMEA records. Is there a strong advantage to having a new field that gives information that is already in the certificate? BTW, I agree with your suggestions about there being separate registries for the fields. There are definitely things that might be appropriate for TLS that are not appropriate for S/MIME, and vice versa. --Paul Hoffman _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
