On Sep 29, 2014, at 5:26 AM, Osterweil, Eric <[email protected]> wrote:
> Based on our implementation experience we would like to suggest that the > following text (taken from Scott Rose's email: > http://www.ietf.org/mail-archive/web/dane/current/msg06180.html ) be > incorporated into the current version of the draft-ietf-dane-smime document. > We are sending text (below), but at a high-level, the text outlines a few > useful additions: > > 1 - Usage #4 (reject) is likely to be very important. This could either > emphasize the difference between saying, ``don't use this cert for this > operation,'' and ``this cert is universally revoked'' or be used to > selectively override an organization-wide TA for certain employees that have > left the organization. > > 2 - The certificate access field (Section 2.1.4) would enable alternate > discovery mechanisms that could help aid incremental deployment and > transition schemes. For example, while cutting over to a DANE solution, some > enterprises may want to transition users from (say) AD to DANE, and this > field would enable that. > > 3 - The ``_encr'' and ``_sign'' labels are excellent additions to the > management of zone sizes and lookup sizes. Rather than querying for all keys > and then locally selecting from them, I (as an RP) likely already know which > of these I want, and I should be able to look them up separately in DANE (and > owners should be able to manage them separately in DANE). > > If anyone objects, please let us know. Jakob and I think that the three additions are unneeded here, and make the draft diverge quite far from the TLSA format without significant value. In specific: 1) This usage type is at least as applicable to TLS as it is to S/MIME. We haven't seen anything indicating much use of certificate revocation anywhere and, where we have seen it, it is much more common in TLS. If the authors really want this feature, it should be an update to TLSA, which SMIMEA could then adopt. 2) Making the record format for SMIMEA different than that of TLSA for this feature seems like a bad idea. Alternate discovery mechanisms might be important, but they will be just as important for TLS as they are for S/MIME. The functionality that the authors want could be added to TLSA by adding new Matching Type fields such as "Hash and NAPTR", "Hash and URI", and so on. The latter is part of IKEv2 (although the feature is generally considered not useful). If the authors really want this feature, it should be an update to TLSA, which SMIMEA could then adopt. 3) There is absolutely no indication that zone size or response size is important to SMIMEA, certainly not relative to the added complexity for clients, servers, and operators. Currently, the RSA certs for SMIME from common CAs are for both signing and encrypting, so this added complexity won't buy current users anything. In the future when we are all (hopefully) using elliptic curve keys, the zone size and response size will be so much smaller than they are now that this change will appear as an over-optimization that adds complexity. When these ideas were brought to the WG earlier this year, we didn't hear any significant support. Given that both of us feel that the proposed changes make the document harder to implement, we would want to see much wider support before we adopt them. --Paul Hoffman and Jakob Schlyter
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
