Re: [stir] URN SOS

Robert Sparks <rjsparks@nostrum.com> Wed, 29 January 2020 20:01 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AB6120969 for <stir@ietfa.amsl.com>; Wed, 29 Jan 2020 12:01:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joDTVtl7Go-k for <stir@ietfa.amsl.com>; Wed, 29 Jan 2020 12:01:06 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECEDA12087A for <stir@ietf.org>; Wed, 29 Jan 2020 12:00:25 -0800 (PST)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 00TK09re034723 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 29 Jan 2020 14:00:10 -0600 (CST) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1580328011; bh=nAy/mUWs+h7xBMZmIKJdwAWlwjWwNLT5Eya18HxtK8c=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=qfevTY3of1M1UXzLOBNw+VXpC0hcYOxIBUXQw+AN3Iww12FJpMkU0tD+ZXixHTOAA mX9fSyhA/34BhIPLZJQOwWyAyy3BxkzAIhnbhRRDkLlONz8uUoxtYuxZ/bQrH9DH1q kEKL97CWgxmRA9osR37X7BqS7/rBemcjPePgt2V0=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "DOLLY, MARTIN C" <md3135@att.com>
Cc: "stir@ietf.org" <stir@ietf.org>
References: <EF51940D-F3B7-4F4E-9AA4-CFE76B75194D@vigilsec.com> <CAL02cgQdow3HsWe-EH-UQU-5bwegyjxsEA+DLRp6TcyrZtLLLg@mail.gmail.com> <00593B03-11CE-4364-97AF-79B53881FCF6@vigilsec.com> <CACG=0wRwcf543PSJqoMRZVx29w3XwXT2_vzTsbKjFb3vxVL_bg@mail.gmail.com> <13e7729e-38e4-9e6e-5c66-1c8b680ee7d0@alum.mit.edu> <22C9E60D-45A4-4DA1-A78D-0720BE8B90AE@att.com> <d8914f8c-5250-2afb-2782-dd7bb8021ab3@alum.mit.edu>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <31a8d160-1315-f11d-366f-9fc4ee1cb7a8@nostrum.com>
Date: Wed, 29 Jan 2020 14:00:08 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <d8914f8c-5250-2afb-2782-dd7bb8021ab3@alum.mit.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/NBauq20xPOewbVURoYnjurWKWQ4>
Subject: Re: [stir] URN SOS
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2020 20:01:16 -0000

Just to make sure this part of the thread is addressed:

The context was a discussion about allowing calls that used an SOS URI 
as the call destination (the To: header field value) to be covered by 
STIR. The concern was raised on whether STIR supports that at the 
moment.  There was concern that the discussion of identities in RFC8225, 
constrained the use of 'uri' to really only mean SIP urls. Discussion 
started, and should continue here about whether that's correct, and if 
so, what changes would need to be made.

I don't think anyone intended to propose a _new_ URI. I think 
speaking/typing quickly introduced that confusion, and I believe we're 
past that.

My own opinion is that 8224/8225 don't constrain the use of 'uri' in a 
way that prevents putting the sos urn in the dest, and that the most we 
need to do is think about the consequences of doing so (to look for 
unexpected rough edges), and possibly provide some information guidance 
on their use.

RjS

