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

[Viktor Dukhovni <[e-mail]>]

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.

* REQ-6 seems to be substantially the same as 5.

* REQ-7 is I think too concise.  What is it about?

* REQ-8 feels wrong.  It is turtles all the way down,
  the merging enterprise's applications may be using some other
  protocol.  The protocol cannot encompass all competing protocols.
  Applications may need to support multiple protocols, and perhaps
  a meta protocol (obligatory xkcd reference anyone) could be used
  to signal which one to apply to which user.  However it may simply
  be better for a new protocol to keep things simple and aim to
  displace rather than entrench legacy options.

* I don't understand REQ-10.

* Is REQ-11 confusing application implementing the protocol with the
  protocol?  If not what is it saying?

* REQ-12 is definitely an application and not a protocol requirement.

* REQ-13 seems to be reprise of REQ-5/6.

* REQ-15 feels like a derived "requirement" from some other unstated
  assumptions.  What is its real purpose?  The words "authenticated
  denial of existence" are I think unfortunate in this context,
  since they have a very specific meaning in DNSSEC, which likely
  differs from the intention here.

* I see no discussion of case sensitivity.  For example, a domain
  in which addresses are case insensitive could publish records
  (at a suitably encoded label) associated with a case-tagged email
  "address" that is not valid 5322 syntax:

	lowercase@[e-mail]

	(as distinct from "lowercase@joeuser"@example.com, and
	 I would expect the quotes in quoted localparts to be
	 part of the input to the encoded address).

  Then applications that don't find a match for the user supplied
  case could try the above variant instead, and not run into
  collisions at domains where addresses are case-sensitive, because
  such domains would not publish data for such prefixes.

  With a bit of cleverness we can handle case sensitivity without
  imposing on the freedom of the destination domain to be case
  sensitive or not.

* Should there be some discussion of EAI?  Are UTF-8 localparts
  also subject to attempts at case conversion?  Any other EAI
  issues?

-- 
	Viktor.