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

>
>10 maj 2013 kl. 19:41 skrev "Matt Miller (mamille2)" <[email protected]>:
>
>> 
>> On May 10, 2013, at 10:37 AM, Olle E. Johansson <[email protected]> wrote:
>> 
>>> 
>>> 10 maj 2013 kl. 17:40 skrev Paul Hoffman <[email protected]>:
>>> 
>>>> On May 10, 2013, at 5:14 AM, Olle E. Johansson <[email protected]> wrote:
>>>> 
>>>>> 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.
>>>> 
>>>>> One difference is that in a SIP uri, the username part is optional:
>>>>> 
>>>>> sip:[email protected]
>>>>> sip:conference.example.com
>>>> 
>>>> Yes, exactly.
>>>> 
>>>>> 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?
>>>> 
>>>> 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?
>> 
>> 
>> 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?
>> 
>
>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.
>

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 protected]
>https://www.ietf.org/mailman/listinfo/dane


_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane

Reply via email to