On Sat, Mar 14, 2015 at 1:23 PM, Paul Hoffman wrote:
> On Mar 13, 2015, at 7:09 PM, Paul Wouters wrote:
> >> My comments on draft-ietf-dane-openpgpkey-02:
> >> 1) Section 3, in case of EAI, it should specify the character encoding
> of
> >> the local-part on which to perform the SHA224 function.
>> 1) Section 3, in case of EAI, it should specify the character encoding of
>> the local-part on which to perform the SHA224 function.
Paul H is right. Regular mail addresses are 7-bit ASCII, and EAI is
UTF-8. Those are the only two choices, and since ASCII is a subset of
UTF-8, it's really onl
On Mar 13, 2015, at 7:09 PM, Paul Wouters wrote:
>> My comments on draft-ietf-dane-openpgpkey-02:
>> 1) Section 3, in case of EAI, it should specify the character encoding of
>> the local-part on which to perform the SHA224 function.
>
> That's a valid point. Should we say that it should be UTF-8
Wil Tan wrote:
(added the dane list in my reply)
Thanks for your review Wil.
My comments on draft-ietf-dane-openpgpkey-02:
1) Section 3, in case of EAI, it should specify the character encoding of
the local-part on which to perform the SHA224 function.
That's a valid point. Should we say th
> "JL" == John Levine writes:
JL> ._mailbox.domain
I posted in the past that smime and openpgp should use the same _name
(search the archives for '_at'). I gave up when it got zero traction.
It also would be a good place to look for TLSA RRs for certs supplied
by tls clients which have
In article <20150313223350.eac992b55...@rock.dv.isc.org> you write:
>
>Why are we arguing about this? We can support both seperate zones
>and combined zones. Just use "_openpgpkey DNAME _mailbox" if you
>want to collape the number of zones.
That would certainly work, but if there isn't actually a
Why are we arguing about this? We can support both seperate zones
and combined zones. Just use "_openpgpkey DNAME _mailbox" if you
want to collape the number of zones.
Mark
In message <20150313221955.GB3479@localhost>, Nico Williams writes:
> On Fri, Mar 13, 2015 at 06:23:34PM -, John Levin
On Fri, Mar 13, 2015 at 06:23:34PM -, John Levine wrote:
> I see that in dane-openpgpkey, the name on the record is
>
> ._openpgpkey.domain
>
> and in dane-smime, the name is:
>
> ._smimecert.domain
>
> These are two different names for the same mailbox. Since they use
> the sa
On Fri, Mar 13, 2015 at 1:54 PM, John Levine wrote:
>
> I'm trying to imagine a situation where one security admin assigns PGP
> keys, a different one assigns S/MIME keys for the same users, and they
> hate each other so much that they need to use separate DNS
> provisioning systems.
You obviou
> On the other hand, if
>the WG thinks that the security admin will be the one adding and changing
>records for
>a particular type of mail security, then the design we are using now is better.
I'm trying to imagine a situation where one security admin assigns PGP
keys, a different one assigns S/M
But we've gotten along with A and MX records at the same name for 30 years.
But A and MX records live within the same zone, whereas _openpgpkey.tld
currently is its own zone. It is a nice and clean separation.
It sounds like you are you saying that every new RR type should come with
a prefix,
On Fri, 13 Mar 2015, John R Levine wrote:
I can see how two different sysadmins administer the _openpgpkey and
the _smimecert zones possibly even running on different nameservers.
Like the smime one on Microsoft and the openpgp one on Linux.
But we've gotten along with A and MX records at the
Forgot to CC the list on my reply to John. (Sorry for the duplicate, John.)
There are some problems that can only be solved by adding a level of
indirection.
However, in the reverse direction (removing a level of indirection), this
can be done trivially: DNAME.
I.e. for those places where putti
> On Mar 13, 2015, at 11:23 AM, John Levine wrote:
>
> I see that in dane-openpgpkey, the name on the record is
>
> ._openpgpkey.domain
>
> and in dane-smime, the name is:
>
> ._smimecert.domain
>
> These are two different names for the same mailbox. Since they use
> the same ha
I can see how two different sysadmins administer the _openpgpkey and
the _smimecert zones possibly even running on different nameservers.
Like the smime one on Microsoft and the openpgp one on Linux.
But we've gotten along with A and MX records at the same name for 30
years. By this logic, eve
On Fri, 13 Mar 2015, John Levine wrote:
future RRs that use hashed mailboxes to use the same name?
._mailbox.domain
I expect we will end up with conventional kludges to deal with the
reality that systems treat mailbox names as case independent, e.g.,
publish the hash of the name as n
I see that in dane-openpgpkey, the name on the record is
._openpgpkey.domain
and in dane-smime, the name is:
._smimecert.domain
These are two different names for the same mailbox. Since they use
the same hash, wouldn't it be a better idea for both of them and any
future RRs tha
On Fri, 13 Mar 2015, Pieter Lexis wrote:
Thanks for the review Pieter,
I'm very much on the "Yes, this is good"-side of things.
3.1:
The MAY in the last sentence is much too weak. We can’t have
interoperability without some stronger rules. Suggest moving this whole
section into -usage or menti
In the PMTA draft I offered the same locator approach as SMIMEA, however
also mention that that is one of many possible means for locating the
record. It is not hard to image use cases in which a recipient would
want to expose multiple payment associations that don't necessarily
correspond to
John,
In the PMTA draft I offered the same locator approach as SMIMEA, however also
mention that that is one of many possible means for locating the record. It is
not hard to image use cases in which a recipient would want to expose multiple
payment associations that don't necessarily correspo
Warren,
Thanks for taking the time to offer so much supporting detail behind your
analysis.
Regarding nefarious domain operators
You have identified a very real risk that we all face when we leverage a domain
over which we have no real control. I trust google to not impersonate me with
my pe
I took a quick look at the eastlake draft from 2001 and although I wasn't
watching those discussions here are my observations:
- This was prior to the supporting work of DNSSEC and DANE which provide an
established trust anchor and chain of trust. This looks as though it was an
idea before its
Hi folks,
I've read this draft (and not my d...@iets.org backlog, so dead horses
may be beaten) and have some comments on it.
On 10/28/2014 12:36 AM, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item o
Hi all,
Late to the party, but here are some nits/things on
draft-ietf-dane-openpgpkey-02. I have not read my huge backlog of the
DANE mailinglist, so please correct me if I'm beating a dead horse.
Nearly all issues I have are mentioned in
draft-ietf-dane-openpgpkey-usage-01.
On 03/09/2015 04:43
24 matches
Mail list logo