> On 12/23/19 11:51 AM, DOLLY, MARTIN C wrote:
>> Paul
>>
>> That is what was discussed in the meeting
>
> If it is to be discussed on this list, then can some of the context be 
> brought here to the list as well?
>
>     Thanks,
>     Paul
>
>> Regards
>>
>> Martin C. Dolly
>>
>> Lead Member of Technical Staff
>>
>> Government & Services Standards
>>
>> AT&T
>>
>> Cell: +1.609.903.3360 <tel:+1.609.903.3360>
>>
>> Email: md3135@att.com <mailto:md3135@att.com>
>>
>>
>> On Dec 23, 2019, at 10:09 AM, Paul Kyzivat <pkyzivat@alum.mit.edu 
>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>
>>> On 12/23/19 9:02 AM, Anders Kristensen wrote:
>>>> May have to do with the fact that RFC 8224 does not cover URNs:
>>>
>>> If the problem is that URNs aren't covered, then how would replacing 
>>> urn:service:sos with urn:sos solve the problem???
>>>
>>> The use of urn:service:sos is institutionalized now in a lot of 
>>> documents. Changing that seems like a hard problem. How about fixing 
>>> RFC 8224?
>>>
>>>    Thanks,
>>>    Paul
>>>
>>>>    1 
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf..org_html_rfc8224-23section-2D1&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=VQ2OV0oQ5RymRKh71MqRjUjZoVwk433iXVncEctnZLU&e= 
>>>> >. Introduction
>>>>    This document provides enhancements to the existing mechanisms for
>>>>    authenticated identity management in the Session Initiation 
>>>> Protocol
>>>>    (SIP) [RFC3261 
>>>>  <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3261&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=BGjbtQQGGuj4m4lgJ-bpTO2NmEkBs6vCssCmUena32c&e= 
>>>> >].  An identity, for the purposes of this document, is
>>>>    defined as either
>>>>    o  a canonical address-of-record (AoR) SIP URI employed to reach a
>>>>       user (such as "sip:alice@atlanta.example.com 
>>>>  <mailto:sip%3Aalice@atlanta.example.com>") or
>>>>    o  a telephone number, which commonly appears either in a tel URI
>>>>       [RFC3966 
>>>>  <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3966&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=dHRjXLr5_Y_dbtfZ8PvYXJTxJNDbByiejlPvh89HYLU&e= 
>>>> >] or as the user portion of a SIP URI.
>>>> On Sun, Dec 22, 2019 at 1:14 PM Russ Housley <housley@vigilsec.com 
>>>> <mailto:housley@vigilsec.com> <mailto:housley@vigilsec.com>> wrote:
>>>>    Richard:
>>>>    It seems to meet the need that was raised in the discussion.  
>>>> Others
>>>>    can comment if I missed some important context.
>>>>    Russ
>>>>>    On Dec 22, 2019, at 3:38 PM, Richard Barnes <rlb@ipv.sx 
>>>>> <mailto:rlb@ipv.sx>
>>>>>    <mailto:rlb@ipv.sx>> wrote:
>>>>>
>>>>>    Not sure if this is what you’re thinking of, or if this has
>>>>>    already been mentioned, but: urn:service:sos exists.
>>>>>
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5031&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=YFxpwD-sFZG8qj0YD1Q3dYHCnMgjeMIRRHjMWcakYeI&e= 
>>>>>
>>>>>
>>>>>    On Sat, Dec 21, 2019 at 17:26 Russ Housley 
>>>>> <housley@vigilsec.com <mailto:housley@vigilsec.com>
>>>>>    <mailto:housley@vigilsec.com>> wrote:
>>>>>
>>>>>        At the session at IETF 106, there was a suggestion that a URN
>>>>>        SOS be defined.  I am sending this note to start a discussion
>>>>>        on that topic.
>>>>>
>>>>>        Russ
>>>>>        _______________________________________________
>>>>>        stir mailing list
>>>>> stir@ietf.org <mailto:stir@ietf.org> <mailto:stir@ietf.org>
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= 
>>>>>
>>>>>    _______________________________________________
>>>>>    stir mailing list
>>>>> stir@ietf.org <mailto:stir@ietf.org> <mailto:stir@ietf.org>
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= 
>>>>>
>>>>    _______________________________________________
>>>>    stir mailing list
>>>> stir@ietf.org <mailto:stir@ietf.org> <mailto:stir@ietf.org>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= 
>>>> _______________________________________________
>>>> stir mailing list
>>>> stir@ietf.org <mailto:stir@ietf.org>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= 
>>>>
>>>
>>> _______________________________________________
>>> stir mailing list
>>> stir@ietf.org <mailto:stir@ietf.org>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=LlWDlfhDO4Vkx9MdBi1k_YjkLmARgGgAlH6FjS6mDmc&s=AzNKVu9D7KOUqyaaebb1l-WkXrq-sBd4hBOP1NZESsU&e= 
>>>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir