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@[email protected]
(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.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
