a) not now (e.g. f), if both are headed to experimental. As you note there are ways to optimize if it turns out the type/rr conventions are the same. What would seem suboptimal at this time is to create the friction of forcing a converged approach until we fully understand the usage scenarios through experience.
b,c,d) were you only referring to the SMIME vs PGP policy? Or other potential secure email usage policies. A while back, in comments on the requirement draft, we suggested the ability to convey some expected usage policies WRT email security. These seemed important enablers to us in an enterprise environment. Not sure if you are referring to those sort of polices, or just SMIME vs PGP policies. f) Given that you posed the questions as a series of alternatives .... this is the real answer. We seem to have interested parties prototyping running code for various components of both solutions. Establish a realistic, but hard, deadline to evaluate the results of the experimental phase - making it clear that further spec work is envisioned on both approaches before adopting on a standards track. dougm On Mon, Jul 20, 2015 at 5:08 AM, Olafur Gudmundsson <[email protected]> wrote: > Dear Colleagues > > This note is to stimulate discussion, on higher level design of the these > two email protocol, > discussion on local-part “name” is a separate discussion. > > Right now we have two “active” email sign/encrypt technologies, proposing > to store “keying” information in DNS, > When we want to do a lookup we have two design dimensions, > — names > — types > > In the name space OPENPGP and SMIME are proposing two different > “zones”/names where keying info is stored this has certain advantages and > disadvantages. > Further more there have been proposals to have different “zones” for sign > and encrypt for SMIME. > > Pro: > - easy to see if organization "supports" technology > - if SMIME is operated by different group than PGP then there are no > organizational conflicts > > Con: > - To see if user X supports encrypted mail may require 2x lookups ( > i.e. in each Technology X all local part guesses) for organizations that > have users that use both PGP and SMIME > - more DNS data to maintain and sign. > > Antidode: If an organization has to support users with both types of keys, > it can publish both in one zone by using DNAME. > > In the type space we have OPENPGPKEY and SIMIMEA types proposed and the > idea is that the contnents of the records specify usage rules. > We can also do this via more types. > > We have seen arguments in the past ranging from “Lets ignore this” to “We > MUST support organizational realities including split views” > > Question: > a) do we want to merge the zones where EMAIL keying is stored ? > > or > b) Do we want to reflect policies in naming? > c) do we want to reflect polices in types > d) do we want to reflect policies inside records > > or > f) we can not answer this, experience will have to guide us. > > Think about how you want to answer these questions and lets have a short > discussion in the meeting on Monday but please start discussion on the > mailing list if you feel strongly about this > > Olafur & Warren > > PS: if you have a speaking slot in the meeting, now is a good time to send > in slides > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane > -- DougM at Work
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
