Subject: [dane] draft-hoffman-dane-smime

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 10 May 2013 14:14:26 +0200

Hi!

This draft only talks about "Mail user agents" but as far as I see it it applies to SIP user agents as well.

One difference is that in a SIP uri, the username part is optional:

sip:[email-masked]
sip:conference.example.com

Are both valid URI's. But that doesn't seem to make much of a difference. The records would become:

MNUHE2LT._smimecert.example.com
_smimecert.conference.example.com

Would it make sense to incorporate SIP into this draft?

/O

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 May 2013 08:40:22 -0700

> This draft only talks about "Mail user agents" but as far as I see it it applies to SIP user agents as well.

Nope, it only applies to MUAs.

> sip:conference.example.com

Yes, exactly.

> Would it make sense to incorporate SIP into this draft?

I don't think so. It would be better to do that as a separate document with separate considerations for the SIP protocol.

--Paul Hoffman

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 10 May 2013 18:37:15 +0200

> I don't think so. It would be better to do that as a separate document with separate considerations for the SIP protocol.

Ok.

Can the "_smimecert" tag be used for this as well or should this be exclusive for S/MIME-Email?

/O

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 10 May 2013 17:41:21 +0000

> Can the "_smimecert" tag be used for this as well or should this be exclusive for S/MIME-Email?

XMPP could also benefit from something very much like this, forTLS mutual auth, E2E, etc.  From my reading, I think there are just enough semantic differences that _smimecert is probably not resuable for us, and I suspect the same is true for SIP.

However, the syntax is going to be nearly identical, so maybe we can find some common ground to build on?

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 10 May 2013 19:50:11 +0200

> However, the syntax is going to be nearly identical, so maybe we can find some common ground to build on?

Maybe the tag can be application agnostic, like _usernamesep

There's no real need that the name is depending upon the application, as we have a record type that indicates the app. 

/O

---

From: Carl Wallace <[email-masked]>
Date: Fri, 10 May 2013 13:59:07 -0400

On 5/10/13 1:50 PM, "Olle E. Johansson" <[email-masked]> wrote:

>>>>> This draft only talks about "Mail user agents" but as far as I see
>>>>>it it applies to SIP user agents as well.
>>>> 
>>>> I don't think so. It would be better to do that as a separate
>>>>document with separate considerations for the SIP protocol.
>>> 
>>> Ok.
>>> 
>> XMPP could also benefit from something very much like this, forTLS
>>mutual auth, E2E, etc.  From my reading, I think there are just enough
>>semantic differences that _smimecert is probably not resuable for us,
>>and I suspect the same is true for SIP.
>> 
>There's no real need that the name is depending upon the application, as
>we have a record type that indicates the app.
>

Seems like this could result in encrypting mail for the wrong certificate.
 The current spec should probably address the case where a user has one
certificate for signing and one for encrypting independent of whether the
spec supports multiple applications.  Noting the application must check
key usage/EKU is probably good enough.

>
>/O
>_______________________________________________
>dane mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dane

---

From: James Cloos <[email-masked]>
Date: Fri, 10 May 2013 16:42:33 -0400

>>>>> "OEJ" == Olle E Johansson <[email-masked]> writes:

OEJ> Maybe the tag can be application agnostic, like _usernamesep

OEJ> There's no real need that the name is depending upon the
OEJ> application, as we have a record type that indicates the app.

I suggested _at at some point in the past.  Short and apt.

But the newer idea of using webfinger seems more usable and reliable.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6