A few of us were chatting after the meeting and I suspect that the 64
octet limit for a label is going to create a problem with using split
base32. It sounds as though we would end up limiting the LHS to 40
octets before the encoding.
On 7/20/15, 12:12 PM, "Peter van Dijk" wrote:
>Hello,
>
>O
> "VD" == Viktor Dukhovni writes:
VD> Mnemonic value notwithstanding, the main advantage of _at is that
VD> that it is *short*.
Yes, short was one of the motivations.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
___
dane mailing lis
> On Jul 20, 2015, at 12:42 PM, Viktor Dukhovni wrote:
>
> On Mon, Jul 20, 2015 at 04:39:49PM +, Osterweil, Eric wrote:
>
>> Another point: the chances that a zone may already want to use "_at"
>> for some other reasons (and thus causing a collision) are higher than the
>> more descriptive
> "WG" == Wiley, Glen writes:
>> Mapping @ to _at makes it easy to remember and easy to read.
WG> Does it make sense to add encoding for the @ since the hashes are
WG> unreadable?
Putting f(local-part) into the dns w/o some sort of separator label may
increase the size of ANY requests for t
On Mon, Jul 20, 2015 at 04:39:49PM +, Osterweil, Eric wrote:
> Another point: the chances that a zone may already want to use "_at"
> for some other reasons (and thus causing a collision) are higher than the
> more descriptive "_openpgpkey," or "_smimecert" labels.
There's no "collision". Th
> On Jul 20, 2015, at 11:32 AM, Viktor Dukhovni wrote:
>
> On Mon, Jul 20, 2015 at 03:17:17PM +, Wiley, Glen wrote:
>
>> After reading your response it occurs to me that James was suggesting
>> adding _at as a label rather than encoding it in the hash - makes
>> more sense.
>
> Specificall
Hello,
On 20 Jul 2015, at 12:29, Paul Wouters wrote:
On Mon, 20 Jul 2015, Wiley, Glen wrote:
Has there been any recent discussion about using a non-hashed LHS
encoding? I don¹t think there has so we probably don¹t want to
bring
that question into scope here.
There was some interested by
On Mon, Jul 20, 2015 at 03:17:17PM +, Wiley, Glen wrote:
> After reading your response it occurs to me that James was suggesting
> adding _at as a label rather than encoding it in the hash - makes
> more sense.
Specifically:
._at.example.com. IN SMIMEA 3 0 0
._at.example.com. IN OP
After reading your response it occurs to me that James was suggesting
adding _at as a label rather than encoding it in the hash - makes
more sense.
Having said that, I still question whether _at really helps much since
humans aren¹t likely to read/write the encoded user name. Even if we
decide t
On Mon, Jul 20, 2015 at 10:41:08AM -0400, James Cloos wrote:
> They should be at the same place even though multiple lookups are likely
> to be required anyway -- not everything will fully support an ANY query.
>
> And I renew my (previously ignored) suggestion that they, along with
> tlsa record
On 7/20/15, 10:41 AM, "James Cloos" wrote:
>They should be at the same place even though multiple lookups are likely
>to be required anyway -- not everything will fully support an ANY query.
I like the idea of using a consistent encoding for anything that uses a
locator
constructed forma user n
They should be at the same place even though multiple lookups are likely
to be required anyway -- not everything will fully support an ANY query.
And I renew my (previously ignored) suggestion that they, along with
tlsa records for client certs where the cn or other lookup -- such as
a sip url or
I have carefully read the draft-ietf-dane-smime-08 draft as well and have
found no problems with it and find it clear and concise.
Being better at engineering than reading+writing, I implemented the draft
in the form of on-line record generator and outlook email translator and it
works.
Thanks to
On Mon, 20 Jul 2015, Wiley, Glen wrote:
Which they'll also learn by just looking at the zone data, if the
localparts are not hashed in the final spec.
Has there been any recent discussion about using a non-hashed LHS
encoding? I don¹t think there has so we probably don¹t want to bring
that qu
On Mon, 20 Jul 2015, Olafur Gudmundsson wrote:
- In addition to matching the approach of OPENPGPKEY on the LHS, it would
make sense for this draft to match the other draft's language on the subject of
response length.
I’d like to see the SMIME draft adopt the Security Consideratio
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
th
On Mon, Jul 20, 2015 at 11:23 AM, Olafur Gudmundsson wrote:
>
> On Jul 19, 2015, at 7:01 AM, Mankin, Allison wrote:
>
> I’ve done a careful read of draft-ietf-dane-smime-08. I find it to be in
> very good shape, and on track for publication as an Experimental.
>
>
> Thank you for this review, m
> On Jul 19, 2015, at 7:01 AM, Mankin, Allison wrote:
>
> I’ve done a careful read of draft-ietf-dane-smime-08. I find it to be in
> very good shape, and on track for publication as an Experimental.
>
Thank you for this review, much appreciated, as chair I encourage others to
take few minut
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 wan
On 7/19/15, 10:57 AM, "Viktor Dukhovni" wrote:
>On Sun, Jul 19, 2015 at 01:52:53PM +, Rose, Scott wrote:
>
>> First, if the _smimecert. is hosted by a service provider (i.e.
>> not the domain owner), the service provider can see who may be receiving
>> encrypted mail.
>
>Which they'll also l
20 matches
Mail list logo
