Re: [dane] Fwd: New Version Notification for draft-osterweil-dane-ent-email-reqs-01.txt

[Doug Montgomery <[e-mail]>]

On Tue, Nov 25, 2014 at 8:04 PM, Viktor Dukhovni <[e-mail]>
wrote:

> On Wed, Nov 26, 2014 at 12:07:06AM +0000, Rose, Scott wrote:
>
> > We submitted a new version of the email-reqs draft.  This version is
> likely not perfect, but I wanted it to appear before the US Thanksgiving
> holiday so people have a chance to look at it before the interim meeting.
> >
> > Text and requirements are cleaned up a bit and added example use cases
> for non-trivial requirements.  Also added a new section of requirements
> that are not really DANE relevant, but added for completeness and just to
> have them documented somewhere.  A new DANE type is probably not the ideal
> solution for all of these requirements.
> >
> > Comments welcome, now or during/after the interim meeting,
>
> * REQ-2 seems to suggest DNAME in a context where I would generally
>   expect CNAME (linking one leaf record to another).  DNAMEs would
>   far more likely be used when all users have addresses in each of
>   two or more equivalent domains.
>
> * I think REQ-5 is a leap from the underlying desire of constraining
>   credentials to specific uses.  It states that it must be possible
>   to convey negative assertions (don't use key K for purpose P'),
>   while it may be quite sufficient to use positive assertions,
>   which have better security semantics (use K for purpose P), and
>   anything not asserted is by definition not valid.
>
>   Thus the requirement ought to be implementation neutral, and whether
>   it is implemented in positive or negative terms is an implementation
>   choice not a requirement.
>

There are two issues that need to be addressed here.

1. Some enterprise identity management systems bind encryption and signing
keys to network identities for other purposes (i.e., not specific to
email).   The requirement addressed the ability for domains to indicate
that even though you might know of such keys through other means, they are
not valid for end-to-end SMIME usage in this domain.

2. The semantics during incremental deployment, and persistent partial
deployment must be well defined.   i.e., one must be able to definitively
determine if the lack of a positive assertion is a purposeful statement of
key usage policy, or a transient condition of partial deployment.

It was not apparent to us how the absence of positive assertions could
address these requirements.

dougm
-- 
DougM at Work