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?
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.
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
