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
