On Aug 26, 2014, at 11:22 AM, Paul Wouters <[email protected]> wrote: > On Tue, 26 Aug 2014, Osterweil, Eric wrote: > >> Some time ago we had some discussions about draft-ietf-dane-smime, which led >> to >> https://www.ietf.org/mail-archive/web/dane/current/msg06338.html >> A few of us felt that it might be productive to outline a set of >> requirements that we foresee DANE facing in enterprises environments (w.r.t. >> encrypted/signed email). To that end, we put together the draft: >> ``Enterprise Requirements for Secure Email Key Management'' >> http://tools.ietf.org/html/draft-osterweil-dane-ent-email-reqs-00 > > I'm not an smime person at all and I'm a little confused about what the > document is trying to do. It talks about "key management requirements", > and then suggests specific requirements for a "protocol"? > > Which protocol? I would think this would be very much in the realm of > local policies. If something is missing in the smime-dane draft for > "enterprise deployment", does that mean the smime-dane draft itself is > incomplete? Could you send PaulH and Jakob text to ensure it can support > enterprise roll-out? If it is complete, then your document should only list > the > requirements on HOW to use it, instead of defining a new future protocol? > Noted - the requirements are for capabilities, so maybe "protocol" is a bad choice of words. This draft is to start to flesh out requirements and get the discussion going with the goal to improve the SMIMEA draft, or other drafts.
> > REQ-16 Encryption keys MUST be discoverable separately from > signature keys. Possible means includes (but not limited to) > naming conventions, sub-typing or unique RR types for each > use > > Intuition: Not all certificates for a user may be needed > for all circumstances. Fetching them separately can be a > management, a scaling, or even a security concern. > > This requirement for example is impossible with the current smime-dane draft? > And > sub-typing these days is frowned upon. > Just listing the options, even bad ones. :) The main reason for being able to differentiate between signing and encrypting keys is the size issue, but also reduce the risk of a client encrypting an email with a receiver's signing key by mistake. Enterprises may have the encrypting key stored at the receiving MTA, but not the signing key. Scott > I'm not sure how fetching the keys for encryption and signing separately > would be a security concern? That seems a little uhm, far fetched :) > If it is in public DNS, anyone can do it. If it is in private DNS, I'd > say it is already secured? > > Paul > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane =================================== Scott Rose NIST [email protected] +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
