From nobody Sat Oct 1 23:20:53 2016 Return-Path: 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 6281912B044 for ; Sat, 1 Oct 2016 23:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no 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 y9qeQORrb-O7 for ; Sat, 1 Oct 2016 23:20:49 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D622012B023 for ; Sat, 1 Oct 2016 23:20:48 -0700 (PDT) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-01v.sys.comcast.net with SMTP id qa8jb3OUgucHZqa8mbW6eg; Sun, 02 Oct 2016 06:20:48 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by resomta-po-13v.sys.comcast.net with SMTP id qa8jbZOP50Hwuqa8kbKyUs; Sun, 02 Oct 2016 06:20:48 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Sat, 1 Oct 2016 23:01:50 -0700 From: Alex Bobotek To: Henning Schulzrinne , "stir@ietf.org" Date: Sat, 1 Oct 2016 23:01:50 -0700 Thread-Topic: FYI only: Two new VoIP spam drafts Thread-Index: AQHSG4AHdXDxA/hrj06MJ4pEMbL5u6CUpQ4g Message-ID: <4B1956260CD29F4A9622F00322FE053101290E491F5A@BOBO1A.bobotek.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4B1956260CD29F4A9622F00322FE053101290E491F5ABOBO1Abobot_" MIME-Version: 1.0 X-CMAE-Envelope: MS4wfGZmJLDR1kqo++EB1WWugOhMHrsBF1cqYcx4f9y5l0aGwqdIC7o4uu7QoyR5n78xfoQUD5i8ZSjaHpJ3386/UvPYRlnr/INAXIqS2BkrA8fZjTRirJoF vJmuVjFQu0EF047+UCG479gMu06xJ5hIJPzBG3/SNJY5zZLPL9djTR9bqQRkZzGGGH3woQ5ewE+cOcofLx4hxrcUw6Pn1YPmBV0= Archived-At: Subject: Re: [stir] FYI only: Two new VoIP spam drafts X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2016 06:20:52 -0000 --_000_4B1956260CD29F4A9622F00322FE053101290E491F5ABOBO1Abobot_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's good to see the docs. I'm very pleased to see the facilitation of end= -user feedback, information crucial to abuse mitigation. Comments on draft-schulzrinne-dispatch-status-unwanted: 1. The status code could, conceivably, be returned by automata or by = human-triggered action (e.g., user click on the 'report spam' button). Con= sider whether the status code could reflect action by someone or something = other than the typically-human called party and at points before the termin= ating device. IMHO, it should permit such indications from automata as wel= l as human-initiated actions. 2. The recommendation that the response code not be used in creating = call filters unless the call has been authenticated via 4474bis is too stro= ng. There are many cases where I want such non-authenticated information t= o be used to filter my calls. Just about everybody using the more popular = call blocking solutions available today benefit from blacklisting based on = feedback of unauthenticated caller IDs, and this practice should not be ter= minated capriciously. Additionally, 4474bis is only one of many methods of= auth and may instead be more of a statement of service provider originati= on than of calling address authority or authentication. I suggest toning t= his down to a statement that the possibility of spoofing or unauthorized us= e should be taken into consideration in constructing call filters. 3. The draft should include normative text that specifies when a SIP = entity MAY/SHOULD/SHALL return the status code. It only specifies what a r= ecipient of the code MAY do. For example, add to section 4: "A SIP entity MAY reply to a SIP request with the 'Unwanted' response code = if there is a user-initiated or other indication that the request is unwant= ed. " 4. Consider allowing SIP entities handling the response to substitute= a different code in any forwarded responses. A called party may not wish = to convey rejection as unwanted all the way back to the calling party. I d= on't know the right answer, and I hope others' opinions will be expressed. = There are times when a message instructing a caller to 'place me on your o= rganization's DNC' is desired, and times when a more silent approach is pre= ferred. 5. The introductory paragraph discusses the need to express that a ca= ll is unwanted. Section 3 discusses the need to indicate that a caller's c= alls are unwanted. These are different assertions. The most basic assert= ion is 'this call is unwanted'. Perhaps an additional 'no calls from that = address are wanted' assertion should also be supported. Regards, Alex From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, September 30, 2016 6:08 PM To: stir@ietf.org Subject: [stir] FYI only: Two new VoIP spam drafts [Please address comments to the DISPATCH list; this copy is FYI only since = I forgot to bcc the list.] In collaboration with members of the Robocall Strike Force (https://www.fcc= .gov/news-events/events/2016/08/first-meeting-industry-led-robocall-strike-= force), I have submitted two I-D's: https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-status-unwanted= / https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-callinfo-spam/ that fill in operational needs for dealing with SIP spam. The first defines= a new status code (666) that users can use to mark unwanted calls, either = as a response code to an INVITE or in a Reason header in a BYE response. (T= his will likely be supplemented in practice by API-based mechanisms for pos= t-call spam reports.) The second defines a set of Call-Info parameters that allow the carrier or = other UE-trusted SIP entity in the path to indicate the spam probability, t= ype of call and other related information that will allow the UE and user t= o make better call handling decisions. This complements the 'verstat' work being submitted to 3GPP (by others), fo= r indicating the level of trust in the From/PAI tel URI. Henning --_000_4B1956260CD29F4A9622F00322FE053101290E491F5ABOBO1Abobot_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It’s = good to see the docs.  I’m very pleased to see the facilitation = of end-user feedback, information crucial to abuse mitigation.  <= /o:p>

 

Comments on draft-schulzrinne-dispatch-status-unwanted= :

 

1.       = The status code could, conceivably, be = returned by automata or by human-triggered action (e.g., user click on the = ‘report spam’ button).  Consider whether the status code c= ould reflect action by someone or something other than the typically-human = called party and at points before the terminating device.  IMHO, it sh= ould permit such indications from automata as well as human-initiated actio= ns.

2.  &= nbsp;    The recommendat= ion that the response code not be used in creating call filters unless the = call has been authenticated via 4474bis is too strong.  There are many= cases where I want such non-authenticated information to be used to filter= my calls.  Just about everybody using the more popular call blocking = solutions available today benefit from blacklisting based on feedback of un= authenticated caller IDs, and this practice should not be terminated capric= iously.  Additionally, 4474bis is only one of many methods of auth and= may instead be more of  a statement of service provider origination t= han of calling address authority or authentication.  I suggest toning = this down to a statement that the possibility of spoofing or unauthorized u= se should be taken into consideration in constructing call filters.  <= o:p>

3.   =     The draft should inc= lude normative text that specifies when a SIP entity MAY/SHOULD/SHALL retur= n the status code.  It only specifies what a recipient of the code MAY= do.  For example, add to section 4:

“A SIP entity MAY re= ply to a SIP request with the ‘Unwanted’ response code if there= is a user-initiated or other indication that the request is unwanted. R= 20;

4.  &n= bsp;    Consider allowin= g SIP entities handling the response to substitute a different code in any = forwarded responses.  A called party may not wish to convey rejection = as unwanted all the way back to the calling party.  I don’t know= the right answer, and I hope others’ opinions will be expressed.&nbs= p; There are times when a message instructing a caller to ‘place me o= n your organization’s DNC’ is desired, and times when a more si= lent approach is preferred.

5.       The introductory paragraph discusses the need to express that a ca= ll is unwanted.  Section 3 discusses the need to indicate that a calle= r’s calls are unwanted.   These are different assertions.&n= bsp; The most basic assertion is ‘this call is unwanted’. = Perhaps an additional ‘no calls from that address are wanted’ = assertion should also be supported. 

 

&= nbsp;

Regards,<= /p>

 

Alex

From:= stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzri= nne
Sent: Friday, September 30, 2016 6:08 PM
To: stir@i= etf.org
Subject: [stir] FYI only: Two new VoIP spam drafts

 

[Please address comments to the DISPATCH list; this copy is F= YI only since I forgot to bcc the list.]

 =

In coll= aboration with members of the Robocall Strike Force (https://www.fcc.gov/news-even= ts/events/2016/08/first-meeting-industry-led-robocall-strike-force), I = have submitted two I-D's:

 

https://datatracker.ietf.org/doc/draft-schulzr= inne-dispatch-status-unwanted/

https://datatracker.ietf.org/doc/draft-schulzrinne-dispatc= h-callinfo-spam/

 

that fill in operational = needs for dealing with SIP spam. The first defines a new status code (666) = that users can use to mark unwanted calls, either as a response code to an = INVITE or in a Reason header in a BYE response. (This will likely be supple= mented in practice by API-based mechanisms for post-call spam reports.)

 

The second defines a set of Call-Info parameters th= at allow the carrier or other UE-trusted SIP entity in the path to indicate= the spam probability, type of call and other related information that will= allow the UE and user to make better call handling decisions.

 

This complements the 'verstat' work being submitted to 3GPP = (by others), for indicating the level of trust in the From/PAI tel URI.

 

Henning

<= span style=3D'font-family:"Calibri",sans-serif;color:black'> 

= --_000_4B1956260CD29F4A9622F00322FE053101290E491F5ABOBO1Abobot_-- From nobody Sun Oct 2 04:17:10 2016 Return-Path: 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 93A2D12B012 for ; Sun, 2 Oct 2016 04:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cZQTqTLVbU1R for ; Sun, 2 Oct 2016 04:17:06 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 990891288B8 for ; Sun, 2 Oct 2016 04:17:06 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id f193so8577280wmg.0 for ; Sun, 02 Oct 2016 04:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=5mbIpJdjiERHrS8oKoTnosOlX0RJ2mX5wBu5gw9lQVM=; b=ELBM/lYtdU6YzRJq2YxQ1PmbHkZkHaWY5sPHL7YjzuvK4JHZcSogsQV36QJLhgzTOf pFpaX9bBdVrUVbkJvxo3gBNONCxxp/SVnb4wmWbtezKHgKGHNq7i343XA9BSfz+dRBob V+qc99ZII1JTItWtWr0cSRV+gYVsldQmqtOnbPnekd1TesbFC7SNj27lgIY0okf+W7qI dE+XuWJN4/pQyrykuVDr5Ht7qws5Zh8lY+UQ1mtaKzm7iukqTxPgSotRW7Y91QZq04yk ODZ1BGTDPl6zgWoaK44ce4FlrDBzwInwVoGP/rPjhyvPMgsPG3DKeKF+xkmbjJlW2ckn 0/Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=5mbIpJdjiERHrS8oKoTnosOlX0RJ2mX5wBu5gw9lQVM=; b=kOKUJM5ZyFDJdwuzXZl52Mc5aGIPmYK+L8+OmyK7+Ohm+fo6siC0kRPP26tlK6knXr XlKRgqaXvFckilORfkIzyza1IQMI3KU5sNqJ61mrg6GQgbNv3pl8pYN6ie/B12MEKSdL kETHKlpvidtzldjSDBvrt5yLkA+F2sfz4qPArAyMenGvw19U2VQVf733Ox6HKBsFwGiz owWJJ3IdQrxGU35tIYBqJGFMebD6EvmH1ptY0InR+EL8+6xeNFZTYjBMr6ibwjiSTlvt Q5NZhzVvubucQiBb1TfITmeWA60nlDOqYCmR58NEIoqHZMmZIhjJQpIaPUFqxxIAngFL +jkA== X-Gm-Message-State: AA6/9Rmo+pJarCRTHuPRnYJvrSZPQAnVLNa2Zx5OGAVABn4XfrdnorhY1dspizExp091lQ== X-Received: by 10.28.50.3 with SMTP id y3mr4908895wmy.23.1475407022743; Sun, 02 Oct 2016 04:17:02 -0700 (PDT) Received: from alans-mbp.lan (80.61.112.87.dyn.plus.net. [87.112.61.80]) by smtp.gmail.com with ESMTPSA id x124sm13532848wmf.22.2016.10.02.04.17.02 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 02 Oct 2016 04:17:02 -0700 (PDT) From: Alan Ford Content-Type: multipart/alternative; boundary="Apple-Mail=_50E56BAE-A4C1-40AE-B16B-0247DC8190ED" Message-Id: Date: Sun, 2 Oct 2016 12:17:58 +0100 To: stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2016 11:17:08 -0000 --Apple-Mail=_50E56BAE-A4C1-40AE-B16B-0247DC8190ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, In general this clarifies a number of the issues raised, and I feel the = use of the compact/full distinction is much clearer for current and = future implementors than =E2=80=9Ccanon". However, there is still opportunity for providing guidance of when to = use each form, to avoid interop issues further down the line. In particular, in Section 6.1, it says: An authentication service MAY use the full form of the PASSporT in the Identity header field. The presence of the full form is OPTIONAL because the information carried in the baseline PASSporT object's headers and claims is usually redundant with information already carried elsewhere in the SIP request. Using the compact form can significantly reduce SIP message size, especially when the PASSporT object contains media keys. The syntax of the compact form is given in [I-D.ietf-stir-passport = ] Section 6 = ; = essentially, it contains a base64 encoding of the JSON header and payload in the PASSporT object. Firstly, "essentially, it contains a base64 encoding of the JSON header = and payload in the PASSporT object=E2=80=9D surely is a typo? The = compact form contains a base64 encoding of the signature? This text also does not clarify why you would want to use the full form = when not using optional extensions. The point I have been making in = earlier mails, and which I feel would be valuable to add to the = document, is something along the lines of =E2=80=9CIf, however, a sender = does not know how a receiver may canonicalise the source or destination = addresses, for example if it does not know whether tn, uri, or both = would be used, then it SHOULD include the full form.=E2=80=9D. (Section = 8 makes comments along these lines but not as explicitly). Also, in Section 6.2.3, it talks about using the full form to help with = canonicalisation of orig: As an optimization, when the full form is present, the verification service MAY compute its own canonicalization of an originating telephone number and compare it to the values in the "orig" element of PASSporT before performing any cryptographic functions in order to ascertain whether or not the two ends agree on the canonical number form. I think it would be helpful to also point out it helps with the = canonicalisation of dest, by adding a sentence such as: =E2=80=9CSimilarly, the presence of the full form allows the receiver to = see how the sender canonicalised the destination address(es), such as = whether it was canonicalised to a tn, a uri, or both, and so this can = help the receiver know how to canonicalise the headers and thus verify = the claims.=E2=80=9D Regards, Alan --Apple-Mail=_50E56BAE-A4C1-40AE-B16B-0247DC8190ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

In = general this clarifies a number of the issues raised, and I feel the use = of the compact/full distinction is much clearer for current and future = implementors than =E2=80=9Ccanon".

However, there is still opportunity for = providing guidance of when to use each form, to avoid interop issues = further down the line.

In particular, in Section 6.1, it says:

   An authentication service MAY use the =
full form of the PASSporT in
   the Identity header field.  The presence of the full form is OPTIONAL
   because the information carried in the baseline PASSporT object's
   headers and claims is usually redundant with information already
   carried elsewhere in the SIP request.  Using the compact form can
   significantly reduce SIP message size, especially when the PASSporT
   object contains media keys.  The syntax of the compact form is given
   in [I-D.ietf-stir-passport] Section 6; essentially, it contains a
   base64 encoding of the JSON header and payload in the PASSporT
   object.

Firstly, "essentially, it contains a base64 encoding of the = JSON header and payload in the PASSporT object=E2=80=9D surely is a = typo? The compact form contains a base64 encoding of the signature?

This text also does not clarify why you = would want to use the full form when not using optional extensions. The = point I have been making in earlier mails, and which I feel would be = valuable to add to the document, is something along the lines of =E2=80=9C= If, however, a sender does not know how a receiver may canonicalise the = source or destination addresses, for example if it does not know whether = tn, uri, or both would be used, then it SHOULD include the full = form.=E2=80=9D. (Section 8 makes comments along these lines but not as = explicitly).

Also, in Section 6.2.3, it talks about using the full form to = help with canonicalisation of orig:

   As an optimization, when the full =
form is present, the verification
   service MAY compute its own canonicalization of an originating
   telephone number and compare it to the values in the "orig" element
   of PASSporT before performing any cryptographic functions in order to
   ascertain whether or not the two ends agree on the canonical number
   form.

I= think it would be helpful to also point out it helps with the = canonicalisation of dest, by adding a sentence such as:

=E2=80=9CSimilarly, the = presence of the full form allows the receiver to see how the sender = canonicalised the destination address(es), such as whether it was = canonicalised to a tn, a uri, or both, and so this can help the receiver = know how to canonicalise the headers and thus verify the = claims.=E2=80=9D

Regards,
Alan

= --Apple-Mail=_50E56BAE-A4C1-40AE-B16B-0247DC8190ED-- From nobody Sun Oct 2 16:25:32 2016 Return-Path: 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 7E2E312B0EE for ; Sun, 2 Oct 2016 16:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 2s5v6fvku95x for ; Sun, 2 Oct 2016 16:25:29 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 8AFD4127A91 for ; Sun, 2 Oct 2016 16:25:29 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id f193so77567510wmg.0 for ; Sun, 02 Oct 2016 16:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=+hGpKP6xseJJAb8FS6GOgUuidu9fKQr1NsBOTmaIrd0=; b=llmgmbHpInnaRck869v4CWf98H3OXEkTgNA29dEZO2An74CN6nghTd3V/EU/JfNz7L uFB3nC3SCSwqJ9E0C0xudgwNWHbxEhEudUGSQJzuU83t6Pn2vWOT4N65+A13dvZ4LI0k c5/B2ddVkVevSPaW5SlUBPcF7dnBOMvYpoPycPfGHdlza2s+nM+50+ooldpWpfL/gHDO YeissDvHnfMhYlCFp/Cdinjyq3Hgo4lUlCPxKsW9gkdLOxmvSWauYW2SaHnmV/04llC9 /Ub/wyXbFEbQ0WcC7PFob23pHUv2haUdet+9b7vkVNrh5GI6AvqdbXsnzuhm3P43eV8t Rn3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+hGpKP6xseJJAb8FS6GOgUuidu9fKQr1NsBOTmaIrd0=; b=PBI5FXAFAMs9cb2m6PqNN174USKfge6thIe+OZ9lyYbRsX2kGRdR+jr8GX4Qdwf2ti nDfUFA5GbYAfNAtqrEnOjwlQHx8zwWfRmck51rd7I3dOTIBwAN/XWj/z3FIYPiA0I80H a8l2RgZLafJuQ/zx5rtgN+FMpEWVKMjkUtY1LV7nfrPKr7Bx7JZ+pbPJbF+NJh1CJfVT XmzdoHka1yjoc38hjXfw5ZBvkkzujhAXYJ3USlxTxpYj6z4l5aHtWQUqUiU2RdpllyXA v/S5s2YGHamHPvQRFVL0r0ocNOuTESP/DaHi/zOaZ46zg9NallMffEimzgl7nXRjY/+z 72Sg== X-Gm-Message-State: AA6/9RmLWZeu81uYr4e3bRf+2GzPs43wI0vcsTu687h+3y3oB+SSy1rrsIk2fODxtjVYYKdSha+GskO+Qw0UtMlw X-Received: by 10.28.91.11 with SMTP id p11mr5925713wmb.98.1475450727621; Sun, 02 Oct 2016 16:25:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.67 with HTTP; Sun, 2 Oct 2016 16:25:26 -0700 (PDT) From: Anders Kristensen Date: Sun, 2 Oct 2016 16:25:26 -0700 Message-ID: To: stir@ietf.org Content-Type: multipart/alternative; boundary=001a11497e1e81492d053dea2494 Archived-At: Subject: [stir] Comments on draft-ietf-stir-certificates-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2016 23:25:31 -0000 --001a11497e1e81492d053dea2494 Content-Type: text/plain; charset=UTF-8 * 3: s/SubjectAltName/subjectAltName/ - for consistency if nothing else. * 3: The first approach is to use subjectAltName and the second is to use the TN Auth List defined in this doc. If one wanted to use SPID then presumably the right way to do it would be to use the TN Auth List but the text here talks about using SPID in subjectAltName. Probably shouldn't be encouraged. * 4: o See Section 7 for requirements related to the TN Query certificate extension. Was this meant to refer to TNAuthorizationList rather than TNQuery? * 7: My preference would be to not list support for SIP as mandatory for info URIs. Using SUBSCRIBE/NOTIFY feels contrived and unnecessary. * 7: OTOH using data: might make sense. Avoids cid: issue with non-multipart support. * 7: Re caching of certs, the doc could mention that a best practice is for the server to never modify resources identified by info URIs, e.g. use cert serial number rather than subjectAltName in the URI. * 8: So TNAuthorizationList is List>. Why can't it just be List? * 8: I'm not sure if ServiceProviderIdentifierList is supposed to contain SPID, Alt SPID and Last Alt SPID in that order. For example, if a cert contains a TNEntry with a spid of length 2 then those two entries would be expected to match SPID and Alt SPID of the calling number respectively? * 9: s/all/call/ * 9.2: ISTM that if OCSP is always used to check freshness of TN auth lists then the actual content of the list is irrelevant. The authority check has just been delegated to the CA... * 9.2: I guess OCSP is not really for the SPID case? If so, maybe mention. * 9.3: s/list of TNs/calling number/ ? --001a11497e1e81492d053dea2494 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
* 3: s/Subjec= tAltName/subjectAltName/ - for consistency if nothing else.

* 3: The first approach is to use subjec= tAltName and the second is to use the TN Auth List defined in this doc. If = one wanted to use SPID then presumably the right way to do it would be to u= se the TN Auth List but the text here talks about using SPID in subjectAltN= ame. Probably shouldn't be encouraged.

* 4:
   o  See Section 7 for requirements related to the TN=
 Query certificate
      extension.

Wa= s this meant to refer to TNAuthorizationList rather than TNQuery?

* 7: My preference would be to not= list support for SIP as mandatory for info URIs. Using SUBSCRIBE/NOTIFY fe= els contrived and unnecessary.

* 7: OTOH using data: might make sense. Avoids cid: issue with non-mu= ltipart support.

* 7: Re = caching of certs, the doc could mention that a best practice is for the ser= ver to never modify resources identified by info URIs, e.g. use cert serial= number rather than subjectAltName in the URI.

* 8: So TNAuthorizationList is List<List<TNEntr= y>>. Why can't it just be List<TNEntry>?

* 8: I'm not sure if ServiceProviderIde= ntifierList is supposed to contain SPID, Alt SPID and Last Alt SPID in that= order. For example, if a cert contains a TNEntry with a spid of length 2 t= hen those two entries would be expected to match SPID and Alt SPID of the c= alling number respectively?

* 9: s/all/call/

* 9.2= : ISTM that if OCSP is always used to check freshness of TN auth lists then= the actual content of the list is irrelevant. The authority check has just= been delegated to the CA...

* 9.2: I guess OCSP is not really for the SPID case? If so, maybe menti= on.

<= div class=3D"gmail_default" style=3D"font-size:small">* 9.3: s/list of TNs/= calling number/ ?

--001a11497e1e81492d053dea2494-- From nobody Sun Oct 2 16:25:49 2016 Return-Path: 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 1D319127A91 for ; Sun, 2 Oct 2016 16:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 nKSQORSKJ5JY for ; Sun, 2 Oct 2016 16:25:47 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 0D7C512B10E for ; Sun, 2 Oct 2016 16:25:45 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id p138so120732149wmb.1 for ; Sun, 02 Oct 2016 16:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Q9mwokFI9EQZzlhPR3FBJ2QcpTblqxuj5gqhcAffToA=; b=AlI87unUd8XiKkwgd24bfyXlFeiIpt32hVtbC/RYNcrBo60menp8IVL+aaqe4Ktp6W yDMGLN+qKb4q67I1FWx8MOVdYzk2hHWHCBI8Zog/WUqovK7aSTAmDE75zF13nLL02FWG AsmNL2WD8pHz98vw1y2Ht8nIn7LuIJ2XKFwwxOXl4ANSEcEhAZlzi0C4WG8+XTGEe6Ls 0uB2WKp940qE/4WmbsumP13uB+Yu120ftXfqf2WnzZp7YKA4Ogv5Z6ZVBKUG8MvGLr8I cUNQM9TpgIDCETIPufwd2bF4S0WL8sVquqjGqqIu/mLyTtzFYU1nfCNHRc1BSz+O5rnN Hr5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Q9mwokFI9EQZzlhPR3FBJ2QcpTblqxuj5gqhcAffToA=; b=f9XCkskRV1/WBjVE7WucyiP5BG4xUBG1LtWEXyKxu4re7fuBifG4VKjNEZ2NdSQw1F 8z+VKe3/8UX4xFEfVrPYXEp53pTv8nbIGORETT420u0z/aI3Bbfk7i1bYQRXl+wyQTdg +1dYBrQ/bdJpbL0qXm6soc0lTmiTkkO8wP7OKCwB7aERGn62kME81pH9HzZ1FVJnJsHe ITaUT3zo2vKm4C3ThGSBodJld15lVNZKN+uZqSYAurv77ZPV+xv0sWIEy2rGs67Q/biP H9d15cMiP2E91hscZ15fjpgvALFuUFlN5vbmbI5iooAJjdkDKCz5XV1WHlcQLNfF9zJe jT9A== X-Gm-Message-State: AA6/9RkFFAFghcszlzBIYSG2CUL6RS0Kl++nLXvHlw7dC0CFwiAF3NsN/l3PPS2AtTxyafGcCJf1Pt0ec6JzQUPn X-Received: by 10.28.60.2 with SMTP id j2mr7864042wma.46.1475450743192; Sun, 02 Oct 2016 16:25:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.67 with HTTP; Sun, 2 Oct 2016 16:25:42 -0700 (PDT) From: Anders Kristensen Date: Sun, 2 Oct 2016 16:25:42 -0700 Message-ID: To: stir@ietf.org Content-Type: multipart/alternative; boundary=001a114a48886ee1ee053dea251a Archived-At: Subject: [stir] Nits in draft-ietf-stir-rfc4474bis-13 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2016 23:25:48 -0000 --001a114a48886ee1ee053dea251a Content-Type: text/plain; charset=UTF-8 * 4.1: orig is not an array. First, the JSON "orig" array MUST be populated. ... Otherwise, the array MUST be populated with a "uri" * I think the intention is to leave it up to local policy whether source identity is based on From or PAI but the text in 4.1 says that if the source is not a number it's based on From. * Probably the destination identity should always be based on To but this is only explicitly stated for the non-number case. * Further down in 4.1: { "orig":{"tn":"12155551212"}, "dest":{"tn":"12155551213"}, "iat":"1443208345" } Here the dest value should be an array. * Again orig is not an array: The "orig" and "dest" arrays may contain identifiers of heterogeneous type; for example, the "orig" array might contain a "tn" claim * 5.1: R-URI and To in the example should be sip:alice@example.org Contact should be @gateway...? --001a114a48886ee1ee053dea251a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
* 4= .1: orig is not an array.
      First, the JSON "or=
ig" array MUST be populated.
...
      Otherwise, the array =
MUST be populated with a "uri"

* I think the intention is to leave it up to local po= licy whether source identity is based on From or PAI but the text in 4.1 sa= ys that if the source is not a number it's based on From.

* Probably the destination identity sh= ould always be based on To but this is only explicitly stated for the non-n= umber case.

* Further= down in 4.1:
<= br>
   { "orig":{"tn":"1215555=
1212"},
     "dest":{"tn":"12155551213"},
     "iat":"1443208345" }

Here the dest value should be an array.

* Again orig is not an array:

   The "orig" and "dest" arrays may contain identifier=
s of heterogeneous
   type; for example, the "orig" array might contain a "tn&q=
uot; claim

* 5.1: R-URI and To in the ex= ample should be=C2=A0<= a href=3D"mailto:sip%3Aalice@example.org">sip:alice@example.org<= /div>
Contact should = be <number>@gateway...?

--001a114a48886ee1ee053dea251a-- From nobody Sun Oct 2 16:26:00 2016 Return-Path: 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 4271B12B10E for ; Sun, 2 Oct 2016 16:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.695 X-Spam-Level: X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 cczuwzxGjI1d for ; Sun, 2 Oct 2016 16:25:52 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 B21F212B10D for ; Sun, 2 Oct 2016 16:25:51 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id p138so120734314wmb.1 for ; Sun, 02 Oct 2016 16:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=O/ryUXBQK1M7RRZMFeizvha/NUVl9NN17E8cXYRbMsQ=; b=nKezBZX/UJgMQ6fMec8+wgSetaoKURjer//j7gteAJip6cjUWhk9DKo7JhfgfY+r7q 1kiXs6DfYJlHfTigqVxg07oa7LdreVfesu99ARp9Et3BomX0MPVE/lRLwtSy3Gemi3uu vRzyIzL21ILeKfYot2ahOa5Kn/raOQeinXbOrEdxGipM+vzgjcYVV0GDiQaQdKBETUye RuVME9IE36I1qFZ/Iwv0DKsyYEWYP7AeOur6c5YVGGeKJ21w+xGncbR+e9IalfB+XEhi 5JhuiA1O7NxSNV1JuMSNAL1d6kBbXjw6Bpj39MTYk3YOxIKDuwZHqvjgTkHC353sN3mE cj2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=O/ryUXBQK1M7RRZMFeizvha/NUVl9NN17E8cXYRbMsQ=; b=bQBX8SkLQv7jCQBhbFy8YUfRAnuew56B20wihmcjic/IG0McitUuv7cfG1HxAROC+e 0o14Ob3PzLT+g8V1RHEaGqDhgLHfsJMownfBUpAUt+3mWBvznQw7oWozLTxhwjbO20dL J5NPseNgEmz3u8YsGd3dC56yB40/aWBKlqm9d6KQy+elT3wN48urXcnzQnOdRtfCPoxH GFg9jIqrOF5r4sbSxPY61C2S2868LUptxAbKPfmoqJ8i6irf4rvZK3TxC7oY9NseMlIk yJuY4pEG5ozrM2sREX17yF3a2LTuOYPYFjcb/lRqY7xHwZ+b3rfxvQDfW46Ls+WGFAW1 LeuQ== X-Gm-Message-State: AA6/9RklxYMAZ76wiRJ+SpYjZx0eGm2eQPXljJXMQ9KOFA5dsUrex4lfqig1VP+geaXEBkEw8bdOG01dzBHfZUZ7 X-Received: by 10.28.15.202 with SMTP id 193mr6457570wmp.98.1475450749843; Sun, 02 Oct 2016 16:25:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.67 with HTTP; Sun, 2 Oct 2016 16:25:49 -0700 (PDT) From: Anders Kristensen Date: Sun, 2 Oct 2016 16:25:49 -0700 Message-ID: To: stir@ietf.org Content-Type: multipart/alternative; boundary=001a1145ac32d483c5053dea2574 Archived-At: Subject: [stir] Nits in draft-ietf-stir-passport-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2016 23:25:53 -0000 --001a1145ac32d483c5053dea2574 Content-Type: text/plain; charset=UTF-8 * 4.2.1: s/only have one/have exactly one/ ? The "orig" JSON object MUST only have one key value pair * 4.2.1.4: Why is "Single Originator", "Single Destination" etc. capitalized? * 5: "above" is actually below (also in Section 8). For the JWS Payload and the JWS Protected Header, the lexicographic ordering and white space rules described above, and JSON serialization rules in Section 8 of this document MUST be followed. * 8.1: Delete leading whitespace: {"dest":{"uri":["sip:alice@example.com"],"iat":1443208345,"mky": [{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD5 4F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F82183B5 40212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}], "orig":{"tn":"12155551212"}} * 9.1: s/the the/the/ * 9.2: Looks like this paragraph was meant to be rendered as a bulleted list. * 9.2: s/the end user the asserted identity represents/the end user represented by the asserted identity/ * 12.1: I think technically speaking this doc does not depend on 4474bis so could make that ref informational. * App A: Remove leading whitespace: {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org /passport.cer"} --001a1145ac32d483c5053dea2574 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
* 4.2.1: s/only have one/have exact= ly one/ ?

The "orig" JSON object MUST only have o=
ne key value pair

*= 4.2.1.4: Why is "Single Originator&quo= t;, "Single Destination" etc. capitalized?

* 5: "above" is actually below (also = in Section 8).

   For the =
JWS Payload and the JWS Protected Header,
   the lexicographic ordering and white space rules described above, and
   JSON serialization rules in Section 8 of this document MUS=
T be
   followed.

* 8.1:= Delete leading whitespace:

   {"dest":{"uri":=
["sip:alice@example.com=
"],"iat":1443208345,"mky":
     [{"alg":"sha-256","dig":"021ACC5427=
ABEB9C533F3E4B652E7D463F5442CD5
     4F17A03A27DF9B07F4619B2"},{"alg":"sha-256",&q=
uot;dig":"4AADB9B13F82183B5
     40212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}],
     "orig":{"tn":"12155551212"}}
=

* 9.1: s/the the/the/

* 9.2: Looks like this paragraph = was meant to be rendered as a bulleted list.

* 9.2: s/the end user the asserted identity represents= /the end user represented by the asserted identity/

* 12.1: I think technically speaking this doc do= es not depend on 4474bis so could make that ref informational.

* App A: Remove leading whitespace:

   {"alg":"ES256","typ":"passpor=
t","x5u":"https://=
cert.example.org
       /passport.cer"}
--001a1145ac32d483c5053dea2574-- From nobody Mon Oct 3 01:49:11 2016 Return-Path: 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 0FD6112B205 for ; Mon, 3 Oct 2016 01:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 0CGGW3cpelv5 for ; Mon, 3 Oct 2016 01:49:08 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67ADB12B20C for ; Mon, 3 Oct 2016 01:49:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7B9BC300A3F for ; Mon, 3 Oct 2016 04:49:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2pGfjGW4fpPa for ; Mon, 3 Oct 2016 04:49:06 -0400 (EDT) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 40E1A300A41 for ; Mon, 3 Oct 2016 04:49:06 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Mon, 3 Oct 2016 04:48:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [stir] Second WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 08:49:10 -0000 I have been thinking about this some more. I have been uneasy about = this use of policy qualifier, and I think that I have figured out the = source of that concern. The certificate is a signed structure. It is signed by the CA, and the = CA needs to be able to vouch for the information in it. I=92m not sure = how the CA knows what level of assurance qualifier value is appropriate = for a particular subject. In the current documents, consider a PASSporT signer that is associated = with two sets of caller numbers, where the signer can provide full = assurance for the first set and partial assurance for the second set. = Then, this signer will need two certificates, one with id-loa-full and = the other with id-loa-partial, then the signer must select the = appropriate certificate based on the caller number. Really, the CA is = not adding any value here. Perhaps it would be better to remove the level of assurance from the = certificate altogether. If we do that, the we would need to include the level of assurance in = the signed PASSporT claims. In this case, the signer would need to = include either loa=3Dfull or loa=3Dpartial, depending on the caller = number. Either way, the signer is deciding what level of assurance to include. What do others think? Russ On Sep 15, 2016, at 12:07 PM, Russ Housley wrote: > I have found a place where additional clarity is needed in Section = 5.1. The current text is: >=20 > 5.1. Levels Of Assurance >=20 > This specification supports different level of assurance (LOA). The > LOA indications, which are Object Identifiers (OIDs) included in the > certificate's certificate policies extension [RFC5280], allow CAs to > differentiate those enrolled from proof-of-possession versus > delegation. A Certification Policy and a Certification Practice > Statement [RFC3647] are produced as part of the normal PKI > bootstrapping process (i.e., the CP is written first and then the = CAs > say how they conform to the CP in the CPS). OIDs are used to > reference the CP and if the CA wishes it can also include a = reference > to the CPS with the certificate policies extension. CAs that wish = to > express different LOAs MUST include the certificate policies > extension in issued certificates. See Section 11 for additional > information about the LOA registry. >=20 > This all makes sense to me, but it does not say whether the LOA is = inferred from the CertPolicyId or explicitly carried in the = PolicyQualifierInfo. I think that the later is intended because of the = reference to an LOA registry. Please confirm that I got that right. >=20 > For background, RFC 5280 specifies the following ASN.1 for the = PolicyQualifierInfo: >=20 > PolicyQualifierInfo ::=3D SEQUENCE { > policyQualifierId PolicyQualifierId, > qualifier ANY DEFINED BY policyQualifierId } >=20 > So, I think we need to specify a single OID for the LOA = policyQualifierId that is used in all certificates, and then have the = qualifier carry an object identifier for the LOA. Each certificate = policy would list the LOA object identifiers that are supported. If = this is the intent, then the IANA considerations should ask for the = assignment of the policyQualifierId object identifier. >=20 > That would result in something like this: >=20 > id-qt-loa OBJECT IDENTIFIER ::=3D { id-qt TBD1 }=20 >=20 > id-loa-full OBJECT IDENTIFIER ::=3D { TBD2 }=20 > id-loa-partial OBJECT IDENTIFIER ::=3D { TBD3 }=20 > id-loa-none OBJECT IDENTIFIER ::=3D { TBD4 } >=20 > Comments? >=20 > Russ >=20 From nobody Mon Oct 3 07:36:32 2016 Return-Path: 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 3482B12B30A for ; Mon, 3 Oct 2016 07:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Xcc4frahpxqI for ; Mon, 3 Oct 2016 07:36:27 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0131.outbound.protection.outlook.com [104.47.32.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD83612B054 for ; Mon, 3 Oct 2016 07:36:26 -0700 (PDT) Received: from BY2FFO11FD008.protection.gbl (10.1.14.32) by BY2FFO11HUB027.protection.gbl (10.1.14.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5; Mon, 3 Oct 2016 14:36:25 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BY2FFO11FD008.mail.protection.outlook.com (10.1.14.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5 via Frontend Transport; Mon, 3 Oct 2016 14:36:25 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u93EZo6f044757; Mon, 3 Oct 2016 09:36:24 -0500 Received: from plswe13m03.ad.sprint.com (plswe13m03.corp.sprint.com [144.229.214.22]) by plsapdm2.corp.sprint.com with ESMTP id 25tax521cr-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 03 Oct 2016 09:36:24 -0500 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m03.ad.sprint.com (2002:90e5:d616::90e5:d616) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Oct 2016 09:36:20 -0500 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1210.000; Mon, 3 Oct 2016 09:36:20 -0500 From: "Gorman, Pierce A [CTO]" To: Russ Housley , IETF STIR Mail List Thread-Topic: [stir] Second WG Last Call for STIR Certificates Document Thread-Index: AQHSHVO8VDGFYp+E8EuUIFAwXDvWFaCWy8DQ Date: Mon, 3 Oct 2016 14:36:19 +0000 Message-ID: References: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.38; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(438002)(377454003)(199003)(51444003)(24454002)(189002)(13464003)(305945005)(7846002)(3846002)(2900100001)(106116001)(87936001)(81166006)(356003)(68736007)(97736004)(19580395003)(6116002)(106466001)(24736003)(108616004)(47776003)(23726003)(8676002)(7696004)(33646002)(586003)(81156014)(11100500001)(5250100002)(8936002)(189998001)(102836003)(7736002)(54356999)(8746002)(76176999)(5001770100001)(97756001)(46406003)(50986999)(19580405001)(92566002)(107886002)(5660300001)(626004)(50466002)(86362001)(2950100002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB027; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD008; 1:arumlzHdYeRmiRH6q01m3XoowDQ8fKDrKa2q32cGnLk7OUP0XCBbjfJYz4eKfgI2UoR9om14WrZu7r2fYi8xyCyah6UWn7WfK5YtVlhehvj1o9ZHfK86sNEDW/xoA64Q945YmxPnLTXYVLeLCWtkAv4DdLqtGy2uwX5kdgIjhhZtkp5l+gZdzynNVI88YvX7j8rroYtQa41DCqLKpif4rzGFgIwSJylu5r8yEqKoYa5e5gI/SpW+vLTjn8kPWCdNC6hFZ2oQAf9LEaMoK8J0Iv7b02D+22lRomp96wig5D3LhLMZ1vjXzV9r19ZGGf3tb3vhUNLTLiEqhlRpF1WZKvCS4ih2b1+VHcqwq74nhNUwUmvr75OQSuPlbpbhFoOTwOEAAR+JHfiDhxHypQkmaHrG48AbyHM9EbWPI3/sXef8/kxbYmkD1LzcVwEADHrfbkwB/I7KdxAVS4Ee71Cp2NujJkKi3zx5phVADO7FcN4G/j5VRM5wdQhVSO3Q/MwkjAXbDgWiRdOhaTghDuPGAWQDs3s3vNtN1Jyo8+wj2ILW0XRUeyGCCYI0qN2odNvX X-MS-Office365-Filtering-Correlation-Id: 717962a9-48cc-4f6f-3272-08d3eb9aa750 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB027; 2:GV40HilOpiIWs992qkJKuY4ri7p72m0gVajTQYddSWzBUWnWcGz7c2EjNXIk1zpFD/eXp5p4FeVVerqZqfC8NpupRZD8F5O7pUEFAoUZLxuwbL9SG53vCeuIdkLIbvQ8cCCc+NZaFLELH254ASfnJAivu3FNpexAHhnuk98r+Vg/ofNOfNJ/XWMB4smiLJcs; 3:rgu3nSlf8wa2AVRQMQQTu4tWMY7LAlnCG0D0FF9uoWfflxpBOmMSxwosmVfiVRHBlhcaIztHwfqYSOmukvkEB6tYdrvGz9QTw/ijrFingliafttR4q5CKhmvPWJa37mQRtKxERxg3nsuelBQdBG1K/H0Fs/sNyxILl8zT2PUPXaC4Cs/u27kj/Lt8aCkSjeSWPj3UO8b1X0AJ/Kk3MhRerXR34A23z9P6VaHH6e04VZ6f8g9th5KJgKoyeoxSJBHbKu7ecN3BlRZVynrAfOmbw==; 25:ghNOmCAGBmpBS3m1h9d4PRxFCFFFSEWuYLfWXz8tLuPtxMbOLLevt8sMJstTyn8/aJdtqwF3DSfpmLcEZ6mpy5q9LtcWQxd8cmkgqOXl8kYZXZ6uh/6yp8AOU58chIC5Zi3IK5N2n5ZKTimt8XufVhAP8KsF+RtpnujDC2Rc3dD++upbKKrbseoaBSGZu/r85KfuMis5m6KGjMvSvDXmRzhmUWhnlMXfQ5oICxIqZmbBNNiny2oxWc6rgnjZ3M3gWNGuO+CsF6lmwxq7IQc9xX446gM0TxKEL2vhSq7+gvil4PRLvLCE4aByHe8o85Lf7naFoOaLBa7jNUiAyjlHBVZ0Mc6MlbeXLcXQpdUG5rpJ0zOjbQbL4RxEZywPaPsUXrqb//Uwh/h3bdq0y+2eozycfmmJwXeQ/sBLKA40mRdifKB0Vwto/VH7AbzwSy0n X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY2FFO11HUB027; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB027; 31:fTSb5Xzrj9KlhmhQqVbk4INupqWs0cBainjsjloXeyNym3J4ASGsRqpgl8IaM0ol4CCbC6hXyEcJM5/DUw6KVq8N4+UrEImbCDziVnfZlr0ZTATM8L4ZPGTBMm062PZXpgjX3QmPMg9UdLhRNE3uayDWLNOwG5+ztOVKPaHeLXqFxCyyGJ/sDsfIZsi20u9KbM6JiPgB+ocacqoNjEt33Nc07wniTDKJPbPqA3ZCJSI=; 20:lUl0IYmbfDUy3EsJfFM/KmJ6a80neovD3PnJ2SKSFqQYgfP0+BvRRcJAcd7DQkw1fabdmZUgYLXz+cg8fcZKic9Fe29swt3h9j7VYWmTimW3bDlEbBvnfz3HHywyfDxirvVPN0uZLcxpIphKdkr1pYOjjNnu7UZkVtyk48qmV2YdWyyorR8Edsd3iHCYyE9YkznsIMwUv2TPlrm7hgO6C6pD74WBXuR+A9rIO/RTqcbBa+76IdSK7CINuYZIhFH/qSJ4chc+k2/w2OkEcbXNpQumAgzfoz0s6XmmbNRHVyvS8g2ZAHH3elN/jZVlFGVhfHJbBggdgtV3mTTz9+z5Xv3HC+E4La4sYH13tpbH093hy1+DybiK53KCJIVZjdt0UP3cHfDAY1yKqwGh/4R23hWNlIDw0cAPS/FoLX1PxjvJNYd6EpwebiiQ+2gpV1R7UdJTQDST/Aq+PexuXLtT5wKMZyDCif/nFWbOKG9NSC2HWAOzH9YZYn2dKxiYGN9k X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13018025)(13017025)(13015025)(13024025)(13023025)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BY2FFO11HUB027; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB027; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB027; 4:NVwkBR3qEVShJiYW/kXhVrKrJ+2NuUakMlLDerVh52zFiJ5WiluqE2JHp6a8PHHGqmmKthOeViDfQ7z7Yau9Fjf5y5pwHIi843ioNlMrVzxleUucmoITMSqn+eit/chi+hlnA3biHMfGfgUwpbVu2pvaiQ9EoEt0FaHEuiWufKqzFNgOFzwe/xy8w8VVvXuwvRSFkUAaGniN7h1k3rkd05BKwZ5EuwOBxjVWAEWRKN+Y9asOJJxJV31EbHkxV26I3KznUPq4DWi4OBHTa9mfzYQ4YOOnUCx096d0krst3Avc9iG3W/c9AjJsW8JRG7HEePzof6GISwthJwMfmJxJLhUb9M8aIHwvQVGlB6KpHrwBX9Go8c+M8fcgZQKoraK3Dkg9ODDVOAhtdDufeYCVJausI1E/Wvh88DUa/T5vdz+MXJW2WfkWLcLuMS8+XsXk3K1f7wd+vlmuMbq5017VqfOdz3IyeYk71DI7D/eKrUYO7n1dX8BvMdn76BRCsX98 X-Forefront-PRVS: 008421A8FF X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB027; 23:fWrT5ZdofhuKImFG0d4K0dZmG0XZj4J4JUw7hlzi?= =?us-ascii?Q?s30nTgv+89yVzWfuG9unPDbxQqDjsUN589ByLClrHdgBHEKkW1VD5YRqiayJ?= =?us-ascii?Q?BoauExsjK5dpl//9yR91aqUkLEUPokV479zlUN90z/QvxKJNxF23VN1WyEna?= =?us-ascii?Q?9I+duO99153DN/p3naBg4RAJBiRKB2qpj8Os+5x/WEEfQ+JFR7Pcb0vBFnbc?= =?us-ascii?Q?XdiBP0i+SBfmwUPH8Y8z1PPrK/z+v840kDF7UcrxkUdILqDR1aGFaTGOIXeR?= =?us-ascii?Q?9HxQY/K4YFp6/YxhxIBvPUy5xCAtb3leMSyXsdP4mnq5bCoxCB7EMSiweK2p?= =?us-ascii?Q?7nBO/0ma18NWLZ1vm8+Gz0GdfbFX4JIkqEyfGHp8y4rpcP929LHvp5ez3eNk?= =?us-ascii?Q?PzJRYZqrhu7rPBSLwJ4wjLeQyTWxq1EKxH9hADBUvMD2TURcHgp1tDMhbeeS?= =?us-ascii?Q?AFnDg57rNDEu/MqwPSTSGGiqzjyWpWtpuWGdp6WmQZCxVbOZtlCiEqn6LYAC?= =?us-ascii?Q?FJ1E0FuhOg5xhHXP09I7+wxNoXFPREl1DMKa6bk4n6VvuYtHvD8EAAM8bEhQ?= =?us-ascii?Q?6M5jCA05LkbhcHLdqmcvsp9lCfaun4TW/ifigEQoGk3aOOMmdUF4R6pDNvuF?= =?us-ascii?Q?iz9ZxpjT33VuNTF8PbJBvjSeVGcCXhCQ6WfdpxfxNYFL5nBvJCGSyU+3uGb4?= =?us-ascii?Q?HAuEO4EiIkHErs3IzqJdMoODxkzFS01qV2/xw6JiPExPclQ66ldni48fwNj1?= =?us-ascii?Q?XQqHsNCnOxViKrqzGLFoFyD0EGSkHIrEP1sU0DRz+XaJwh9IPBOasWwfoSJG?= =?us-ascii?Q?DHR6xDNcaGMKZPtds8Ae97/2olB/cqRfhwrDvQwcsRSvW+ENF7I92w7P55rI?= =?us-ascii?Q?qimCMe9XjbO7FlSNKty489Daib3h+irpWxNTZWaUmclTHQWU0AZ4wHchKfO5?= =?us-ascii?Q?jeR42Y/IQW0sgA3/4Ae19J4Q8ljSjCUyKky2uuk7vtiIWNSapCYOQt8VSI9r?= =?us-ascii?Q?PA+pOGqZN0VZo4AOZAYPZFWzw4WSgtKiXM8xeV0IBTlPJYgJeWBrX118TuZn?= =?us-ascii?Q?A2sG3Yv19TlMc22eMnYLMbbLsrgMrE/0bAU6dFRzACy6LHZtQBZAMDNUPHQW?= =?us-ascii?Q?CyitrnscxedEDSzL2Ma5Inv2Jwn1sjtijG/uJUN4zFp8iSGevkm9FUAm1728?= =?us-ascii?Q?Emc7F0Mnr3W07rlQpLidy9vy4F3WJgga7Gtz5VtZWZ8YOEiEkgi1b80S8fuR?= =?us-ascii?Q?rWe9AmoPunHvsq3+ExNmPycXqwyiKOGvdF0iipZpjxZWaE9qAU0yhqMwLIY1?= =?us-ascii?Q?9A=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB027; 6:e2akAMfhiu46Jbyncyef8kYNbLJ6mTfMubljSjVNyKm4siBnFncLa8H5n78xBAD9zBu78Mef0iV0Gij9lEYY/U2ms3DwVpERt0dVGn7Hsj2NG5Ay9b12+CXYHF+nf5pCiTYZFVXARRc7sIs1r9NLUYbtkhxvgEGBZQmywC7FJFUmCuVPBFyYySPANxL0ckMyWgczUnVBYhpuDaIgoBmQYSANloND2kHdfhNYOGR34Bxz4PMd1WpE8T3NXGT1AAou0YGHie3DK8rpXPQbQc6LCxEGFgIUwG80hKF9qdsTIdC2l+DWsMVywqagYb6e9qjLnBJh993f3YTR6w8DdhHJGA==; 5:rRLb4mDt3WQDEmGFWM2TsK1DlMQxXFUm7SRkOmRIeNWXx4JDiNBnUaT0b0RXxEIs/SrNhwpwDguNSFQwbYmbsQo3fo/hChJQ6OFGra5rYkOOEFg1bAUzKYYK9MZgp1xTiq8q6/CGMOnhqdH1DH/egQ==; 24:AAqD+Z3xJ2+2+ngpEo1xJo0i03CpIW1O40w9TAwrDTSyn9WKZ3KjEnEJWDiiMKdejQ10Uaj873SS901zh++fne2I9lTwyyrXfs3d1jnx+M4=; 7:Yk7VLClry/2ecfalVo1TE6zj89jrq1zgLAycCvg0zaH7sT90UV5MqWcrzIiBOGa8fOX8q+sGy3yRFhSVsafyQb9x2jLdp7Z8t7R3U99Bsto3nBKRKkIxMSTLBmx3ZDUEV4/sdkUL7b76S9fr/AzPEpeB+rAmA9Fc80Ee+cqQzNoLG3QsUv/qtY2JJxmGGmwLPhPubnKA49di4/WtDmgyQm2WErSFqZvSwg+AlET7mKduVO3Gem9fzk3gYJMTFR71ZFtwsY/K4KE1dGs/YV3e8X5TCMA1I8BAeMI1eTvA/cjO3vO0NXzfS9U2EhePNO9J SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2016 14:36:25.1885 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB027 Archived-At: Subject: Re: [stir] Second WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 14:36:30 -0000 I prefer loa in the claims. Pierce -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: October 03, 2016 3:49 AM To: IETF STIR Mail List Subject: Re: [stir] Second WG Last Call for STIR Certificates Document I have been thinking about this some more. I have been uneasy about this u= se of policy qualifier, and I think that I have figured out the source of t= hat concern. The certificate is a signed structure. It is signed by the CA, and the CA = needs to be able to vouch for the information in it. I'm not sure how the = CA knows what level of assurance qualifier value is appropriate for a parti= cular subject. In the current documents, consider a PASSporT signer that is associated wit= h two sets of caller numbers, where the signer can provide full assurance f= or the first set and partial assurance for the second set. Then, this sign= er will need two certificates, one with id-loa-full and the other with id-l= oa-partial, then the signer must select the appropriate certificate based o= n the caller number. Really, the CA is not adding any value here. Perhaps it would be better to remove the level of assurance from the certif= icate altogether. If we do that, the we would need to include the level of assurance in the s= igned PASSporT claims. In this case, the signer would need to include eith= er loa=3Dfull or loa=3Dpartial, depending on the caller number. Either way, the signer is deciding what level of assurance to include. What do others think? Russ On Sep 15, 2016, at 12:07 PM, Russ Housley wrote: > I have found a place where additional clarity is needed in Section 5.1. = The current text is: > > 5.1. Levels Of Assurance > > This specification supports different level of assurance (LOA). The > LOA indications, which are Object Identifiers (OIDs) included in the > certificate's certificate policies extension [RFC5280], allow CAs to > differentiate those enrolled from proof-of-possession versus > delegation. A Certification Policy and a Certification Practice > Statement [RFC3647] are produced as part of the normal PKI > bootstrapping process (i.e., the CP is written first and then the CAs > say how they conform to the CP in the CPS). OIDs are used to > reference the CP and if the CA wishes it can also include a reference > to the CPS with the certificate policies extension. CAs that wish to > express different LOAs MUST include the certificate policies > extension in issued certificates. See Section 11 for additional > information about the LOA registry. > > This all makes sense to me, but it does not say whether the LOA is inferr= ed from the CertPolicyId or explicitly carried in the PolicyQualifierInfo. = I think that the later is intended because of the reference to an LOA regi= stry. Please confirm that I got that right. > > For background, RFC 5280 specifies the following ASN.1 for the PolicyQual= ifierInfo: > > PolicyQualifierInfo ::=3D SEQUENCE { > policyQualifierId PolicyQualifierId, > qualifier ANY DEFINED BY policyQualifierId } > > So, I think we need to specify a single OID for the LOA policyQualifierId= that is used in all certificates, and then have the qualifier carry an obj= ect identifier for the LOA. Each certificate policy would list the LOA obj= ect identifiers that are supported. If this is the intent, then the IANA c= onsiderations should ask for the assignment of the policyQualifierId object= identifier. > > That would result in something like this: > > id-qt-loa OBJECT IDENTIFIER ::=3D { id-qt TBD1 } > > id-loa-full OBJECT IDENTIFIER ::=3D { TBD2 } > id-loa-partial OBJECT IDENTIFIER ::=3D { TBD3 } > id-loa-none OBJECT IDENTIFIER ::=3D { TBD4 } > > Comments? > > Russ > ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Mon Oct 3 13:37:26 2016 Return-Path: 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 9F333129527 for ; Mon, 3 Oct 2016 13:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 DFLf2Qi9JTGE for ; Mon, 3 Oct 2016 13:37:22 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE8C129522 for ; Mon, 3 Oct 2016 13:37:22 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u93KWfMj003459; Mon, 3 Oct 2016 16:37:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar.biz; bh=kXvp/KrLyoiP9SAmPoBnbn0tuQO42/Kbp2FhJQOIQ/8=; b=zP6M2lxAY8GXIfSEiqTXpoO4ETskpLiFvB/YB5Yw9lQduGrPyuAVmJuFcpLYmwKWg+KA lUfZG40PFn1sk/CegbAC/Sc4ybC9U4FXct1KWZ5soZKwEiaSv2gpbAXgkdjEc99XMQ8F kaJ+3ppVNs9R9fawBCe7hinc+qa3aG4I+ssXtalMcVb2UCPl9GWu6mx1BVM+U0cdia7G ctXbB0Llp3LJEw/hrI3HrgfjX5pvrF2XXO/+xR978hGylMS17N6jUpNvLLcvm17IEPlV D3n5vw2mOF/JMF8Hyw+W+MNhMkT6TgtBGSODHYf5TAuH/kZVgkcaxnsczHWUd4zQpZeQ Zg== Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 25t7suxxpy-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 03 Oct 2016 16:37:22 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.225]) with mapi id 14.03.0279.002; Mon, 3 Oct 2016 16:37:20 -0400 From: "Peterson, Jon" To: Russ Housley , IETF STIR Mail List Thread-Topic: [stir] Second WG Last Call for STIR Certificates Document Thread-Index: AQHSC3y43yS7fSkQQUGpP6fQ3Pml6aB7Ao0AgBvPa4CAAILogA== Date: Mon, 3 Oct 2016 20:37:20 +0000 Message-ID: References: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.13.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-03_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609280000 definitions=main-1610030351 Archived-At: Subject: Re: [stir] Second WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 20:37:24 -0000 So, I definitely agree that it makes sense for an authentication service to select a level of assurance on a per-call basis when it is signing for requests coming from heterogenous points of origin, and that the AS shouldn't have to hold multiple certificates with different LoAs to do that. For that reason, I do see the value in specifying a JWT claim which allows authentication services to characterize those different originators. I don't think this is such a universally applicable feature that we need that we need to spend another rev to get it into the baseline PASSporT spec, but I can definitely see adding something like that as an extension in the near future. I'm not sure however that this JWT claim would entirely eliminate the need for a level of assurance indication in the certificate or the corresponding proposed registry. In some models, for example, a number owner might delegate authority to a customer, and want to grant the customer a credential they could use to sign requests with their own authentication service. Moving LoA to PASSporT only works if we assume that any certificate holder has the authority to assign LoAs - but in delegation models, the LoA should be constrained by limited authority of the cert. There are other use cases I can think of as well where having a level of assurance in a cert could be meaningful. But I don't think we need to specify how delegation in the cert would work now: we just need to create the necessary registry in the certs document. Given that we are late in the process here, I'd propose we just do that and let the community do with it what they will. If people end up never using this code point and registry in certs, we won't have gone to any real trouble for it. Jon Peterson Neustar, Inc. On 10/3/16, 4:48 AM, "stir on behalf of Russ Housley" wrote: >I have been thinking about this some more. I have been uneasy about this >use of policy qualifier, and I think that I have figured out the source >of that concern. > >The certificate is a signed structure. It is signed by the CA, and the >CA needs to be able to vouch for the information in it. I=B9m not sure ho= w >the CA knows what level of assurance qualifier value is appropriate for a >particular subject. > >In the current documents, consider a PASSporT signer that is associated >with two sets of caller numbers, where the signer can provide full >assurance for the first set and partial assurance for the second set. >Then, this signer will need two certificates, one with id-loa-full and >the other with id-loa-partial, then the signer must select the >appropriate certificate based on the caller number. Really, the CA is >not adding any value here. > >Perhaps it would be better to remove the level of assurance from the >certificate altogether. > >If we do that, the we would need to include the level of assurance in the >signed PASSporT claims. In this case, the signer would need to include >either loa=3Dfull or loa=3Dpartial, depending on the caller number. > >Either way, the signer is deciding what level of assurance to include. > >What do others think? > >Russ > >On Sep 15, 2016, at 12:07 PM, Russ Housley wrote: > >> I have found a place where additional clarity is needed in Section 5.1. >> The current text is: >>=20 >> 5.1. Levels Of Assurance >>=20 >> This specification supports different level of assurance (LOA). The >> LOA indications, which are Object Identifiers (OIDs) included in the >> certificate's certificate policies extension [RFC5280], allow CAs to >> differentiate those enrolled from proof-of-possession versus >> delegation. A Certification Policy and a Certification Practice >> Statement [RFC3647] are produced as part of the normal PKI >> bootstrapping process (i.e., the CP is written first and then the CAs >> say how they conform to the CP in the CPS). OIDs are used to >> reference the CP and if the CA wishes it can also include a reference >> to the CPS with the certificate policies extension. CAs that wish to >> express different LOAs MUST include the certificate policies >> extension in issued certificates. See Section 11 for additional >> information about the LOA registry. >>=20 >> This all makes sense to me, but it does not say whether the LOA is >>inferred from the CertPolicyId or explicitly carried in the >>PolicyQualifierInfo. I think that the later is intended because of the >>reference to an LOA registry. Please confirm that I got that right. >>=20 >> For background, RFC 5280 specifies the following ASN.1 for the >>PolicyQualifierInfo: >>=20 >> PolicyQualifierInfo ::=3D SEQUENCE { >> policyQualifierId PolicyQualifierId, >> qualifier ANY DEFINED BY policyQualifierId } >>=20 >> So, I think we need to specify a single OID for the LOA >>policyQualifierId that is used in all certificates, and then have the >>qualifier carry an object identifier for the LOA. Each certificate >>policy would list the LOA object identifiers that are supported. If >>this is the intent, then the IANA considerations should ask for the >>assignment of the policyQualifierId object identifier. >>=20 >> That would result in something like this: >>=20 >> id-qt-loa OBJECT IDENTIFIER ::=3D { id-qt TBD1 } >>=20 >> id-loa-full OBJECT IDENTIFIER ::=3D { TBD2 } >> id-loa-partial OBJECT IDENTIFIER ::=3D { TBD3 } >> id-loa-none OBJECT IDENTIFIER ::=3D { TBD4 } >>=20 >> Comments? >>=20 >> Russ >>=20 > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Mon Oct 3 18:53:22 2016 Return-Path: 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 7AC1B1293F2 for ; Mon, 3 Oct 2016 18:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 nErLzYMvBt1m for ; Mon, 3 Oct 2016 18:53:18 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 B642E127078 for ; Mon, 3 Oct 2016 18:53:18 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id j129so172316528qkd.1 for ; Mon, 03 Oct 2016 18:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CewOnoiXARsSC8Ks1C+LeKc+6Co57z5JoxOnn3JRQyU=; b=Lhw3zZ3uhiXs6lEmONK3AkelrtB1tYr8H+XZpq+lnpMKm9ONJ2pQENHbneMFTvgzgU biqEa9YCw7oZLPjx2kt6rVJH8E++0dggyzt/1FDgaDp6VPnqvD/1e6Q+TNGaf0/6wYkC OEebYvQXS0c+NlKnHwI0LugbtUxgIejcX+DkcYkJd8njqRxrwR0rq5+Jf9kbJ4ES6PVz kX/d+1muPXbAosEEt/mCxdC2vcHzRLY5M0Zh0SKvg1vjxMduD48wQAZn0PK8oBmdMtxx R4cpUrlY8I7KbZ51QhVrUFtMVnHoHG7ujeu1ORt1eUL/aW5GjzhtiB+7VRMTdsi+Gv3z gvMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CewOnoiXARsSC8Ks1C+LeKc+6Co57z5JoxOnn3JRQyU=; b=UB0VcaGl6y/fxuB3FXLTOcq7LwoOgvY1n9JxCtlZ52t6L2tNGyKPWRIXe4CBsT8HyV U3KFzFx+TeluC9DxxSE6VDttFIjsHbNRXPX+rJeFLpA3/SwZ/MsqTXB5xvzCBj0H+WdQ YN/xyNihTwP7u1o1KB9VO0VU9r99rw03DlMsJMgk5uKmmTkVnBACkw1S7PRPB0z63wsC QIVLPCM02l2aWmJ1J5tfG+eCEcKFqi+9RTsoHKnk5ybFn0fnJ6LdBIA64dKr9Uzo9P2s Lgqkq6R+BwIfIvuFJEtx308GNAznFab9YE+es7JX1OpXYMeBB/XusGK5QgsjhsX67AUG VPpw== X-Gm-Message-State: AA6/9RnXGSEBMc9+4/vMVG2hg2Yh46K2cAhAV/U+9rZnDcQ0lLAPuS9PKvCXqCNr9Tq5KA== X-Received: by 10.55.123.133 with SMTP id w127mr1137605qkc.271.1475545997907; Mon, 03 Oct 2016 18:53:17 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:140b:46ac:4114:f2ec? ([2601:41:c101:9364:140b:46ac:4114:f2ec]) by smtp.gmail.com with ESMTPSA id 2sm567226qki.28.2016.10.03.18.53.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Oct 2016 18:53:17 -0700 (PDT) From: Chris Wendt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6C32B5B7-59CA-43A5-A035-F658D2BF402C" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Mon, 3 Oct 2016 21:53:16 -0400 In-Reply-To: To: Anders Kristensen References: X-Mailer: Apple Mail (2.3226) Archived-At: Cc: stir@ietf.org Subject: Re: [stir] Nits in draft-ietf-stir-passport-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 01:53:20 -0000 --Apple-Mail=_6C32B5B7-59CA-43A5-A035-F658D2BF402C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Anders for your comments, will incorporate them in next version. > On Oct 2, 2016, at 7:25 PM, Anders Kristensen = wrote: >=20 >=20 > * 4.2.1: s/only have one/have exactly one/ ? >=20 > The "orig" JSON object MUST only have one key value pair >=20 > * 4.2.1.4 : Why is "Single Originator", "Single = Destination" etc. capitalized? >=20 > * 5: "above" is actually below (also in Section 8). >=20 > For the JWS Payload and the JWS Protected Header, > the lexicographic ordering and white space rules described above, = and > JSON serialization rules in Section 8 = of = this document MUST be > followed. >=20 > * 8.1: Delete leading whitespace: >=20 > {"dest":{"uri":["sip:alice@example.com = "],"iat":1443208345,"mky": > = [{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD5 > = 4F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F82183B5 > 40212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}], > "orig":{"tn":"12155551212"}} >=20 > * 9.1: s/the the/the/ >=20 > * 9.2: Looks like this paragraph was meant to be rendered as a = bulleted list. >=20 > * 9.2: s/the end user the asserted identity represents/the end user = represented by the asserted identity/ >=20 > * 12.1: I think technically speaking this doc does not depend on = 4474bis so could make that ref informational. >=20 > * App A: Remove leading whitespace: >=20 > {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org = > /passport.cer"} > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_6C32B5B7-59CA-43A5-A035-F658D2BF402C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks Anders for your comments, will incorporate them in = next version.

On Oct 2, 2016, at 7:25 PM, Anders = Kristensen <andersk@google.com> wrote:


* = 4.2.1: s/only have = one/have exactly one/ ?

The "orig" JSON object MUST only have one key value =
pair
*= 4.2.1.4: Why is "Single = Originator", "Single Destination" etc. capitalized?

* = 5: "above" is actually below (also in Section 8).

   For the JWS Payload =
and the JWS Protected Header,
   the lexicographic ordering and white space rules described above, and
   JSON serialization rules in Section 8 of this document MUST be
   followed.

* 8.1: Delete leading = whitespace:

   {"dest":{"uri":["sip:alice@example.com"],"iat":1443208345,"mky":
     [{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD5
     4F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F82183B5
     40212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}],
     "orig":{"tn":"12155551212"}}

* 9.1: s/the = the/the/

* = 9.2: Looks like this paragraph was meant to be rendered as a bulleted = list.

* = 9.2: s/the end user the asserted identity represents/the end user = represented by the asserted identity/

* 12.1: I think = technically speaking this doc does not depend on 4474bis so could make = that ref informational.

* App A: Remove = leading whitespace:

   {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org=

       /passport.cer"}
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_6C32B5B7-59CA-43A5-A035-F658D2BF402C-- From nobody Wed Oct 5 05:26:32 2016 Return-Path: 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 7E8021296D8 for ; Wed, 5 Oct 2016 05:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 GwDQSCM4J9Z4 for ; Wed, 5 Oct 2016 05:26:28 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 F19461296DA for ; Wed, 5 Oct 2016 05:26:24 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id j129so209064884qkd.1 for ; Wed, 05 Oct 2016 05:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7rVZyGem3DGQ2NKldpjQLu5NGk9H3MHIjhSDUh2c0Cw=; b=JVrRZQpKLhmU4VxROlFIJk9Lyp4hO5/gM0M8J7xBtF+02ppHpKues7+45lOzlIcu3l OsTiCxU1AnlI/+/zvV19n991A2VL66myvKQrLP3V7G3tywQz59mWkWJWNxkppgOXbVP6 iYdZLY0iwSpy4JXuEWh/MsImBv/j+vZLYiogyf7P9Vla95yyAnayKWT2Y1HZcilqJGp0 BuYiLO3FEVI/Ql9j9qJQGJWlzKDAc6UeYIJ0RqbI9JHV5BKznbM7kx31ZB46xI1tgGjO GEC/G0Dv2UtPPRbxIyWdE2A2kKwxFDYW2E6j+57SVVSVWyD7caEp7tmoQVa7L9GrKxHZ gPvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7rVZyGem3DGQ2NKldpjQLu5NGk9H3MHIjhSDUh2c0Cw=; b=TC6icz8IvCERR/P1pVrnWGMEA58/eN/Z12K4ga+1LZV4+pK1wJ+J4xPbfbbFXayX0P 7ff7/1I3vW7PcqrpNYDJsEk9G7w+ZeHGkx/iObsIfx5paSuWi9bHxt5XzPbjZAbdZfel KV4TQZm+KqlcX4tY4I7++x8g9/+DDTay8lm7U09AgkwXcL4LEWOP1CALtgBX9myVq0lF 3xNhnwnaSR2x2h284iVcWO5cZmBD/vn/f0mN0u4uTW1/1XnJhyAwNzyIUQ2D3YycixdM DywgYDi58aSv+B8dNfRqUobvKRTLmmrgeuSDh5IT+DEh/xouocDSMhV+jX0XRGssg73s lyyw== X-Gm-Message-State: AA6/9RlHn0DlOGFjUCMTOKdCLSlmgT+VPfviM8uT7vfYHK5bdNbCpBAwpX9+GkLj0GfStw== X-Received: by 10.55.56.12 with SMTP id f12mr6044840qka.106.1475670384024; Wed, 05 Oct 2016 05:26:24 -0700 (PDT) Received: from [10.233.63.217] (c-68-33-79-65.hsd1.md.comcast.net. [68.33.79.65]) by smtp.gmail.com with ESMTPSA id u129sm3398648qkf.25.2016.10.05.05.26.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 05:26:23 -0700 (PDT) From: Chris Wendt Message-Id: <0DBEF9D6-B2D6-41AE-974B-1659858D69D1@chriswendt.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_B3C837BE-3A06-45CF-AB68-8C2A8EA38A9E" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Wed, 5 Oct 2016 08:26:26 -0400 In-Reply-To: To: "Peterson, Jon" References: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Second WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 12:26:30 -0000 --Apple-Mail=_B3C837BE-3A06-45CF-AB68-8C2A8EA38A9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree, delegation does seem to be the right use case for this. In SHAKEN framework, we, i think mistakenly, tried to use this policy = indicator for attestation of how the call was originated. While i think = we could have made it work, i think the main problem was that the = attestation is a per call decision and choosing between different = certificates to sign just didn=E2=80=99t feel right once we started = mapping it out. Rather we are going to make the attestation a claim as part of a = passport extension. A per call attestation indicator signed in the = token.=20 So i think the concern Russ is expressing I can see and we have = experienced first hand, but i also agree with Jon that there is probably = scenarios where a delegated customer might be signing all calls with a = policy indicator that says, =E2=80=9Cwe have delegated the authority to = sign calls, so validate the calling identity in that context=E2=80=9D so = keeping it around is probably ok. -Chris > On Oct 3, 2016, at 4:37 PM, Peterson, Jon = wrote: >=20 >=20 > So, I definitely agree that it makes sense for an authentication = service > to select a level of assurance on a per-call basis when it is signing = for > requests coming from heterogenous points of origin, and that the AS > shouldn't have to hold multiple certificates with different LoAs to do > that. For that reason, I do see the value in specifying a JWT claim = which > allows authentication services to characterize those different > originators. I don't think this is such a universally applicable = feature > that we need that we need to spend another rev to get it into the = baseline > PASSporT spec, but I can definitely see adding something like that as = an > extension in the near future. >=20 > I'm not sure however that this JWT claim would entirely eliminate the = need > for a level of assurance indication in the certificate or the > corresponding proposed registry. In some models, for example, a number > owner might delegate authority to a customer, and want to grant the > customer a credential they could use to sign requests with their own > authentication service. Moving LoA to PASSporT only works if we assume > that any certificate holder has the authority to assign LoAs - but in > delegation models, the LoA should be constrained by limited authority = of > the cert. There are other use cases I can think of as well where = having a > level of assurance in a cert could be meaningful. >=20 > But I don't think we need to specify how delegation in the cert would = work > now: we just need to create the necessary registry in the certs = document. > Given that we are late in the process here, I'd propose we just do = that > and let the community do with it what they will. If people end up = never > using this code point and registry in certs, we won't have gone to any > real trouble for it. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 10/3/16, 4:48 AM, "stir on behalf of Russ Housley" > on behalf of = housley@vigilsec.com > wrote: >=20 >> I have been thinking about this some more. I have been uneasy about = this >> use of policy qualifier, and I think that I have figured out the = source >> of that concern. >>=20 >> The certificate is a signed structure. It is signed by the CA, and = the >> CA needs to be able to vouch for the information in it. I=C2=B9m not = sure how >> the CA knows what level of assurance qualifier value is appropriate = for a >> particular subject. >>=20 >> In the current documents, consider a PASSporT signer that is = associated >> with two sets of caller numbers, where the signer can provide full >> assurance for the first set and partial assurance for the second set. >> Then, this signer will need two certificates, one with id-loa-full = and >> the other with id-loa-partial, then the signer must select the >> appropriate certificate based on the caller number. Really, the CA = is >> not adding any value here. >>=20 >> Perhaps it would be better to remove the level of assurance from the >> certificate altogether. >>=20 >> If we do that, the we would need to include the level of assurance in = the >> signed PASSporT claims. In this case, the signer would need to = include >> either loa=3Dfull or loa=3Dpartial, depending on the caller number. >>=20 >> Either way, the signer is deciding what level of assurance to = include. >>=20 >> What do others think? >>=20 >> Russ >>=20 >> On Sep 15, 2016, at 12:07 PM, Russ Housley = wrote: >>=20 >>> I have found a place where additional clarity is needed in Section = 5.1. >>> The current text is: >>>=20 >>> 5.1. Levels Of Assurance >>>=20 >>> This specification supports different level of assurance (LOA). = The >>> LOA indications, which are Object Identifiers (OIDs) included in = the >>> certificate's certificate policies extension [RFC5280], allow CAs = to >>> differentiate those enrolled from proof-of-possession versus >>> delegation. A Certification Policy and a Certification Practice >>> Statement [RFC3647] are produced as part of the normal PKI >>> bootstrapping process (i.e., the CP is written first and then the = CAs >>> say how they conform to the CP in the CPS). OIDs are used to >>> reference the CP and if the CA wishes it can also include a = reference >>> to the CPS with the certificate policies extension. CAs that wish = to >>> express different LOAs MUST include the certificate policies >>> extension in issued certificates. See Section 11 for additional >>> information about the LOA registry. >>>=20 >>> This all makes sense to me, but it does not say whether the LOA is >>> inferred from the CertPolicyId or explicitly carried in the >>> PolicyQualifierInfo. I think that the later is intended because of = the >>> reference to an LOA registry. Please confirm that I got that right. >>>=20 >>> For background, RFC 5280 specifies the following ASN.1 for the >>> PolicyQualifierInfo: >>>=20 >>> PolicyQualifierInfo ::=3D SEQUENCE { >>> policyQualifierId PolicyQualifierId, >>> qualifier ANY DEFINED BY policyQualifierId } >>>=20 >>> So, I think we need to specify a single OID for the LOA >>> policyQualifierId that is used in all certificates, and then have = the >>> qualifier carry an object identifier for the LOA. Each certificate >>> policy would list the LOA object identifiers that are supported. If >>> this is the intent, then the IANA considerations should ask for the >>> assignment of the policyQualifierId object identifier. >>>=20 >>> That would result in something like this: >>>=20 >>> id-qt-loa OBJECT IDENTIFIER ::=3D { id-qt TBD1 } >>>=20 >>> id-loa-full OBJECT IDENTIFIER ::=3D { TBD2 } >>> id-loa-partial OBJECT IDENTIFIER ::=3D { TBD3 } >>> id-loa-none OBJECT IDENTIFIER ::=3D { TBD4 } >>>=20 >>> Comments? >>>=20 >>> Russ >>>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir = --Apple-Mail=_B3C837BE-3A06-45CF-AB68-8C2A8EA38A9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I agree, delegation does seem to be the right use case for = this.

In SHAKEN = framework, we, i think mistakenly, tried to use this policy indicator = for attestation of how the call was originated. While i think we could = have made it work, i think the main problem was that the attestation is = a per call decision and choosing between different certificates to sign = just didn=E2=80=99t feel right once we started mapping it out.

Rather = we are going to make the attestation a claim as part of a passport = extension.  A per call attestation indicator signed in the = token. 

So = i think the concern Russ is expressing I can see and we have experienced = first hand, but i also agree with Jon that there is probably scenarios = where a delegated customer might be signing all calls with a policy = indicator that says, =E2=80=9Cwe have delegated the authority to sign = calls, so validate the calling identity in that context=E2=80=9D so = keeping it around is probably ok.

-Chris

On = Oct 3, 2016, at 4:37 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:


So, I definitely = agree that it makes sense for an authentication service
to select a level = of assurance on a per-call basis when it is signing for
requests coming = from heterogenous points of origin, and that the AS
shouldn't have to = hold multiple certificates with different LoAs to do
that. For that = reason, I do see the value in specifying a JWT claim which
allows = authentication services to characterize those different
originators. I = don't think this is such a universally applicable feature
that we need that = we need to spend another rev to get it into the baseline
PASSporT spec, but = I can definitely see adding something like that as an
extension in the = near future.

I'm not sure = however that this JWT claim would entirely eliminate the need
for a level of = assurance indication in the certificate or the
corresponding = proposed registry. In some models, for example, a number
owner might = delegate authority to a customer, and want to grant the
customer a = credential they could use to sign requests with their own
authentication = service. Moving LoA to PASSporT only works if we assume
that any = certificate holder has the authority to assign LoAs - but in
delegation models, = the LoA should be constrained by limited authority of
the cert. There are = other use cases I can think of as well where having a
level of assurance = in a cert could be meaningful.

But I don't think we need to specify how = delegation in the cert would work
now: we just need to create the necessary = registry in the certs document.
Given that we are late in the process = here, I'd propose we just do that
and let the community do with it what = they will. If people end up never
using this code point and registry in = certs, we won't have gone to any
real trouble for it.

Jon Peterson
Neustar, = Inc.

On 10/3/16, 4:48 = AM, "stir on behalf of Russ Housley"
<stir-bounces@ietf.org on behalf of housley@vigilsec.com> wrote:

I have been thinking about = this some more.  I have been uneasy about this
use of = policy qualifier, and I think that I have figured out the source
of that concern.

The certificate = is a signed structure.  It is signed by the CA, and the
CA needs to be able to vouch for the information in it. =  I=C2=B9m not sure how
the CA knows what level of = assurance qualifier value is appropriate for a
particular = subject.

In the current documents, consider = a PASSporT signer that is associated
with two sets of = caller numbers, where the signer can provide full
assurance = for the first set and partial assurance for the second set.
Then, this signer will need two certificates, one with = id-loa-full and
the other with id-loa-partial, then the = signer must select the
appropriate certificate based on = the caller number.  Really, the CA is
not adding any = value here.

Perhaps it would be better to = remove the level of assurance from the
certificate = altogether.

If we do that, the we would = need to include the level of assurance in the
signed = PASSporT claims.  In this case, the signer would need to include
either loa=3Dfull or loa=3Dpartial, depending on the caller = number.

Either way, the signer is deciding = what level of assurance to include.

What do = others think?

Russ

On Sep 15, 2016, at 12:07 PM, Russ Housley <housley@vigilsec.com> wrote:

I have found a place = where additional clarity is needed in Section 5.1.
The = current text is:

5.1.  Levels Of = Assurance

 This specification supports = different level of assurance (LOA).  The
 LOA = indications, which are Object Identifiers (OIDs) included in the
 certificate's certificate policies extension [RFC5280], = allow CAs to
 differentiate those enrolled from = proof-of-possession versus
 delegation.  A = Certification Policy and a Certification Practice
 Statement [RFC3647] are produced as part of the normal = PKI
 bootstrapping process (i.e., the CP is written = first and then the CAs
 say how they conform to the = CP in the CPS).  OIDs are used to
 reference the = CP and if the CA wishes it can also include a reference
 to the CPS with the certificate policies extension. =  CAs that wish to
 express different LOAs MUST = include the certificate policies
 extension in issued = certificates.  See Section 11 for additional
 information about the LOA registry.

This all makes sense to me, but it does not say whether the = LOA is
inferred from the CertPolicyId or explicitly = carried in the
PolicyQualifierInfo.  I think that the = later is intended because of the
reference to an LOA = registry.  Please confirm that I got that right.

For background, RFC 5280 specifies the following ASN.1 for = the
PolicyQualifierInfo:

 PolicyQualifierInfo ::=3D SEQUENCE {
      policyQualifierId =  PolicyQualifierId,
      qualifier =          ANY DEFINED BY = policyQualifierId }

So, I think we need to = specify a single OID for the LOA
policyQualifierId that is = used in all certificates, and then have the
qualifier = carry an object identifier for the LOA.  Each certificate
policy would list the LOA object identifiers that are = supported.  If
this is the intent, then the IANA = considerations should ask for the
assignment of the = policyQualifierId object identifier.

That = would result in something like this:

 id-qt-loa OBJECT IDENTIFIER ::=3D { id-qt TBD1 }

 id-loa-full OBJECT IDENTIFIER ::=3D { = TBD2 }
 id-loa-partial OBJECT IDENTIFIER ::=3D { TBD3 = }
 id-loa-none OBJECT IDENTIFIER ::=3D { TBD4 }

Comments?

Russ


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_B3C837BE-3A06-45CF-AB68-8C2A8EA38A9E-- From nobody Wed Oct 5 05:40:55 2016 Return-Path: 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 EFC2C1296C3 for ; Wed, 5 Oct 2016 05:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 AnwEV9tILlgV for ; Wed, 5 Oct 2016 05:40:49 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E681296AD for ; Wed, 5 Oct 2016 05:40:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8FE3D300A45 for ; Wed, 5 Oct 2016 08:40:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zJ0mV6IW7qCC for ; Wed, 5 Oct 2016 08:40:44 -0400 (EDT) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id DB7DB3000E0; Wed, 5 Oct 2016 08:40:43 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6531D7AE-F4A6-4615-B825-018A8C1FEF91" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <0DBEF9D6-B2D6-41AE-974B-1659858D69D1@chriswendt.net> Date: Wed, 5 Oct 2016 08:40:43 -0400 Message-Id: References: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> <0DBEF9D6-B2D6-41AE-974B-1659858D69D1@chriswendt.net> To: Chris Wendt , Jon Peterson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] Second WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 12:40:54 -0000 --Apple-Mail=_6531D7AE-F4A6-4615-B825-018A8C1FEF91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Chris: When that delegation occurs, it is done by issuing a certificate. That = certificate may need to contain constraints on the passport claim. That = feels like a much better fit. Russ On Oct 5, 2016, at 8:26 AM, Chris Wendt = wrote: > I agree, delegation does seem to be the right use case for this. >=20 > In SHAKEN framework, we, i think mistakenly, tried to use this policy = indicator for attestation of how the call was originated. While i think = we could have made it work, i think the main problem was that the = attestation is a per call decision and choosing between different = certificates to sign just didn=92t feel right once we started mapping it = out. >=20 > Rather we are going to make the attestation a claim as part of a = passport extension. A per call attestation indicator signed in the = token.=20 >=20 > So i think the concern Russ is expressing I can see and we have = experienced first hand, but i also agree with Jon that there is probably = scenarios where a delegated customer might be signing all calls with a = policy indicator that says, =93we have delegated the authority to sign = calls, so validate the calling identity in that context=94 so keeping it = around is probably ok. >=20 > -Chris >=20 >> On Oct 3, 2016, at 4:37 PM, Peterson, Jon = wrote: >>=20 >>=20 >> So, I definitely agree that it makes sense for an authentication = service >> to select a level of assurance on a per-call basis when it is signing = for >> requests coming from heterogenous points of origin, and that the AS >> shouldn't have to hold multiple certificates with different LoAs to = do >> that. For that reason, I do see the value in specifying a JWT claim = which >> allows authentication services to characterize those different >> originators. I don't think this is such a universally applicable = feature >> that we need that we need to spend another rev to get it into the = baseline >> PASSporT spec, but I can definitely see adding something like that as = an >> extension in the near future. >>=20 >> I'm not sure however that this JWT claim would entirely eliminate the = need >> for a level of assurance indication in the certificate or the >> corresponding proposed registry. In some models, for example, a = number >> owner might delegate authority to a customer, and want to grant the >> customer a credential they could use to sign requests with their own >> authentication service. Moving LoA to PASSporT only works if we = assume >> that any certificate holder has the authority to assign LoAs - but in >> delegation models, the LoA should be constrained by limited authority = of >> the cert. There are other use cases I can think of as well where = having a >> level of assurance in a cert could be meaningful. >>=20 >> But I don't think we need to specify how delegation in the cert would = work >> now: we just need to create the necessary registry in the certs = document. >> Given that we are late in the process here, I'd propose we just do = that >> and let the community do with it what they will. If people end up = never >> using this code point and registry in certs, we won't have gone to = any >> real trouble for it. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> On 10/3/16, 4:48 AM, "stir on behalf of Russ Housley" >> wrote: >>=20 >>> I have been thinking about this some more. I have been uneasy about = this >>> use of policy qualifier, and I think that I have figured out the = source >>> of that concern. >>>=20 >>> The certificate is a signed structure. It is signed by the CA, and = the >>> CA needs to be able to vouch for the information in it. I=B9m not = sure how >>> the CA knows what level of assurance qualifier value is appropriate = for a >>> particular subject. >>>=20 >>> In the current documents, consider a PASSporT signer that is = associated >>> with two sets of caller numbers, where the signer can provide full >>> assurance for the first set and partial assurance for the second = set. >>> Then, this signer will need two certificates, one with id-loa-full = and >>> the other with id-loa-partial, then the signer must select the >>> appropriate certificate based on the caller number. Really, the CA = is >>> not adding any value here. >>>=20 >>> Perhaps it would be better to remove the level of assurance from the >>> certificate altogether. >>>=20 >>> If we do that, the we would need to include the level of assurance = in the >>> signed PASSporT claims. In this case, the signer would need to = include >>> either loa=3Dfull or loa=3Dpartial, depending on the caller number. >>>=20 >>> Either way, the signer is deciding what level of assurance to = include. >>>=20 >>> What do others think? >>>=20 >>> Russ >>>=20 >>> On Sep 15, 2016, at 12:07 PM, Russ Housley = wrote: >>>=20 >>>> I have found a place where additional clarity is needed in Section = 5.1. >>>> The current text is: >>>>=20 >>>> 5.1. Levels Of Assurance >>>>=20 >>>> This specification supports different level of assurance (LOA). = The >>>> LOA indications, which are Object Identifiers (OIDs) included in = the >>>> certificate's certificate policies extension [RFC5280], allow CAs = to >>>> differentiate those enrolled from proof-of-possession versus >>>> delegation. A Certification Policy and a Certification Practice >>>> Statement [RFC3647] are produced as part of the normal PKI >>>> bootstrapping process (i.e., the CP is written first and then the = CAs >>>> say how they conform to the CP in the CPS). OIDs are used to >>>> reference the CP and if the CA wishes it can also include a = reference >>>> to the CPS with the certificate policies extension. CAs that wish = to >>>> express different LOAs MUST include the certificate policies >>>> extension in issued certificates. See Section 11 for additional >>>> information about the LOA registry. >>>>=20 >>>> This all makes sense to me, but it does not say whether the LOA is >>>> inferred from the CertPolicyId or explicitly carried in the >>>> PolicyQualifierInfo. I think that the later is intended because of = the >>>> reference to an LOA registry. Please confirm that I got that = right. >>>>=20 >>>> For background, RFC 5280 specifies the following ASN.1 for the >>>> PolicyQualifierInfo: >>>>=20 >>>> PolicyQualifierInfo ::=3D SEQUENCE { >>>> policyQualifierId PolicyQualifierId, >>>> qualifier ANY DEFINED BY policyQualifierId } >>>>=20 >>>> So, I think we need to specify a single OID for the LOA >>>> policyQualifierId that is used in all certificates, and then have = the >>>> qualifier carry an object identifier for the LOA. Each certificate >>>> policy would list the LOA object identifiers that are supported. = If >>>> this is the intent, then the IANA considerations should ask for the >>>> assignment of the policyQualifierId object identifier. >>>>=20 >>>> That would result in something like this: >>>>=20 >>>> id-qt-loa OBJECT IDENTIFIER ::=3D { id-qt TBD1 } >>>>=20 >>>> id-loa-full OBJECT IDENTIFIER ::=3D { TBD2 } >>>> id-loa-partial OBJECT IDENTIFIER ::=3D { TBD3 } >>>> id-loa-none OBJECT IDENTIFIER ::=3D { TBD4 } >>>>=20 >>>> Comments? >>>>=20 >>>> Russ >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_6531D7AE-F4A6-4615-B825-018A8C1FEF91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Chris:

When that delegation = occurs, it is done by issuing a certificate.  That certificate may = need to contain constraints on the passport claim.  That feels like = a much better = fit.

Russ



On Oct 5, 2016, at 8:26 AM, Chris Wendt <chris-ietf@chriswendt.net>= ; wrote:

I agree, = delegation does seem to be the right use case for this.
In SHAKEN framework, we, i think = mistakenly, tried to use this policy indicator for attestation of how = the call was originated. While i think we could have made it work, i = think the main problem was that the attestation is a per call decision = and choosing between different certificates to sign just didn=92t feel = right once we started mapping it out.

Rather we are going to = make the attestation a claim as part of a passport extension.  A = per call attestation indicator signed in the token. 

So i think the concern = Russ is expressing I can see and we have experienced first hand, but i = also agree with Jon that there is probably scenarios where a delegated = customer might be signing all calls with a policy indicator that says, = =93we have delegated the authority to sign calls, so validate the = calling identity in that context=94 so keeping it around is probably = ok.

-Chris

On Oct 3, 2016, at 4:37 PM, = Peterson, Jon <jon.peterson@neustar.biz> wrote:


So, I definitely = agree that it makes sense for an authentication service
to select a level = of assurance on a per-call basis when it is signing for
requests coming = from heterogenous points of origin, and that the AS
shouldn't have to = hold multiple certificates with different LoAs to do
that. For that = reason, I do see the value in specifying a JWT claim which
allows = authentication services to characterize those different
originators. I = don't think this is such a universally applicable feature
that we need that = we need to spend another rev to get it into the baseline
PASSporT spec, but = I can definitely see adding something like that as an
extension in the = near future.

I'm not sure = however that this JWT claim would entirely eliminate the need
for a level of = assurance indication in the certificate or the
corresponding = proposed registry. In some models, for example, a number
owner might = delegate authority to a customer, and want to grant the
customer a = credential they could use to sign requests with their own
authentication = service. Moving LoA to PASSporT only works if we assume
that any = certificate holder has the authority to assign LoAs - but in
delegation models, = the LoA should be constrained by limited authority of
the cert. There are = other use cases I can think of as well where having a
level of assurance = in a cert could be meaningful.

But I don't think we need to specify how = delegation in the cert would work
now: we just need to create the necessary = registry in the certs document.
Given that we are late in the process = here, I'd propose we just do that
and let the community do with it what = they will. If people end up never
using this code point and registry in = certs, we won't have gone to any
real trouble for it.

Jon Peterson
Neustar, = Inc.

On 10/3/16, 4:48 = AM, "stir on behalf of Russ Housley"
<stir-bounces@ietf.org on behalf of housley@vigilsec.com> wrote:

I have been thinking about = this some more.  I have been uneasy about this
use of = policy qualifier, and I think that I have figured out the source
of that concern.

The certificate = is a signed structure.  It is signed by the CA, and the
CA needs to be able to vouch for the information in it. =  I=B9m not sure how
the CA knows what level of = assurance qualifier value is appropriate for a
particular = subject.

In the current documents, consider = a PASSporT signer that is associated
with two sets of = caller numbers, where the signer can provide full
assurance = for the first set and partial assurance for the second set.
Then, this signer will need two certificates, one with = id-loa-full and
the other with id-loa-partial, then the = signer must select the
appropriate certificate based on = the caller number.  Really, the CA is
not adding any = value here.

Perhaps it would be better to = remove the level of assurance from the
certificate = altogether.

If we do that, the we would = need to include the level of assurance in the
signed = PASSporT claims.  In this case, the signer would need to include
either loa=3Dfull or loa=3Dpartial, depending on the caller = number.

Either way, the signer is deciding = what level of assurance to include.

What do = others think?

Russ

On Sep 15, 2016, at 12:07 PM, Russ Housley <housley@vigilsec.com> wrote:

I have found a place = where additional clarity is needed in Section 5.1.
The = current text is:

5.1.  Levels Of = Assurance

 This specification supports = different level of assurance (LOA).  The
 LOA = indications, which are Object Identifiers (OIDs) included in the
 certificate's certificate policies extension [RFC5280], = allow CAs to
 differentiate those enrolled from = proof-of-possession versus
 delegation.  A = Certification Policy and a Certification Practice
 Statement [RFC3647] are produced as part of the normal = PKI
 bootstrapping process (i.e., the CP is written = first and then the CAs
 say how they conform to the = CP in the CPS).  OIDs are used to
 reference the = CP and if the CA wishes it can also include a reference
 to the CPS with the certificate policies extension. =  CAs that wish to
 express different LOAs MUST = include the certificate policies
 extension in issued = certificates.  See Section 11 for additional
 information about the LOA registry.

This all makes sense to me, but it does not say whether the = LOA is
inferred from the CertPolicyId or explicitly = carried in the
PolicyQualifierInfo.  I think that the = later is intended because of the
reference to an LOA = registry.  Please confirm that I got that right.

For background, RFC 5280 specifies the following ASN.1 for = the
PolicyQualifierInfo:

 PolicyQualifierInfo ::=3D SEQUENCE {
      policyQualifierId =  PolicyQualifierId,
      qualifier =          ANY DEFINED BY = policyQualifierId }

So, I think we need to = specify a single OID for the LOA
policyQualifierId that is = used in all certificates, and then have the
qualifier = carry an object identifier for the LOA.  Each certificate
policy would list the LOA object identifiers that are = supported.  If
this is the intent, then the IANA = considerations should ask for the
assignment of the = policyQualifierId object identifier.

That = would result in something like this:

 id-qt-loa OBJECT IDENTIFIER ::=3D { id-qt TBD1 }

 id-loa-full OBJECT IDENTIFIER ::=3D { = TBD2 }
 id-loa-partial OBJECT IDENTIFIER ::=3D { TBD3 = }
 id-loa-none OBJECT IDENTIFIER ::=3D { TBD4 }

Comments?

Russ


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/m= ailman/listinfo/stir

_______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_____________________________________________= __
stir mailing list
stir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/stir

= --Apple-Mail=_6531D7AE-F4A6-4615-B825-018A8C1FEF91-- From nobody Wed Oct 5 05:42:40 2016 Return-Path: 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 CEFDE1296D1 for ; Wed, 5 Oct 2016 05:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 kX804zXCBgbM for ; Wed, 5 Oct 2016 05:42:33 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 43E701296D8 for ; Wed, 5 Oct 2016 05:42:33 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id n189so143986073qke.0 for ; Wed, 05 Oct 2016 05:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KVMjXUzC/IwUDjYNDxVEEp6IKZi5pEbj+7JS/ziGSK4=; b=aZx+UA9y+HMN6OJ+NKr9sZWuio2pz71mgo3E62w74s3cuwCyopTL/n6Mfrwn6unOGm SKUBBQzPs+oGbgQAGj3QFwieJlE+yZkTqHNdTNZ2cPCGLSaOpnitmRwmkneFOgaNXXe5 tilc7fF7MmRZJqZ83J2SWUfm+uT1cixLjz0Z6oxLJtxf3JM2j3rDiimmuACn9KpoTt/r NeoOCHZcqtn6Vmw5co/5CFPku2ZNBjOatICxn2zYrIyI9Fc5JcqGTPTWcYW0JAywEEYq /0EBk5z/gPzRHunUUpXjvwZzxn18PEthCYSKofC338OsV+fx48NbRbq9p+zTxaywxONH FJQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KVMjXUzC/IwUDjYNDxVEEp6IKZi5pEbj+7JS/ziGSK4=; b=ejT6vaT4W58gES6spvGFmcaU0r1pE/FHqvaLpbvXypVl0JyC2ABEO6FIAguhbH9xkT a0h356xQvoIi+rPhxWIum4WH48MYMaVp4+VnOkFCo3RbvlXfBnpC22woKci3ZU3QR+ya S5yu7TuALm+LTFnk07zB2x9Eq3ywx+v+nH371Vxq34MC6GD3AexmS3LBh3MP6iqe4KtS LYUgQPPyd/6xwKehsM+OtPdaRRETzI52uLEq6fKKayCZig0TZVkV5bgBy8ohC/0h9RhN 284pHJgrjZLHimSw2w221tP8nkjkCp8QGYDZgXIQLeVdLYVVo/pQvnViHj8Hnn/3r4tD WIKg== X-Gm-Message-State: AA6/9RnEvQMctToQ/6WYSgFOG/BELSPpVBKE8cvTw/PwHfWYeJ+h+3etBBHIf3hyPa3XjQ== X-Received: by 10.55.21.164 with SMTP id 36mr9144384qkv.215.1475671352298; Wed, 05 Oct 2016 05:42:32 -0700 (PDT) Received: from [10.233.63.217] (c-68-33-79-65.hsd1.md.comcast.net. [68.33.79.65]) by smtp.gmail.com with ESMTPSA id o65sm3410473qkc.48.2016.10.05.05.42.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 05:42:31 -0700 (PDT) From: Chris Wendt Message-Id: <26716A99-5000-4165-9D1C-238864D505C9@chriswendt.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_169886FB-1962-4BA1-8710-007EF9BC34A9" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Wed, 5 Oct 2016 08:42:30 -0400 In-Reply-To: To: Russ Housley References: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> <0DBEF9D6-B2D6-41AE-974B-1659858D69D1@chriswendt.net> X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF STIR Mail List , Jon Peterson Subject: Re: [stir] Second WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 12:42:38 -0000 --Apple-Mail=_169886FB-1962-4BA1-8710-007EF9BC34A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agree > On Oct 5, 2016, at 8:40 AM, Russ Housley wrote: >=20 > Chris: >=20 > When that delegation occurs, it is done by issuing a certificate. = That certificate may need to contain constraints on the passport claim. = That feels like a much better fit. >=20 > Russ >=20 >=20 >=20 > On Oct 5, 2016, at 8:26 AM, Chris Wendt > wrote: >=20 >> I agree, delegation does seem to be the right use case for this. >>=20 >> In SHAKEN framework, we, i think mistakenly, tried to use this policy = indicator for attestation of how the call was originated. While i think = we could have made it work, i think the main problem was that the = attestation is a per call decision and choosing between different = certificates to sign just didn=E2=80=99t feel right once we started = mapping it out. >>=20 >> Rather we are going to make the attestation a claim as part of a = passport extension. A per call attestation indicator signed in the = token.=20 >>=20 >> So i think the concern Russ is expressing I can see and we have = experienced first hand, but i also agree with Jon that there is probably = scenarios where a delegated customer might be signing all calls with a = policy indicator that says, =E2=80=9Cwe have delegated the authority to = sign calls, so validate the calling identity in that context=E2=80=9D so = keeping it around is probably ok. >>=20 >> -Chris >>=20 >>> On Oct 3, 2016, at 4:37 PM, Peterson, Jon > wrote: >>>=20 >>>=20 >>> So, I definitely agree that it makes sense for an authentication = service >>> to select a level of assurance on a per-call basis when it is = signing for >>> requests coming from heterogenous points of origin, and that the AS >>> shouldn't have to hold multiple certificates with different LoAs to = do >>> that. For that reason, I do see the value in specifying a JWT claim = which >>> allows authentication services to characterize those different >>> originators. I don't think this is such a universally applicable = feature >>> that we need that we need to spend another rev to get it into the = baseline >>> PASSporT spec, but I can definitely see adding something like that = as an >>> extension in the near future. >>>=20 >>> I'm not sure however that this JWT claim would entirely eliminate = the need >>> for a level of assurance indication in the certificate or the >>> corresponding proposed registry. In some models, for example, a = number >>> owner might delegate authority to a customer, and want to grant the >>> customer a credential they could use to sign requests with their own >>> authentication service. Moving LoA to PASSporT only works if we = assume >>> that any certificate holder has the authority to assign LoAs - but = in >>> delegation models, the LoA should be constrained by limited = authority of >>> the cert. There are other use cases I can think of as well where = having a >>> level of assurance in a cert could be meaningful. >>>=20 >>> But I don't think we need to specify how delegation in the cert = would work >>> now: we just need to create the necessary registry in the certs = document. >>> Given that we are late in the process here, I'd propose we just do = that >>> and let the community do with it what they will. If people end up = never >>> using this code point and registry in certs, we won't have gone to = any >>> real trouble for it. >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>> On 10/3/16, 4:48 AM, "stir on behalf of Russ Housley" >>> on behalf of = housley@vigilsec.com > wrote: >>>=20 >>>> I have been thinking about this some more. I have been uneasy = about this >>>> use of policy qualifier, and I think that I have figured out the = source >>>> of that concern. >>>>=20 >>>> The certificate is a signed structure. It is signed by the CA, and = the >>>> CA needs to be able to vouch for the information in it. I=C2=B9m = not sure how >>>> the CA knows what level of assurance qualifier value is appropriate = for a >>>> particular subject. >>>>=20 >>>> In the current documents, consider a PASSporT signer that is = associated >>>> with two sets of caller numbers, where the signer can provide full >>>> assurance for the first set and partial assurance for the second = set. >>>> Then, this signer will need two certificates, one with id-loa-full = and >>>> the other with id-loa-partial, then the signer must select the >>>> appropriate certificate based on the caller number. Really, the CA = is >>>> not adding any value here. >>>>=20 >>>> Perhaps it would be better to remove the level of assurance from = the >>>> certificate altogether. >>>>=20 >>>> If we do that, the we would need to include the level of assurance = in the >>>> signed PASSporT claims. In this case, the signer would need to = include >>>> either loa=3Dfull or loa=3Dpartial, depending on the caller number. >>>>=20 >>>> Either way, the signer is deciding what level of assurance to = include. >>>>=20 >>>> What do others think? >>>>=20 >>>> Russ >>>>=20 >>>> On Sep 15, 2016, at 12:07 PM, Russ Housley > wrote: >>>>=20 >>>>> I have found a place where additional clarity is needed in Section = 5.1. >>>>> The current text is: >>>>>=20 >>>>> 5.1. Levels Of Assurance >>>>>=20 >>>>> This specification supports different level of assurance (LOA). = The >>>>> LOA indications, which are Object Identifiers (OIDs) included in = the >>>>> certificate's certificate policies extension [RFC5280], allow CAs = to >>>>> differentiate those enrolled from proof-of-possession versus >>>>> delegation. A Certification Policy and a Certification Practice >>>>> Statement [RFC3647] are produced as part of the normal PKI >>>>> bootstrapping process (i.e., the CP is written first and then the = CAs >>>>> say how they conform to the CP in the CPS). OIDs are used to >>>>> reference the CP and if the CA wishes it can also include a = reference >>>>> to the CPS with the certificate policies extension. CAs that = wish to >>>>> express different LOAs MUST include the certificate policies >>>>> extension in issued certificates. See Section 11 for additional >>>>> information about the LOA registry. >>>>>=20 >>>>> This all makes sense to me, but it does not say whether the LOA is >>>>> inferred from the CertPolicyId or explicitly carried in the >>>>> PolicyQualifierInfo. I think that the later is intended because = of the >>>>> reference to an LOA registry. Please confirm that I got that = right. >>>>>=20 >>>>> For background, RFC 5280 specifies the following ASN.1 for the >>>>> PolicyQualifierInfo: >>>>>=20 >>>>> PolicyQualifierInfo ::=3D SEQUENCE { >>>>> policyQualifierId PolicyQualifierId, >>>>> qualifier ANY DEFINED BY policyQualifierId } >>>>>=20 >>>>> So, I think we need to specify a single OID for the LOA >>>>> policyQualifierId that is used in all certificates, and then have = the >>>>> qualifier carry an object identifier for the LOA. Each = certificate >>>>> policy would list the LOA object identifiers that are supported. = If >>>>> this is the intent, then the IANA considerations should ask for = the >>>>> assignment of the policyQualifierId object identifier. >>>>>=20 >>>>> That would result in something like this: >>>>>=20 >>>>> id-qt-loa OBJECT IDENTIFIER ::=3D { id-qt TBD1 } >>>>>=20 >>>>> id-loa-full OBJECT IDENTIFIER ::=3D { TBD2 } >>>>> id-loa-partial OBJECT IDENTIFIER ::=3D { TBD3 } >>>>> id-loa-none OBJECT IDENTIFIER ::=3D { TBD4 } >>>>>=20 >>>>> Comments? >>>>>=20 >>>>> Russ >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir = >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir = >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 --Apple-Mail=_169886FB-1962-4BA1-8710-007EF9BC34A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Agree

On Oct 5, 2016, at 8:40 AM, = Russ Housley <housley@vigilsec.com> wrote:

Chris:

When that delegation = occurs, it is done by issuing a certificate.  That certificate may = need to contain constraints on the passport claim.  That feels like = a much better fit.

Russ



On Oct 5, 2016, at 8:26 AM, Chris Wendt = <chris-ietf@chriswendt.net> wrote:

I agree, delegation does seem to be the right use case for = this.

In SHAKEN = framework, we, i think mistakenly, tried to use this policy indicator = for attestation of how the call was originated. While i think we could = have made it work, i think the main problem was that the attestation is = a per call decision and choosing between different certificates to sign = just didn=E2=80=99t feel right once we started mapping it out.

Rather = we are going to make the attestation a claim as part of a passport = extension.  A per call attestation indicator signed in the = token. 

So = i think the concern Russ is expressing I can see and we have experienced = first hand, but i also agree with Jon that there is probably scenarios = where a delegated customer might be signing all calls with a policy = indicator that says, =E2=80=9Cwe have delegated the authority to sign = calls, so validate the calling identity in that context=E2=80=9D so = keeping it around is probably ok.

-Chris

On Oct 3, 2016, at 4:37 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:


So, I definitely = agree that it makes sense for an authentication service
to select a level = of assurance on a per-call basis when it is signing for
requests coming = from heterogenous points of origin, and that the AS
shouldn't have to = hold multiple certificates with different LoAs to do
that. For that = reason, I do see the value in specifying a JWT claim which
allows = authentication services to characterize those different
originators. I = don't think this is such a universally applicable feature
that we need that = we need to spend another rev to get it into the baseline
PASSporT spec, but = I can definitely see adding something like that as an
extension in the = near future.

I'm not sure = however that this JWT claim would entirely eliminate the need
for a level of = assurance indication in the certificate or the
corresponding = proposed registry. In some models, for example, a number
owner might = delegate authority to a customer, and want to grant the
customer a = credential they could use to sign requests with their own
authentication = service. Moving LoA to PASSporT only works if we assume
that any = certificate holder has the authority to assign LoAs - but in
delegation models, = the LoA should be constrained by limited authority of
the cert. There are = other use cases I can think of as well where having a
level of assurance = in a cert could be meaningful.

But I don't think we need to specify how = delegation in the cert would work
now: we just need to create the necessary = registry in the certs document.
Given that we are late in the process = here, I'd propose we just do that
and let the community do with it what = they will. If people end up never
using this code point and registry in = certs, we won't have gone to any
real trouble for it.

Jon Peterson
Neustar, = Inc.

On 10/3/16, 4:48 = AM, "stir on behalf of Russ Housley"
<stir-bounces@ietf.org on behalf of housley@vigilsec.com> wrote:

I have been thinking about = this some more.  I have been uneasy about this
use of = policy qualifier, and I think that I have figured out the source
of that concern.

The certificate = is a signed structure.  It is signed by the CA, and the
CA needs to be able to vouch for the information in it. =  I=C2=B9m not sure how
the CA knows what level of = assurance qualifier value is appropriate for a
particular = subject.

In the current documents, consider = a PASSporT signer that is associated
with two sets of = caller numbers, where the signer can provide full
assurance = for the first set and partial assurance for the second set.
Then, this signer will need two certificates, one with = id-loa-full and
the other with id-loa-partial, then the = signer must select the
appropriate certificate based on = the caller number.  Really, the CA is
not adding any = value here.

Perhaps it would be better to = remove the level of assurance from the
certificate = altogether.

If we do that, the we would = need to include the level of assurance in the
signed = PASSporT claims.  In this case, the signer would need to include
either loa=3Dfull or loa=3Dpartial, depending on the caller = number.

Either way, the signer is deciding = what level of assurance to include.

What do = others think?

Russ

On Sep 15, 2016, at 12:07 PM, Russ Housley <housley@vigilsec.com> wrote:

I have found a place = where additional clarity is needed in Section 5.1.
The = current text is:

5.1.  Levels Of = Assurance

 This specification supports = different level of assurance (LOA).  The
 LOA = indications, which are Object Identifiers (OIDs) included in the
 certificate's certificate policies extension [RFC5280], = allow CAs to
 differentiate those enrolled from = proof-of-possession versus
 delegation.  A = Certification Policy and a Certification Practice
 Statement [RFC3647] are produced as part of the normal = PKI
 bootstrapping process (i.e., the CP is written = first and then the CAs
 say how they conform to the = CP in the CPS).  OIDs are used to
 reference the = CP and if the CA wishes it can also include a reference
 to the CPS with the certificate policies extension. =  CAs that wish to
 express different LOAs MUST = include the certificate policies
 extension in issued = certificates.  See Section 11 for additional
 information about the LOA registry.

This all makes sense to me, but it does not say whether the = LOA is
inferred from the CertPolicyId or explicitly = carried in the
PolicyQualifierInfo.  I think that the = later is intended because of the
reference to an LOA = registry.  Please confirm that I got that right.

For background, RFC 5280 specifies the following ASN.1 for = the
PolicyQualifierInfo:

 PolicyQualifierInfo ::=3D SEQUENCE {
      policyQualifierId =  PolicyQualifierId,
      qualifier =          ANY DEFINED BY = policyQualifierId }

So, I think we need to = specify a single OID for the LOA
policyQualifierId that is = used in all certificates, and then have the
qualifier = carry an object identifier for the LOA.  Each certificate
policy would list the LOA object identifiers that are = supported.  If
this is the intent, then the IANA = considerations should ask for the
assignment of the = policyQualifierId object identifier.

That = would result in something like this:

 id-qt-loa OBJECT IDENTIFIER ::=3D { id-qt TBD1 }

 id-loa-full OBJECT IDENTIFIER ::=3D { = TBD2 }
 id-loa-partial OBJECT IDENTIFIER ::=3D { TBD3 = }
 id-loa-none OBJECT IDENTIFIER ::=3D { TBD4 }

Comments?

Russ


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_____________________________________________= __
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir


= --Apple-Mail=_169886FB-1962-4BA1-8710-007EF9BC34A9-- From nobody Wed Oct 5 16:33:13 2016 Return-Path: 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 15E25129476 for ; Wed, 5 Oct 2016 16:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.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 9xG5dHVxeMw2 for ; Wed, 5 Oct 2016 16:33:11 -0700 (PDT) Received: from rgout02.bt.lon5.cpcloud.co.uk (rgout0207.bt.lon5.cpcloud.co.uk [65.20.0.206]) by ietfa.amsl.com (Postfix) with ESMTP id 97A0F129424 for ; Wed, 5 Oct 2016 16:33:10 -0700 (PDT) X-OWM-Source-IP: 10.110.12.2 () X-OWM-Env-Sender: nweinronk@btinternet.com X-Junkmail-Premium-Raw: score=14/50, refid=2.7.2:2016.10.5.231218:17:14.906, ip=, rules=__CSHC_RCVD, __HAS_FROM, __FRAUD_WEBMAIL_FROM, FROM_NAME_ALLCAPS, __HAS_REPLYTO, __FRAUD_WEBMAIL_REPLYTO, __TO_MALFORMED_2, __TO_NO_NAME, __HAS_MSGID, __SANE_MSGID, INVALID_MSGID_NO_FQDN, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_PRIORITY, __REPLYTO_SAMEAS_FROM_ADDY, __REPLYTO_SAMEAS_FROM_ACC, __REPLYTO_SAMEAS_FROM_DOMAIN, __TO_IN_SUBJECT, __MIME_TEXT_P2, __MIME_TEXT_H2, __FRAUD_CONTACT_NAME, __HAS_HTML, HTML_NO_HTTP, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_3000_MORE, BODYTEXTH_SIZE_10000_LESS, __MIME_TEXT_H1, __MIME_TEXT_P1, __MIME_HTML, HTML_70_90, __FRAUD_WEBMAIL, NO_URI_FOUND, NO_CTA_URI_FOUND, __PHISH_SPEAR_STRUCTURE_1, PRIORITY_NO_NAME, TO_IN_SUBJECT, __MIME_TEXT_H, __MIME_TEXT_P, NO_URI_HTTPS Received: from webmail39.bt.ext.cpcloud.co.uk (10.110.12.2) by rgout02.bt.lon5.cpcloud.co.uk (9.0.019.07.01-1) (authenticated as nweinronk@btinternet.com) id 57F4D2C7001AE005 for stir@ietf.org; Thu, 6 Oct 2016 00:33:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1475710390; bh=4JkJ4UFkcMV7imPb+EXEUOdvt4UGD8hSZcOULBzosco=; h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version; b=fplhuUc3LPuT3TdgG4qwZc+GoGTAtR0HWWc9KnEvKxBdi+A8EjITMGDD88Ywd3lJK0lIgq9THOw6Khsmg5gMX7FRv/gJEibuivewKscISypmXvwtpnkfDJTxqgj7Kp84Eb198EZL1VrlCWf7tXdNzFHX5vqnG8OYdAI9895Qypw= Date: Thu, 6 Oct 2016 00:33:09 +0100 (BST) From: N WEINRONK To: stir@ietf.org Message-ID: <24430040.96568.1475710389106.JavaMail.defaultUser@defaultHost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_96567_26113098.1475710389077" Importance: 3 (Normal) X-Priority: 3 (Normal) X-Client-IP: IPv4[86.170.189.203] Epoch[1475710389078] Archived-At: Subject: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nweinronk@btinternet.com List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 23:33:13 -0000 ------=_Part_96567_26113098.1475710389077 Content-Type: multipart/alternative; boundary="----=_Part_96566_16340547.1475710389077" ------=_Part_96566_16340547.1475710389077 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for this document. =20 I have some comments on this version. =20 =20 4.1.1 para 2: I note the recommendation of the compact form of PASSporT here.=20 I do have concern over B2BUAs actions on Date header. Will B2BUA actions (stripping / replacing this header) actually mean that everyone in reality will have to use the full format of PASSporT anyway and probably wi= thout does the repeat after failure on the compact form ? =20 =20 General: Use of the =E2=80=9Cdest=E2=80=9D identity: I am aware of some services that alter the To header =E2=80=93 for example 3GPP diversion service can do this =E2=80=93 does this mean that we= should remove reliance on =E2=80=9Cdest=E2=80=9D ? Is there any privacy concern with allowing the =E2=80=98verification service=E2=80=99 to identify the original =E2=80=98to header=E2=80=99 (full= form) when the request could have been redirected ? I am aware of some service codes that have * and # not just as the leading number dialled eg. *24#1# - again could we do anything to remov= e reliance on =E2=80=98dest=E2=80=99 ? =20 =20 6.1 step 3: Certain features can cause INVITEs to arrive at terminating UA more than 1 minute after the call originated =E2=80=93 for e= xample diversion chains - these would fail the 60 second logic but are valid calls. =20 =20 6.2 step 1: Identity request =E2=80=93> Identity header ?=20 =20 =20 6.2 step 1: Here we ignore not supported ppt but above we reject them =E2=80=93 which is correct ? =20 =20 6.2 step 4: =E2=80=9Ciat=E2=80=9D value is later =E2=80=93 do you really me= an earlier here not later =E2=80=93 I think you are trying to cover the case where the= Date header has been added along the way so will the =E2=80=9Ciat=E2=80=9D not be earli= er ? =20 =20 6.2 step 5: typo =E2=80=93 that the that the =20 =20 8 last para: Reword around - could itself could =20 =20 8 para 2: Would you expect the p-asserted-id in the PASSporT to be in a different field than the 1 the From is in so it can be distingui= shed at the terminating end ? =20 =20 8.3 Why is the ABNF here limited to 1 DIGIT =E2=80=93 in fact do you need tn-spec in this version of the document ? =20 =20 11 para 5: I am a little confused here before in the document you talked about using p-asserted-id instead of from (section 8) but now I think this is a different case =E2=80=93 but it is not clear to me. =20 Thanks, Nigel ------=_Part_96566_16340547.1475710389077 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=

Thanks for this document.

=  

= I have some comments on this version.

=  

=  

= 4.1.1 para 2: I note the recommendation of the compact form of PASSporT here.

I do have concern over B2BUAs actions on Date header. Will B2BUA actions (stripping / replacing this header) actually mean that everyone in reality will have to use the full format of PASSporT anyway and probably without does the repeat after failure on the compact = form ?

=  

=  

= General: Use of the =E2=80=9Cdest=E2=80=9D identity:

= I am aware of some services that alter the To header =E2=80=93 for example 3GPP diversion service can do this =E2=80=93 does this mean that we= should remove reliance on =E2=80=9Cdest=E2=80=9D ?

= Is there any privacy concern with allowing the =E2=80=98verification service=E2=80=99 to identify the original =E2=80=98to header=E2=80=99 (full= form) when the request could have been redirected ?

= I am aware of some service codes that have * and # not just as the leading number dialled eg. *24#1# - again could we do anything to remov= e reliance on =E2=80=98dest=E2=80=99 ?

 

=  

= 6.1 step 3: Certain features can cause INVITEs to arrive at terminating UA more than 1 minute after the call originated =E2=80=93 for e= xample diversion chains - these would fail the 60 second logic but are valid calls.

=  

=  

= 6.2 step 1: Identity request =E2=80=93> Identity header ?

=  

=  

= 6.2 step 1: Here we ignore not supported ppt but above we reject them =E2=80=93 which is correct ?

=  

=  

= 6.2 step 4: =E2=80=9Ciat=E2=80=9D value is later =E2=80=93 do you really me= an earlier here not later =E2=80=93 I think you are trying to cover the case where the= Date header has been added along the way so will the =E2=80=9Ciat=E2=80=9D not be earli= er ?

=  

=  

= 6.2 step 5: typo =E2=80=93 that the that the

=  

=  

= 8 last para: Reword around - could itself could

=  

=  

= 8 para 2: Would you expect the p-asserted-id in the PASSporT to be in a different field than the 1 the From is in so it can be distingui= shed at the terminating end ?

=  

=  

= 8.3 Why is the ABNF here limited to 1 DIGIT =E2=80=93 in fact do you need tn-spec in this version of the document ?

=  

=  

= 11 para 5: I am a little confused here before in the document you talked about using p-asserted-id instead of from (section 8) but now I think this is a different case =E2=80=93 but it is not clear to me.<= /p>

=

 

= Thanks,

= Nigel


------=_Part_96566_16340547.1475710389077-- ------=_Part_96567_26113098.1475710389077-- From nobody Thu Oct 6 16:02:19 2016 Return-Path: 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 50D2D1295DB for ; Thu, 6 Oct 2016 16:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 Bm3EdIZfWKx2 for ; Thu, 6 Oct 2016 16:02:16 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2295129582 for ; Thu, 6 Oct 2016 16:02:16 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u96MqjAx026350; Thu, 6 Oct 2016 19:02:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar.biz; bh=8M8nFdS9qRfXqPbsVWHNl2o4NeU27OwLddiQeciEb0w=; b=yVrt1wKiiz+0eIZLt+nRnohucIv9V5N/ebkpRgocLPPoeFWS8jq21A3yy1Ydc9VZm6Sc lxZXKJCnJiKKCaDznIlkK/3q9ScAKIUBT6/KcTTfGtSQftML/P2Gu+jhum4oiwUlOqZR TLCBP9UpEYYZnO42eRrm1N5GLD1p0al5b/j6/rOlM+fAEF7cofy1WIezDXtOGjGwh2yc zEqa9sVLfAR8Br9HXyRrHTnpI4nop5AzJeT7BGfJxqaXijHzdO5hF5qVJfdk0LlssGN/ kdBJwwJA+xpuxiobOgr4zQnEo2iFMC85R+JhDTPBdBZCJmPeg3xjTs0pSu4tP68xbe9f 3A== Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 25wj314wyn-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 06 Oct 2016 19:02:15 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.225]) with mapi id 14.03.0279.002; Thu, 6 Oct 2016 19:02:14 -0400 From: "Peterson, Jon" To: Anders Kristensen , "stir@ietf.org" Thread-Topic: [stir] Comments on draft-ietf-stir-certificates-08 Thread-Index: AQHSHQRHgAUn/aJa6U+CGG4o045+qKCcEUyA Date: Thu, 6 Oct 2016 23:02:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.13.30] Content-Type: multipart/alternative; boundary="_000_D41BD82F1BBDBAjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-06_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610060400 Archived-At: Subject: Re: [stir] Comments on draft-ietf-stir-certificates-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 23:02:18 -0000 --_000_D41BD82F1BBDBAjonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Appreciate the nit fixes here; a few responses on more substantial points. * 7: My preference would be to not list support for SIP as mandatory for in= fo URIs. Using SUBSCRIBE/NOTIFY feels contrived and unnecessary. The reason we included this back when was for future compatibility with pot= ential systems that would let you subscribe to certificates and receive upd= ates when they were changed: we imagined this might make sense for some hig= h-volume verification services. Given how far down the OCSP path this docum= ent goes today, perhaps that isn't strictly necessary - but I can still ima= gine deployments where it make might sense. Supporting SIP is basically fre= e for SIP implementations, so it doesn't seem like much of a burden to keep= this option open. * 7: OTOH using data: might make sense. Avoids cid: issue with non-multipar= t support. I don't think we'd want to make that data URL yet another parameter of the = Identity header, which is already getting quite long with a full form PASSp= orT. I don't think it's unreasonable to have a way to carry a certificate b= y-value in a header, though I'd look to future work for that. * 8: So TNAuthorizationList is List>. Why can't it just be Li= st? The original justification for this, I think I dimly recall, was that we we= re going to have other categories than TNAuthorizationList under TNAuthoriz= ation - but that was many moons ago. I think at this point we can safely co= llapse that down into one level. * 8: I'm not sure if ServiceProviderIdentifierList is supposed to contain S= PID, Alt SPID and Last Alt SPID in that order. For example, if a cert conta= ins a TNEntry with a spid of length 2 then those two entries would be expec= ted to match SPID and Alt SPID of the calling number respectively? It hadn't occurred to me that the order might be significant to relying par= ties. Is there any reason it would be? As far as I know, the question is wh= ether the relying party trusts any of the SPIDs that might appear in this a= rray; the ordering shouldn't be significant. * 9.2: ISTM that if OCSP is always used to check freshness of TN auth lists= then the actual content of the list is irrelevant. The authority check has= just been delegated to the CA... Agreed that if you use OCSP the way this section describes, then yes, the c= ert is basically just delivering you the tools to query OCSP, and you might= as well not even bother including the TN Authorization List. I think that = at best, in these cases, the TN Authorization List might be used for an ini= tial sanity check before incurring the RTT of checking OCSP. Including the = TN Authorization List by value probably more useful for single telephone nu= mbers than for ranges, in any event. Jon Peterson Neustar, Inc. --_000_D41BD82F1BBDBAjonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <783AF8269010FF4687DDA7625D5824D8@neustar.biz> Content-Transfer-Encoding: quoted-printable

Appreciate the nit fixes here; a few responses on more substantial poi= nts.

* 7: My preference w= ould be to not list support for SIP as mandatory for info URIs. Using SUBSC= RIBE/NOTIFY feels contrived and unnecessary.

The reason we included this back when was for future compatibility wit= h potential systems that would let you subscribe to certificates and receiv= e updates when they were changed: we imagined this might make sense for som= e high-volume verification services. Given how far down the OCSP path this document goes today, perhaps that is= n't strictly necessary - but I can still imagine deployments where it make = might sense. Supporting SIP is basically free for SIP implementations, so i= t doesn't seem like much of a burden to keep this option open.

* 7: OTOH using data= : might make sense. Avoids cid: issue with non-multipart support.

I don't think we'd want to make that data URL yet another parameter of= the Identity header, which is already getting quite long with a full form = PASSporT. I don't think it's unreasonable to have a way to carry a certific= ate by-value in a header, though I'd look to future work for that.

* 8: So TNAuthorizat= ionList is List<List<TNEntry>>. Why can't it just be List<TN= Entry>?

The original justification for this, I think I dimly recall, was that = we were going to have other categories than TNAuthorizationList under TNAut= horization - but that was many moons ago. I think at this point we can safe= ly collapse that down into one level.

* 8: I'm not sure if= ServiceProviderIdentifierList is supposed to contain SPID, Alt SPID and La= st Alt SPID in that order. For example, if a cert contains a TNEntry with a= spid of length 2 then those two entries would be expected to match SPID and Alt SPID of the calling number respect= ively?

It hadn't occurred to me that the order might be significant to relyin= g parties. Is there any reason it would be? As far as I know, the question = is whether the relying party trusts any of the SPIDs that might appear in t= his array; the ordering shouldn't be significant.

* 9.2: ISTM that if = OCSP is always used to check freshness of TN auth lists then the actual con= tent of the list is irrelevant. The authority check has just been delegated= to the CA...

Agreed that if you use OCSP the way this section describes, then yes, = the cert is basically just delivering you the tools to query OCSP, and you = might as well not even bother including the TN Authorization List. I think = that at best, in these cases, the TN Authorization List might be used for an initial sanity check before inc= urring the RTT of checking OCSP. Including the TN Authorization List by val= ue probably more useful for single telephone numbers than for ranges, in an= y event.

Jon Peterson
Neustar, Inc.
--_000_D41BD82F1BBDBAjonpetersonneustarbiz_-- From nobody Thu Oct 6 16:03:22 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D5B1294A4; Thu, 6 Oct 2016 16:03:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147579499730.23836.1281835671176470754.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2016 16:03:17 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-certificates-09.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 23:03:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Secure Telephone Identity Credentials: Certificates Authors : Jon Peterson Sean Turner Filename : draft-ietf-stir-certificates-09.txt Pages : 23 Date : 2016-10-06 Abstract: In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-certificates-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-certificates-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 6 17:03:15 2016 Return-Path: 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 A98C81294E2 for ; Thu, 6 Oct 2016 17:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 ABvJTT8-sAy3 for ; Thu, 6 Oct 2016 17:03:12 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 7D3861294DC for ; Thu, 6 Oct 2016 17:03:12 -0700 (PDT) Received: (qmail 14872 invoked by uid 0); 7 Oct 2016 00:03:09 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 7 Oct 2016 00:03:09 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id sPy51t00n1MNPNq01Py8p4; Thu, 06 Oct 2016 17:58:09 -0600 X-Authority-Analysis: v=2.1 cv=efGuId0H c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=1oJP67jkp3AA:10 a=CH0kA5CcgfcA:10 a=ZZnuYtJkoWoA:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=HmCT5iXHAAAA:8 a=MONI1RiiIFPMRQMy4w0A:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=u9063_s84hYA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=43sUurYG_G3sDUy-GQgA:9 a=1CI4DwNOCdOkFxhE:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=4zOjnXqnbfPznnZ39DHr:22 a=BKKCjISod1eDJeS0ORpz:22 a=zjWhRoSqWz9hl55Hdlzg:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:Message-ID:To:From: Subject:Date; bh=KNJ7Vm6HgJJEAGCjkLfahxWffRBAsr7cWFCZDHCbao8=; b=MmpU5mmjxS8A 6+vBimqi0HxJn1+M7w07ASBi00hwglCjEzzRGhPZJ3NPfx73ZFtlnkboEzTKVYcB/uWoYePEOEhTD cswUiIX82a+AxPL3eFgbzT9ApdwET5t2YNXdonC; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:64142 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1bsIY9-0004hh-Oc for stir@ietf.org; Thu, 06 Oct 2016 17:58:05 -0600 User-Agent: Microsoft-MacOutlook/f.1a.1.160916 Date: Thu, 06 Oct 2016 19:58:03 -0400 From: Richard Shockey To: IETF STIR Mail List Message-ID: <5C775124-3C87-4725-9545-404E08770022@shockey.us> Thread-Topic: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt In-Reply-To: <24430040.96568.1475710389106.JavaMail.defaultUser@defaultHost> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3558628685_307880279" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1bsIY9-0004hh-Oc X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:64142 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 00:03:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3558628685_307880279 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable In line=20 =20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 =20 From: stir on behalf of N WEINRONK Reply-To: Date: Wednesday, October 5, 2016 at 7:33 PM To: Subject: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt =20 =20 Thanks for this document. =20 I have some comments on this version. =20 =20 4.1.1 para 2: I note the recommendation of the compact form of PASSporT her= e.=20 I do have concern over B2BUAs actions on Date header. Will B2BUA actions (s= tripping / replacing this header) actually mean that everyone in reality wil= l have to use the full format of PASSporT anyway and probably without does t= he repeat after failure on the compact form ? =20 =20 RS> In the United States carrier profile of STIR aka SHAKEN, you must use t= he full form of PASSporT. There will be more on this after October 26. =20 =20 =20 _________________________________ stir mailing list stir@ietf.org https://w= ww.ietf.org/mailman/listinfo/stir=20 --B_3558628685_307880279 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

In line

=

&= nbsp;

— 

Richard Shockey=

Shockey Co= nsulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org=

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101<= /span>

PSTN +1 703= -593-2683

 

 =

From: stir= <stir-bounces@ietf.org> on behalf of N WEINRONK <nweinronk@btinter= net.com>
Reply-To: <nweinronk@btinternet.com>
Date:= Wednesday, October 5, 2016 at 7:33 PM
To: <stir@ietf.org&g= t;
Subject: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt

 

 

Thanks f= or this document.

 

I hav= e some comments on this version.

 

 

4.1.1 para 2: I note the recommendat= ion of the compact form of PASSporT here.

I do have = concern over B2BUAs actions on Date header. Will B2BUA actions (stripping / = replacing this header) actually mean that everyone in reality will have to u= se the full format of PASSporT anyway and probably without does the repeat a= fter failure on the compact form ?

 <= /span>

 

RS> In the United States carrie= r profile of STIR aka SHAKEN, you must use the full form of PASSporT.  =   There will be more on this after October 26. 

 

 

_________________________________ stir mailing list stir@ietf.or= g https://www.ietf.org/mailman/listinfo/stir

--B_3558628685_307880279-- From nobody Fri Oct 7 07:27:36 2016 Return-Path: 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 D469C12962A for ; Fri, 7 Oct 2016 07:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 IslTXsG7EmBm for ; Fri, 7 Oct 2016 07:27:34 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16BA12960F for ; Fri, 7 Oct 2016 07:27:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 41B75300A3F for ; Fri, 7 Oct 2016 10:27:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jU6ioYeKS0MH for ; Fri, 7 Oct 2016 10:27:32 -0400 (EDT) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 3E96D3002BA for ; Fri, 7 Oct 2016 10:27:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Fri, 7 Oct 2016 10:27:32 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: To: IETF STIR Mail List X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [stir] Third WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 14:27:36 -0000 A revised document to address the issues raised in the second WG Last Call has been posted. (https://www.ietf.org/id/draft-ietf-stir-rfc4474bis-13.txt). This message starts a third WG Last Call for this document, but unlike the two earlier WG Last Calls, this one will be for one week. It ends on 14 October 2016. Please review the document and send comments on it to the STIR WG mail list. Please clearly state your opinion as to whether the document is ready for publication as a standards-track RFC. Remember that support for publication is needed, so if you think the document is ready to go forward, please say so. Thanks, Russ & Robert From nobody Fri Oct 7 07:29:51 2016 Return-Path: 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 8C65D129625 for ; Fri, 7 Oct 2016 07:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 CwOlxZi-q_qH for ; Fri, 7 Oct 2016 07:29:48 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2255D12960F for ; Fri, 7 Oct 2016 07:29:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 831E1300A32 for ; Fri, 7 Oct 2016 10:29:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xbiTPilWn_1s for ; Fri, 7 Oct 2016 10:29:46 -0400 (EDT) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 6064B3002BA for ; Fri, 7 Oct 2016 10:29:46 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Oct 2016 10:29:09 -0400 Message-Id: <67B01470-D522-4519-A1C2-CF22160DC5FF@vigilsec.com> To: IETF STIR Mail List Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [stir] Third WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF STIR Mail List List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 14:29:49 -0000 A revised document to address the issues raised in the second WG Last = Call has been posted. = (https://www.ietf.org/id/draft-ietf-stir-certificates-09.txt). This message starts a third WG Last Call for this document, but unlike = the two earlier WG Last Calls, this one will be for one week. It ends on 14 October 2016. Please review the document and send comments on it to the STIR WG mail list. Please clearly state your opinion as to whether the document is ready for publication as a standards-track RFC. Remember that support for publication is needed, so if you think the document is ready to go forward, please say so. Thanks, Russ & Robert From nobody Fri Oct 7 07:30:37 2016 Return-Path: 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 0C372129625 for ; Fri, 7 Oct 2016 07:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 7CbeIV3ZUv9l for ; Fri, 7 Oct 2016 07:30:34 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C8E129609 for ; Fri, 7 Oct 2016 07:30:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0CCC1300A32 for ; Fri, 7 Oct 2016 10:30:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EecNBfQ9aaA2 for ; Fri, 7 Oct 2016 10:30:33 -0400 (EDT) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 05F823002BA for ; Fri, 7 Oct 2016 10:30:32 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 7 Oct 2016 10:30:27 -0400 Message-Id: <9CF2DE1E-2A1B-4475-ABBD-BFCA8015E7C8@vigilsec.com> To: IETF STIR Mail List Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [stir] Third WG Last Call for PASSporT Document X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF STIR Mail List List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 14:30:36 -0000 A revised document to address the issues raised in the second WG Last Call has been posted. (https://www.ietf.org/id/draft-ietf-stir-passport-08.txt). This message starts a third WG Last Call for this document, but unlike the two earlier WG Last Calls, this one will be for one week. It ends on 14 October 2016. Please review the document and send comments on it to the STIR WG mail list. Please clearly state your opinion as to whether the document is ready for publication as a standards-track RFC. Remember that support for publication is needed, so if you think the document is ready to go forward, please say so. Thanks, Russ & Robert From nobody Fri Oct 7 10:26:00 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AA3129683; Fri, 7 Oct 2016 10:25:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147586115935.8896.1319111797200431049.idtracker@ietfa.amsl.com> Date: Fri, 07 Oct 2016 10:25:59 -0700 Archived-At: Cc: stir@ietf.org, alissa@cooperw.in, stir-chairs@ietf.org, smccammon@amsl.com Subject: [stir] stir - Update to a Meeting Session Request for IETF 97 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:25:59 -0000 An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the stir working group. --------------------------------------------------------- Working Group Name: Secure Telephone Identity Revisited Area Name: Applications and Real-Time Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: lamps acme tls ecrit avtcore dane siprec p2psip rtcweb mmusic sipcore dispatch appsawg ice modern ipwave sipbrandy curdle Second Priority: perc slim netvc clue tcpinc cose uta ace saag oauth Special Requests: Monday/Tuesday if possible --------------------------------------------------------- From nobody Fri Oct 7 12:45:23 2016 Return-Path: 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 C09AD1293F8 for ; Fri, 7 Oct 2016 12:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 xZCwQkOvC9tJ for ; Fri, 7 Oct 2016 12:45:20 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 0596E1293D8 for ; Fri, 7 Oct 2016 12:45:19 -0700 (PDT) Received: (qmail 19929 invoked by uid 0); 7 Oct 2016 19:45:18 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy1.mail.unifiedlayer.com with SMTP; 7 Oct 2016 19:45:18 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id sjgA1t00B1MNPNq01jgDSE; Fri, 07 Oct 2016 13:40:17 -0600 X-Authority-Analysis: v=2.1 cv=beT4Do/B c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=CH0kA5CcgfcA:10 a=ZZnuYtJkoWoA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=tGX7uwomAAAA:8 a=EWo9a3_1IEYrn1SoTo0A:9 a=H0pEkAwp7Fhnp2eg:21 a=nCqMlP95Zn1--n9d:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=ZFOOzkjxzLGrPE5HuMia:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date; bh=7Hm5TN1DL7xQXZETKeyxGUPijNO/NQ8hYfrOtSKu77s=; b=eNm+kjv3p6ENK3aA2LeQBl8CsB JF1X+OBc9/9e/RZ1jeP9dQntWsJ1vUykruuyfmqEzfvAicbKVTjpeRiqnpHuQzF9CxPb+xicHxsKy pPOtaMwjl5LAGx33OYFhDYY1v; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:51045 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1bsaQ2-00068i-Fb for stir@ietf.org; Fri, 07 Oct 2016 13:02:54 -0600 User-Agent: Microsoft-MacOutlook/f.1a.1.160916 Date: Fri, 07 Oct 2016 15:02:52 -0400 From: Richard Shockey To: IETF STIR Mail List Message-ID: <98F6D0CA-5D85-42E9-96FF-875D3A74CF52@shockey.us> Thread-Topic: [stir] Third WG Last Call for RFC4474bis References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1bsaQ2-00068i-Fb X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:51045 X-Source-Auth: richard+shockey.us X-Email-Count: 6 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [stir] Third WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 19:45:22 -0000 IMHO ready for publication. =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 On 10/7/16, 10:27 AM, "stir on behalf of Russ Housley" wrote: =20 A revised document to address the issues raised in the second WG Last C= all has been posted. (https://www.ietf.org/id/draft-ietf-stir-rfc4474bis-13= .txt). =20 This message starts a third WG Last Call for this document, but unlike = the two earlier WG Last Calls, this one will be for one week. It ends on 14 October 2016. =20 Please review the document and send comments on it to the STIR WG mail list. Please clearly state your opinion as to whether the document is ready for publication as a standards-track RFC. Remember that support for publication is needed, so if you think the document is ready to go forward, please say so. =20 Thanks, Russ & Robert =20 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir =20 From nobody Fri Oct 7 12:49:39 2016 Return-Path: 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 39405129432 for ; Fri, 7 Oct 2016 12:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 tEFpcu1Kknzh for ; Fri, 7 Oct 2016 12:49:35 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 27C0312941A for ; Fri, 7 Oct 2016 12:49:35 -0700 (PDT) Received: (qmail 22351 invoked by uid 0); 7 Oct 2016 19:49:35 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 7 Oct 2016 19:49:35 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id sjkY1t0011MNPNq01jkb10; Fri, 07 Oct 2016 13:44:35 -0600 X-Authority-Analysis: v=2.1 cv=KLfJUj1o c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=CH0kA5CcgfcA:10 a=ZZnuYtJkoWoA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=tGX7uwomAAAA:8 a=FXrVMzA55T8QgALr7W0A:9 a=RZ2fkh7nRo-ayEqN:21 a=nCqMlP95Zn1--n9d:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=ZFOOzkjxzLGrPE5HuMia:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date; bh=J+9u7JNkb/v0IlRIkyBdpBYghiqWpeGXOOwOSWY+oM4=; b=RaVqh/CHbw0296Kshs49qaC0Ms dqUsOf/w/dIEq9d1oD6jg07v1R2WBWQfrYac2Pfavl6+FgIzToOZ5dvx2KghuYjbLgN7nAD/cgRuG 8nBFeTM7erjC7bBWk8DpCv04o; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:51045 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1bsaQE-00068i-Un for stir@ietf.org; Fri, 07 Oct 2016 13:03:07 -0600 User-Agent: Microsoft-MacOutlook/f.1a.1.160916 Date: Fri, 07 Oct 2016 15:03:06 -0400 From: Richard Shockey To: IETF STIR Mail List Message-ID: <5A0AD89D-44DB-4DA5-ADA0-897386762589@shockey.us> Thread-Topic: [stir] Third WG Last Call for STIR Certificates Document References: <67B01470-D522-4519-A1C2-CF22160DC5FF@vigilsec.com> In-Reply-To: <67B01470-D522-4519-A1C2-CF22160DC5FF@vigilsec.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1bsaQE-00068i-Un X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:51045 X-Source-Auth: richard+shockey.us X-Email-Count: 6 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [stir] Third WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 19:49:37 -0000 Ready for publication.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 On 10/7/16, 10:29 AM, "stir on behalf of Russ Housley" wrote: =20 A revised document to address the issues raised in the second WG Last C= all has been posted. (https://www.ietf.org/id/draft-ietf-stir-certificates-= 09.txt). =20 This message starts a third WG Last Call for this document, but unlike = the two earlier WG Last Calls, this one will be for one week. It ends on 14 October 2016. =20 Please review the document and send comments on it to the STIR WG mail list. Please clearly state your opinion as to whether the document is ready for publication as a standards-track RFC. Remember that support for publication is needed, so if you think the document is ready to go forward, please say so. =20 Thanks, Russ & Robert =20 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir =20 From nobody Fri Oct 7 12:51:49 2016 Return-Path: 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 EBBE81296FE for ; Fri, 7 Oct 2016 12:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 MjFC41XXp3JI for ; Fri, 7 Oct 2016 12:51:47 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 2BBA51296FB for ; Fri, 7 Oct 2016 12:51:47 -0700 (PDT) Received: (qmail 23612 invoked by uid 0); 7 Oct 2016 19:51:47 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 7 Oct 2016 19:51:47 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id sjmk1t00R1MNPNq01jmnLo; Fri, 07 Oct 2016 13:46:47 -0600 X-Authority-Analysis: v=2.1 cv=KLfJUj1o c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=CH0kA5CcgfcA:10 a=ZZnuYtJkoWoA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=tGX7uwomAAAA:8 a=FXrVMzA55T8QgALr7W0A:9 a=39KPBQxwvFdobY12:21 a=nCqMlP95Zn1--n9d:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=ZFOOzkjxzLGrPE5HuMia:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date; bh=mGNmDaNY9k661QPyy2XjZIWpG3i1Mq25t83R18OVUNE=; b=nRFjF0t5uyKkQceQ86hPY+j0A2 YbBFhitRe4PhgoY/eKapLrmCAPCdngZBmsEJNzCGtEAVvTv4RCjN3M40MuzM6V8K667zg16Zu3pP4 2cwcxQVwstSnMS6/FuIKKIehw; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:51045 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1bsaQR-00068i-Q7 for stir@ietf.org; Fri, 07 Oct 2016 13:03:19 -0600 User-Agent: Microsoft-MacOutlook/f.1a.1.160916 Date: Fri, 07 Oct 2016 15:03:19 -0400 From: Richard Shockey To: IETF STIR Mail List Message-ID: <0DA94ABF-E2FE-4434-B297-C83139402093@shockey.us> Thread-Topic: [stir] Third WG Last Call for PASSporT Document References: <9CF2DE1E-2A1B-4475-ABBD-BFCA8015E7C8@vigilsec.com> In-Reply-To: <9CF2DE1E-2A1B-4475-ABBD-BFCA8015E7C8@vigilsec.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1bsaQR-00068i-Q7 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:51045 X-Source-Auth: richard+shockey.us X-Email-Count: 6 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [stir] Third WG Last Call for PASSporT Document X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 19:51:49 -0000 Ready for publication.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 On 10/7/16, 10:30 AM, "stir on behalf of Russ Housley" wrote: =20 A revised document to address the issues raised in the second WG Last C= all has been posted. (https://www.ietf.org/id/draft-ietf-stir-passport-08.t= xt). =20 This message starts a third WG Last Call for this document, but unlike = the two earlier WG Last Calls, this one will be for one week. It ends on 14 October 2016. =20 Please review the document and send comments on it to the STIR WG mail list. Please clearly state your opinion as to whether the document is ready for publication as a standards-track RFC. Remember that support for publication is needed, so if you think the document is ready to go forward, please say so. =20 Thanks, Russ & Robert =20 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir =20 From nobody Sat Oct 8 11:16:03 2016 Return-Path: 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 DE3CD12954F; Sat, 8 Oct 2016 11:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 BTTrOKJoNP5A; Sat, 8 Oct 2016 11:16:00 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1039129508; Sat, 8 Oct 2016 11:15:59 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 8 Oct 2016 11:29:10 -0700 From: Jim Schaad To: Date: Sat, 8 Oct 2016 11:15:45 -0700 Message-ID: <065e01d2218f$fea323b0$fbe96b10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdIg4gF4XR18IpbFR76cpVd45Z1JXQ== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: stir@ietf.org Subject: [stir] draft-ietf-stir-passport-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 18:16:02 -0000 Here is a review of the document as a whole. * Section 4 - para 3 - The term "key values" is potentially ambiguous. This could refer either to the value of the key or the value the key is pointing to. I would suggest making this clear. * Section 4 - para 3 - The form you are using for encoding of claims values has two problems. The first is that this does not match what the JSON document says to use "\uXXXX". The second is that as written, it is ambiguous. If I have the US-ASCII string of "%ABCD" then it does not need to be percent encoded as the string is not outside of the US-ASCII range. * Section 4.2.1 - General - I am having a hard time with this section because it is not highlighting the last piece of information that I think I need to understand for this. From what I read, I think that dest == aud in terms of JWT - that is the target of the statement. Orig == iss in terms of JWT - that is the entity that issued the statement. I don't see anything that is telling me what the sub of the JWT is supposed to be. It would also be good to say why different items are being defined that appear to be the same thing as already exist in JWT terms. (Yes, at the core it is because the types are different.) * Section 4.2.X - you are not telling me that these are arrays of "some type" rather than the "some type". * Section 4.2.2 - You are stating that things must occur in a specific order. This is not "normal" JSON behavior and not all JSON serializers may be able to support this behavior. I think you need some justification someplace. * Section 5 - I am having a hard time finding the lexicographic order and white space rules quickly. A pointer might be reasonable. * Section 7 - One issue that I think you need to address in the extension section is that signaling protocols need to identify what these new items are so that they can be picked up and placed into the PASSporT when it is reconstructed. The destination does not have to understand the extension, but it does need to understand that the extension exists. * Section 8 - You have a problem in that there are no rules in RFC 7638 for dealing with serialization of integers. Given that some of the fields in the JWT are integers this needs to be addressed. You might want to move this justification to the top of the document so that people are prepared for and look for this. * Section 8 - Wording problem with saying that "dest" and "mky" need to follow their OWN rules. Are these really defined elsewhere or do you just use the standard rules recursively. * Section 9.2 - Consider using a list structure for the asterisk leading list in this section. * Section 10.1.1 - Encoding Considerations - This could be 7 bit as the value is base64 encoded for normal values and would be UTF8 if you used the full JOSE signature structure which you do not. * General - I was really tired when I read through this and I kept getting tripped up on prose. I did not write down all of the items which bothered me and now I have read it enough that it is harder for me to locate them. However, I would request that the authors perform some method of detailed reading to check for this. I frequently read the text aloud to myself for this purpose. Alternatively, you can just wait for the copy editors. Jim From nobody Tue Oct 11 04:08:08 2016 Return-Path: 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 4F1CD1294A4 for ; Tue, 11 Oct 2016 04:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6oLo_VHYp6si for ; Tue, 11 Oct 2016 04:08:04 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 E2CA6127058 for ; Tue, 11 Oct 2016 04:08:03 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id l131so3397441lfl.2 for ; Tue, 11 Oct 2016 04:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=lESU3a6wl9pPoNc6Cemza1UXT0MDFp1lRTnLBKFZvgo=; b=hmw3n+DqggBXxVVaAYoCk3k6NjolirlM3UEtnOuE6PMKdbV5BHaPzV6T0yanO/G9ME pr7m7P2xDFp9+JbLXM9AZHsBZikHu6rZNPznDzNawFqyiq3vYjX9A9cSH5zWKEaAKaat qio5JtqxoyB7S+bAAYAvdXlaO87/MeEjLxxaBLRCKUCS25oaBKM+9XGmZ9I3ZHKTvvLr 8kKiv+QCoAPnXiaqgc8BZc9X7TzGTL6ZjQzOBsS+oO5ouVlt0gdCweLxcPgidTOdFWS+ BDk4LT3zZTYXEA6GMFd7rbyWetv3SC9saZdNTSscgbGBhbgPRtjhSRbbu5m4oI34NJvz gYkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=lESU3a6wl9pPoNc6Cemza1UXT0MDFp1lRTnLBKFZvgo=; b=WtmZjOLQ6sF2qaIVwHnPwr6HbPdvUkU2GZqM6SYKCsn0PVxf8l8RUg83cbGl4bRzg1 YhEuxGGkLOlFB2NUd7fmkdEpfyRdmgWKlKa6lbDfdno9q5UTfq8RfyNBSHLrek53rkPN qoX4igiLPzIWMGAaarsJkurpRaeiv1hihezuXUrK217fSBm+l6elIJ6QN6YTuMSbwqiw 3Ox6e3h2nzLSvFGeNlihsKDWCvJBj7Qg47nxJSpAJmNg0XG8H7rBSU8t9LMO8D77CkOY WtblF2f22HcqyvPxADcv1zTllyo0obsMVEw4djUzXIU7NY7qz0Hpi1c4tdxnmDCRG7yh lKCQ== X-Gm-Message-State: AA6/9Rk+VQOYRwRAB1Yq0215a15+LuHmjhuDgAf5yE1/geX3xCFCXJOa328AFHYn6k5vYw== X-Received: by 10.194.178.200 with SMTP id da8mr4294817wjc.157.1476184079983; Tue, 11 Oct 2016 04:07:59 -0700 (PDT) Received: from alans-mbp.lan ([37.152.254.14]) by smtp.gmail.com with ESMTPSA id za1sm1426589wjb.8.2016.10.11.04.07.58 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Oct 2016 04:07:59 -0700 (PDT) From: Alan Ford Content-Type: multipart/alternative; boundary="Apple-Mail=_0BDCC820-069A-4F3F-A4B3-04CE953ACC3D" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Tue, 11 Oct 2016 12:09:25 +0100 References: To: stir@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [stir] Nits in draft-ietf-stir-passport-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 11:08:07 -0000 --Apple-Mail=_0BDCC820-069A-4F3F-A4B3-04CE953ACC3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agree on the 4.2.1 feedback, and indeed there's some small rewording = which could be done in Section 4.2.1 to make this easier to understand = (IMHO anyway): The "dest" JSON object MUST have at least have one key value pair, but could have multiple identity types (i.e. "tn" and/or "uri") but only one of each. If both "tn" and "uri" are included, the JSON object should list the "tn" array first and the "uri" array second. Within the "tn" and "uri" arrays, the identity strings should be put in lexicographical order including the scheme-specific portion of the URI characters. Additionally, in the case of "dest" only, the identity type key value MUST be an array signaled by standard JSON brackets, even when there is a single identity value in the identity type key value. The requirement to be an array should be introduced earlier, since = it=E2=80=99s mentioned in passing half way through and only confirmed at = the end. Instead I=E2=80=99d propose putting a second sentence in, = something like this, and then losing the last sentence: The "dest" JSON object MUST have at least have one key value pair, but could have multiple identity types (i.e. "tn" and/or "uri") but only one of each. Each value in the key value pair is an array,=20 containing one or more identity strings of this identity type. If = both "tn=E2=80=9D=20 and "uri" are included, the JSON object should list the "tn" array = first=20 and the "uri" array second. Within the "tn" and "uri" arrays, the=20 identity strings should be put in lexicographical order, including = the=20 scheme-specific portion of the URI characters. =20 Other than that this, I have re-read this document again and it reads = well and I believe it to be ready for publication. Regards, Alan > On 3 Oct 2016, at 00:25, Anders Kristensen wrote: >=20 >=20 > * 4.2.1: s/only have one/have exactly one/ ? >=20 > The "orig" JSON object MUST only have one key value pair >=20 > * 4.2.1.4 : Why is "Single Originator", "Single = Destination" etc. capitalized? >=20 > * 5: "above" is actually below (also in Section 8). >=20 > For the JWS Payload and the JWS Protected Header, > the lexicographic ordering and white space rules described above, = and > JSON serialization rules in Section 8 = of = this document MUST be > followed. >=20 > * 8.1: Delete leading whitespace: >=20 > {"dest":{"uri":["sip:alice@example.com = "],"iat":1443208345,"mky": > = [{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD5 > = 4F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F82183B5 > 40212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}], > "orig":{"tn":"12155551212"}} >=20 > * 9.1: s/the the/the/ >=20 > * 9.2: Looks like this paragraph was meant to be rendered as a = bulleted list. >=20 > * 9.2: s/the end user the asserted identity represents/the end user = represented by the asserted identity/ >=20 > * 12.1: I think technically speaking this doc does not depend on = 4474bis so could make that ref informational. >=20 > * App A: Remove leading whitespace: >=20 > {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org = > /passport.cer"} > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_0BDCC820-069A-4F3F-A4B3-04CE953ACC3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Agree on the 4.2.1 feedback, and indeed = there's some small rewording which could be done in Section 4.2.1 to = make this easier to understand (IMHO anyway):

   The "dest" =
JSON object MUST have at least have one key value pair,
   but could have multiple identity types (i.e. "tn" and/or "uri") but
   only one of each.  If both "tn" and "uri" are included, the JSON
   object should list the "tn" array first and the "uri" array second.
   Within the "tn" and "uri" arrays, the identity strings should be put
   in lexicographical order including the scheme-specific portion of the
   URI characters.  Additionally, in the case of "dest" only, the
   identity type key value MUST be an array signaled by standard JSON
   brackets, even when there is a single identity value in the identity
   type key value.

The requirement to be an array should be introduced earlier, = since it=E2=80=99s mentioned in passing half way through and only = confirmed at the end. Instead I=E2=80=99d propose putting a second = sentence in, something like this, and then losing the last = sentence:

   The "dest" JSON object MUST have at least have = one key value pair,
   but could have = multiple identity types (i.e. "tn" and/or "uri") but
   only one of each.  Each value in the key = value pair is an array, 
  =  containing one or more identity strings of this identity type. If = both "tn=E2=80=9D 
   and "uri" are = included, the JSON object should list the "tn" array = first 
   and the "uri" array = second. Within the "tn" and "uri" arrays, the 
   identity strings should be put in = lexicographical order, including the 
  =  scheme-specific portion of the URI characters.  

Other than that this, I have re-read = this document again and it reads well and I believe it to be ready for = publication.

Regards,
Alan

On = 3 Oct 2016, at 00:25, Anders Kristensen <andersk@google.com> = wrote:


* 4.2.1: s/only have one/have exactly = one/ ?

The "orig" JSON object MUST only have one key value =
pair
*= 4.2.1.4: Why is "Single = Originator", "Single Destination" etc. capitalized?

* = 5: "above" is actually below (also in Section 8).

   For the JWS Payload =
and the JWS Protected Header,
   the lexicographic ordering and white space rules described above, and
   JSON serialization rules in Section 8 of this document MUST be
   followed.

* 8.1: Delete leading = whitespace:

   {"dest":{"uri":["sip:alice@example.com"],"iat":1443208345,"mky":
     [{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD5
     4F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F82183B5
     40212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}],
     "orig":{"tn":"12155551212"}}

* 9.1: s/the = the/the/

* = 9.2: Looks like this paragraph was meant to be rendered as a bulleted = list.

* = 9.2: s/the end user the asserted identity represents/the end user = represented by the asserted identity/

* 12.1: I think = technically speaking this doc does not depend on 4474bis so could make = that ref informational.

* App A: Remove = leading whitespace:

   {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org=

       /passport.cer"}
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_0BDCC820-069A-4F3F-A4B3-04CE953ACC3D-- From nobody Wed Oct 12 12:28:52 2016 Return-Path: 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 06F6C129653 for ; Wed, 12 Oct 2016 12:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 qnws7jKw9uYw for ; Wed, 12 Oct 2016 12:28:37 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 1D8A512965F for ; Wed, 12 Oct 2016 12:28:37 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id n189so50701453qke.0 for ; Wed, 12 Oct 2016 12:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nhqlVm7aCc6hZi9ht6mRG/1z8J7nWvS2YXexo9kunvE=; b=zhGuLdv1Idp36F9uoz/57AZn379OUqkbBSj0OR7vJj8ecKNOUMdIefgy8KIf7e7C41 03PT63vwjgOFfwIbwJt1Leinx6mJIEslsbpjEIucO6AIk0lTddISnavEY1QNkZrSId91 Vz5mk1x2gAzRGdyOtfe/boP2FOW1SooAxRYa9HlxqydHomosSgYCe/8mYV/ZEtJDn3Lo wiFz4RoGBTjPgLf23QVdYdowo93CW31wnOxtfg7oXN5wAXKslMp6Zy6a6d0VpmcSEjLC St6R9RwTLRz4egxZQjzlwX3t4deUW6eEJeD1sulIBKHf7PRKLO8jjexL5ElVxQqNlOeg jjdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nhqlVm7aCc6hZi9ht6mRG/1z8J7nWvS2YXexo9kunvE=; b=bXJZvQGhHLMdpQr2/IZVGql3XEl9mNC+K4zc5tD6zLcXpciM1kebv2pNPNIXpAMhU8 Qrsycj+6iW1t/zKHML5BcYiVvBdpuRjgnqyj9Oy7zbCfF7GqJLsD2Pu5nEh5/LBSOdJ9 MFjcgYcCdamTRoDQM/GxslIjaEYJS+T1y4bJtg4mzCZ7Wkagqo5MECRUqYuk0lYbJEap DRzGZePRO8T0Nl1T7AZZ/E//IxuFr5aZxH3v2TF7bjy968eQaodJpp6vLOYq2BeHVPib 2QfqxZ5V1x+Qmf02kDiP3eOEi1RS9fNbOA7eROUttg1FNX82ObB6wQDnLwkPx028UdTw 6nwQ== X-Gm-Message-State: AA6/9RmKoPE4fE/0CZ7RrKCZLLMHp9/owe6a11v1uAYpvi3FTYZ10YV5wEjVlh5XEpwL2A== X-Received: by 10.55.49.203 with SMTP id x194mr2780239qkx.94.1476300516190; Wed, 12 Oct 2016 12:28:36 -0700 (PDT) Received: from ?IPv6:2601:a40:100:d3:34fe:c9ba:a1aa:6ddf? ([2601:a40:100:d3:34fe:c9ba:a1aa:6ddf]) by smtp.gmail.com with ESMTPSA id u4sm3291770qka.9.2016.10.12.12.28.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Oct 2016 12:28:35 -0700 (PDT) From: Chris Wendt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_42182400-55CF-4E5D-8CF6-0DF9ABEEE329" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Wed, 12 Oct 2016 15:28:35 -0400 In-Reply-To: To: Alan Ford References: X-Mailer: Apple Mail (2.3226) Archived-At: Cc: stir@ietf.org Subject: Re: [stir] Nits in draft-ietf-stir-passport-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 19:28:46 -0000 --Apple-Mail=_42182400-55CF-4E5D-8CF6-0DF9ABEEE329 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Alan, Yes that is more appropriate, I will incorporate that change in wording. = =20 > On Oct 11, 2016, at 7:09 AM, Alan Ford wrote: >=20 > Agree on the 4.2.1 feedback, and indeed there's some small rewording = which could be done in Section 4.2.1 to make this easier to understand = (IMHO anyway): >=20 > The "dest" JSON object MUST have at least have one key value pair, > but could have multiple identity types (i.e. "tn" and/or "uri") but > only one of each. If both "tn" and "uri" are included, the JSON > object should list the "tn" array first and the "uri" array second. > Within the "tn" and "uri" arrays, the identity strings should be = put > in lexicographical order including the scheme-specific portion of = the > URI characters. Additionally, in the case of "dest" only, the > identity type key value MUST be an array signaled by standard JSON > brackets, even when there is a single identity value in the = identity > type key value. >=20 > The requirement to be an array should be introduced earlier, since = it=E2=80=99s mentioned in passing half way through and only confirmed at = the end. Instead I=E2=80=99d propose putting a second sentence in, = something like this, and then losing the last sentence: >=20 > The "dest" JSON object MUST have at least have one key value pair, > but could have multiple identity types (i.e. "tn" and/or "uri") but > only one of each. Each value in the key value pair is an array,=20 > containing one or more identity strings of this identity type. If = both "tn=E2=80=9D=20 > and "uri" are included, the JSON object should list the "tn" array = first=20 > and the "uri" array second. Within the "tn" and "uri" arrays, the=20= > identity strings should be put in lexicographical order, including = the=20 > scheme-specific portion of the URI characters. =20 >=20 > Other than that this, I have re-read this document again and it reads = well and I believe it to be ready for publication. >=20 > Regards, > Alan >=20 >> On 3 Oct 2016, at 00:25, Anders Kristensen > wrote: >>=20 >>=20 >> * 4.2.1: s/only have one/have exactly one/ ? >>=20 >> The "orig" JSON object MUST only have one key value pair >>=20 >> * 4.2.1.4 : Why is "Single Originator", "Single = Destination" etc. capitalized? >>=20 >> * 5: "above" is actually below (also in Section 8). >>=20 >> For the JWS Payload and the JWS Protected Header, >> the lexicographic ordering and white space rules described above, = and >> JSON serialization rules in Section 8 = of = this document MUST be >> followed. >>=20 >> * 8.1: Delete leading whitespace: >>=20 >> {"dest":{"uri":["sip:alice@example.com = "],"iat":1443208345,"mky": >> = [{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD5 >> = 4F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F82183B5 >> 40212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}], >> "orig":{"tn":"12155551212"}} >>=20 >> * 9.1: s/the the/the/ >>=20 >> * 9.2: Looks like this paragraph was meant to be rendered as a = bulleted list. >>=20 >> * 9.2: s/the end user the asserted identity represents/the end user = represented by the asserted identity/ >>=20 >> * 12.1: I think technically speaking this doc does not depend on = 4474bis so could make that ref informational. >>=20 >> * App A: Remove leading whitespace: >>=20 >> {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org = >> /passport.cer"} >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_42182400-55CF-4E5D-8CF6-0DF9ABEEE329 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Alan,

Yes that is more appropriate, I will incorporate that change = in wording.  


On Oct 11, 2016, at 7:09 AM, Alan Ford <alan.ford@gmail.com>= wrote:

Agree on the 4.2.1 feedback, and indeed there's some small = rewording which could be done in Section 4.2.1 to make this easier to = understand (IMHO anyway):

   The "dest" JSON object MUST have at least =
have one key value pair,
   but could have multiple identity types (i.e. "tn" and/or "uri") but
   only one of each.  If both "tn" and "uri" are included, the JSON
   object should list the "tn" array first and the "uri" array second.
   Within the "tn" and "uri" arrays, the identity strings should be put
   in lexicographical order including the scheme-specific portion of the
   URI characters.  Additionally, in the case of "dest" only, the
   identity type key value MUST be an array signaled by standard JSON
   brackets, even when there is a single identity value in the identity
   type key value.

The requirement to be an array should be introduced earlier, = since it=E2=80=99s mentioned in passing half way through and only = confirmed at the end. Instead I=E2=80=99d propose putting a second = sentence in, something like this, and then losing the last = sentence:

   The "dest" JSON object MUST have at least have = one key value pair,
   but could have = multiple identity types (i.e. "tn" and/or "uri") but
   only one of each.  Each value in the key = value pair is an array, 
  =  containing one or more identity strings of this identity type. If = both "tn=E2=80=9D 
   and "uri" are = included, the JSON object should list the "tn" array = first 
   and the "uri" array = second. Within the "tn" and "uri" arrays, the 
   identity strings should be put in = lexicographical order, including the 
  =  scheme-specific portion of the URI characters.  

Other than that this, I have re-read = this document again and it reads well and I believe it to be ready for = publication.

Regards,
Alan

On 3 Oct = 2016, at 00:25, Anders Kristensen <andersk@google.com> = wrote:


* 4.2.1: s/only have one/have exactly = one/ ?

The "orig" JSON object MUST only have one key value =
pair
*= 4.2.1.4: Why is "Single = Originator", "Single Destination" etc. capitalized?

* = 5: "above" is actually below (also in Section 8).

   For the JWS Payload =
and the JWS Protected Header,
   the lexicographic ordering and white space rules described above, and
   JSON serialization rules in Section 8 of this document MUST be
   followed.

* 8.1: Delete leading = whitespace:

   {"dest":{"uri":["sip:alice@example.com"],"iat":1443208345,"mky":
     [{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD5
     4F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F82183B5
     40212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}],
     "orig":{"tn":"12155551212"}}

* 9.1: s/the = the/the/

* = 9.2: Looks like this paragraph was meant to be rendered as a bulleted = list.

* = 9.2: s/the end user the asserted identity represents/the end user = represented by the asserted identity/

* 12.1: I think = technically speaking this doc does not depend on 4474bis so could make = that ref informational.

* App A: Remove = leading whitespace:

   {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org=

       /passport.cer"}
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_42182400-55CF-4E5D-8CF6-0DF9ABEEE329-- From nobody Wed Oct 12 12:31:34 2016 Return-Path: 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 8FDA712965D for ; Wed, 12 Oct 2016 12:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 3BtDPxpVJFPi for ; Wed, 12 Oct 2016 12:31:30 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 6B311129657 for ; Wed, 12 Oct 2016 12:31:30 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id f6so27103581qtd.2 for ; Wed, 12 Oct 2016 12:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mEZq4jVR8BzT56Aw6eY/OjzKRTyvBWtkAMwjj5hX4T4=; b=uJwjIgzGHxv2okUegoJt4wZKXdJ6bk0i9iNIRplYt1hZvKdyhSxziNVfF5fwOdnx5q UDUfDmYxNBeGyQ/TmlOtG/zUeur48PvrS2JuuJrQOKBP6c2Y5vzASN7gTqTgjH1o6NA2 OdPA+MKxrmuXdmsSCa2jW9kWOJRrle3ZuFxrSG4zRe/UKvzIOfAWAYKzXc98egVfqlZd nKPReGqRq3T+GaS2kO3JyjvWwxLilnVi4ZUtG56DGt6BPVdHI4lTYoW9GBQ2UGCeU/9Q 9H3oOpzPIY392W/ppQDFhQ3wMXLRXAd+SH3o2qbNKliSZKkKOXG3m8OxpShKl3fY+Dy5 0S+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mEZq4jVR8BzT56Aw6eY/OjzKRTyvBWtkAMwjj5hX4T4=; b=A6FNwnbOxMwRLczc0aMNWRpMCRPqfLHKzIvSIZg7rzDdxbpP+Y8D41IUzGe3tjqmWE 8yTTmwOYc8veLosY1WjIE/QQ5rDoVfMINBvIDEDZUngMRbAC5Ny73kop7MvT3BJgtgnc dJGvoDpfPpmpCHVQQ81clU663Kr7EznkO5akPchMI4JQ9tUNCS8phL1ZcCaJ9LIszc8W xRnnD9MzU9B3jPDdYN6wG+kRgysv3AWsNNHSI1Ll89963zzySJhJNuIi6GfCWhC3uWo0 /Y4ASDKQ2UGoy1DFBffHAI+fTRh71fihCPsKZe6VWvbG58wX1v1JrNqGo8F/2HQRcv1C E7Hg== X-Gm-Message-State: AA6/9Rk9nS/WKDZpuRHSaY8fHKrzu36m9JyDWgWo8d5tdaZmZzm9xYeq6JjfPq7aWnq+Ng== X-Received: by 10.200.50.215 with SMTP id a23mr3010651qtb.79.1476300689531; Wed, 12 Oct 2016 12:31:29 -0700 (PDT) Received: from ?IPv6:2601:a40:100:d3:34fe:c9ba:a1aa:6ddf? ([2601:a40:100:d3:34fe:c9ba:a1aa:6ddf]) by smtp.gmail.com with ESMTPSA id 65sm2179795qth.0.2016.10.12.12.31.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Oct 2016 12:31:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Chris Wendt In-Reply-To: <065e01d2218f$fea323b0$fbe96b10$@augustcellars.com> Date: Wed, 12 Oct 2016 15:31:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <065e01d2218f$fea323b0$fbe96b10$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3226) Archived-At: Cc: stir@ietf.org, draft-ietf-stir-passport@ietf.org Subject: Re: [stir] draft-ietf-stir-passport-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 19:31:32 -0000 HI Jim,=20 Thanks for the comprehensive review. I am working through some of the = fixes based on your comments. Meanwhile i have the following responses inline. -Chris > On Oct 8, 2016, at 2:15 PM, Jim Schaad wrote: >=20 > Here is a review of the document as a whole. >=20 > * Section 4 - para 3 - The term "key values" is potentially ambiguous. = This > could refer either to the value of the key or the value the key is = pointing > to. I would suggest making this clear. I will use the term =E2=80=9Cclaim value=E2=80=9D which is a RFC 7519 = term. One additional question is whether we say same thing for =E2=80=9Cc= laim name=E2=80=9D as well? I suppose we allow it. >=20 > * Section 4 - para 3 - The form you are using for encoding of claims = values > has two problems. The first is that this does not match what the JSON > document says to use "\uXXXX". The second is that as written, it is > ambiguous. If I have the US-ASCII string of "%ABCD" then it does not = need > to be percent encoded as the string is not outside of the US-ASCII = range. Could you provide a pointer to the use of =E2=80=9C\uXXX" specifically, = we had a working group discussion on this text, but if there is = something existing, i haven=E2=80=99t been able to find it. >=20 > * Section 4.2.1 - General - I am having a hard time with this section > because it is not highlighting the last piece of information that I = think I > need to understand for this. =46rom what I read, I think that dest =3D=3D= aud in > terms of JWT - that is the target of the statement. Orig =3D=3D iss = in terms of > JWT - that is the entity that issued the statement. I don't see = anything > that is telling me what the sub of the JWT is supposed to be.=20 >=20 > It would also be good to say why different items are being defined = that > appear to be the same thing as already exist in JWT terms. (Yes, at = the core > it is because the types are different.) I don=E2=80=99t believe the mapping of aud and iss are appropriate here. = The =E2=80=9Corig=E2=80=9D and =E2=80=9Cdest=E2=80=9D claim is = specifically the asserted identity, telephone number of caller and = callee, but may not correspond to the issuer/signer of the JWT, e.g. = service provider.=20 I can explain this in the text if that is helpful. >=20 > * Section 4.2.X - you are not telling me that these are arrays of = "some > type" rather than the "some type=E2=80=9D. sorry, i=E2=80=99m having trouble figuring out what you mean by this >=20 > * Section 4.2.2 - You are stating that things must occur in a specific > order. This is not "normal" JSON behavior and not all JSON = serializers may > be able to support this behavior. I think you need some justification > someplace. I plan to move this to the compact form section, since ordering is only = really needed for compact form now. >=20 > * Section 5 - I am having a hard time finding the lexicographic order = and > white space rules quickly. A pointer might be reasonable. same answer as above. >=20 > * Section 7 - One issue that I think you need to address in the = extension > section is that signaling protocols need to identify what these new = items > are so that they can be picked up and placed into the PASSporT when it = is > reconstructed. The destination does not have to understand the = extension, > but it does need to understand that the extension exists. This will be defined in the =E2=80=9Cusing protocol=E2=80=9D = specification, however i can make that clearer >=20 > * Section 8 - You have a problem in that there are no rules in RFC = 7638 for > dealing with serialization of integers. Given that some of the fields = in > the JWT are integers this needs to be addressed. You might want to = move > this justification to the top of the document so that people are = prepared > for and look for this. wondering if the best way to solve this is to note it and make sure that = for any passport extensions that use compact form, they specify the = handling integers. >=20 > * Section 8 - Wording problem with saying that "dest" and "mky" need = to > follow their OWN rules. Are these really defined elsewhere or do you = just > use the standard rules recursively. will try to clarify >=20 > * Section 9.2 - Consider using a list structure for the asterisk = leading > list in this section. Yep, this was just a missed formatting problem >=20 > * Section 10.1.1 - Encoding Considerations - This could be 7 bit as = the > value is base64 encoded for normal values and would be UTF8 if you = used the > full JOSE signature structure which you do not. Ok, will look at changing this. >=20 > * General - I was really tired when I read through this and I kept = getting > tripped up on prose. I did not write down all of the items which = bothered > me and now I have read it enough that it is harder for me to locate = them. > However, I would request that the authors perform some method of = detailed > reading to check for this. I frequently read the text aloud to myself = for > this purpose. Alternatively, you can just wait for the copy editors. >=20 > Jim >=20 >=20 >=20 From nobody Wed Oct 12 18:45:01 2016 Return-Path: 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 F104D12964E; Wed, 12 Oct 2016 18:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 FzgYh7ucQCNy; Wed, 12 Oct 2016 18:44:57 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B17C12941A; Wed, 12 Oct 2016 18:44:57 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Oct 2016 18:58:05 -0700 From: Jim Schaad To: 'Chris Wendt' References: <065e01d2218f$fea323b0$fbe96b10$@augustcellars.com> In-Reply-To: Date: Wed, 12 Oct 2016 18:44:42 -0700 Message-ID: <0c3801d224f3$60030830$20091890$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLP9b2L90RPVe3qxR2K8L+Qwo/TggIiodRCnpjfHqA= Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: stir@ietf.org, draft-ietf-stir-passport@ietf.org Subject: Re: [stir] draft-ietf-stir-passport-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 01:45:00 -0000 > -----Original Message----- > From: Chris Wendt [mailto:chris-ietf@chriswendt.net] > Sent: Wednesday, October 12, 2016 12:31 PM > To: Jim Schaad > Cc: draft-ietf-stir-passport@ietf.org; stir@ietf.org > Subject: Re: draft-ietf-stir-passport-08 >=20 > HI Jim, >=20 > Thanks for the comprehensive review. I am working through some of the = fixes > based on your comments. > Meanwhile i have the following responses inline. >=20 > -Chris >=20 >=20 > > On Oct 8, 2016, at 2:15 PM, Jim Schaad = wrote: > > > > Here is a review of the document as a whole. > > > > * Section 4 - para 3 - The term "key values" is potentially = ambiguous. > > This could refer either to the value of the key or the value the key > > is pointing to. I would suggest making this clear. >=20 > I will use the term =E2=80=9Cclaim value=E2=80=9D which is a RFC 7519 = term. One additional > question is whether we say same thing for =E2=80=9Cclaim name=E2=80=9D = as well? I suppose we > allow it As long as it is clear what is a key and what is a value for the = purposes of JSON, I don't think it makes any difference. My problem = with the term was that it had both terms so yes "claim name" or "claim = key" would seem to make sense. However both the JSON document and JWT = both seem to prefer "name" to "key". I will note that JWT seems to = prefer prefixing claim to both name and value.=20 . >=20 > > > > * Section 4 - para 3 - The form you are using for encoding of claims > > values has two problems. The first is that this does not match what > > the JSON document says to use "\uXXXX". The second is that as > > written, it is ambiguous. If I have the US-ASCII string of "%ABCD" > > then it does not need to be percent encoded as the string is not = outside of the > US-ASCII range. >=20 > Could you provide a pointer to the use of =E2=80=9C\uXXX" = specifically, we had a working > group discussion on this text, but if there is something existing, i = haven=E2=80=99t been > able to find it. This is from the JSON document 7159 section 7 (Strings). Thus it should = be the default behavior for JSON serialization code. >=20 > > > > * Section 4.2.1 - General - I am having a hard time with this = section > > because it is not highlighting the last piece of information that I > > think I need to understand for this. From what I read, I think that > > dest =3D=3D aud in terms of JWT - that is the target of the = statement. > > Orig =3D=3D iss in terms of JWT - that is the entity that issued the > > statement. I don't see anything that is telling me what the sub of = the JWT is > supposed to be. > > > > It would also be good to say why different items are being defined > > that appear to be the same thing as already exist in JWT terms. = (Yes, > > at the core it is because the types are different.) >=20 > I don=E2=80=99t believe the mapping of aud and iss are appropriate = here. The =E2=80=9Corig=E2=80=9D and > =E2=80=9Cdest=E2=80=9D claim is specifically the asserted identity, = telephone number of caller and > callee, but may not correspond to the issuer/signer of the JWT, e.g. = service > provider. >=20 > I can explain this in the text if that is helpful. I am more worried about the fact that when I read the document, I = thought that 'orig' was associated with the entity making the claim - = i.e. the service provider and not with the call originator than I am = about the question of equivalence to the existing JWT claims. =20 >=20 > > > > * Section 4.2.X - you are not telling me that these are arrays of > > "some type" rather than the "some type=E2=80=9D. >=20 > sorry, i=E2=80=99m having trouble figuring out what you mean by this I can understand some of your confusion and I got it partly wrong - I = was looking at 4.2.2 not 4.2.1 when I wrote the text. 4.2.1 contains the text "The "orig" JSON object MUST only have one key = value pair representing the asserted identity of any type (currently either "tn" or "uri") of the originator of the personal communications signaling."=20 The above is the only place that I can see that says that "orig" is a = JSON object. Separating this into two different sentences would make it = clear that 1) it is and object and 2) the object can only have one = name/value pair. In section 4.2.2 - I did not see any clear text before getting to the = example about the array/object question for the "mky" name. Looking at = just the one example, I would not see that there is a distinction = between having a single value and having multiple values as it is not = clearly highlighted. It might be good to break the first paragraph into = multiple ones each dealing with different parts of the constructed item. = Simple language makes things easier to understand. >=20 > > > > * Section 4.2.2 - You are stating that things must occur in a = specific > > order. This is not "normal" JSON behavior and not all JSON > > serializers may be able to support this behavior. I think you need > > some justification someplace. >=20 > I plan to move this to the compact form section, since ordering is = only really > needed for compact form now. I need to look; however, memory says that only the PASSporT compact form = was allowed. =20 >=20 > > > > * Section 5 - I am having a hard time finding the lexicographic = order > > and white space rules quickly. A pointer might be reasonable. >=20 > same answer as above. >=20 > > > > * Section 7 - One issue that I think you need to address in the > > extension section is that signaling protocols need to identify what > > these new items are so that they can be picked up and placed into = the > > PASSporT when it is reconstructed. The destination does not have to > > understand the extension, but it does need to understand that the = extension > exists. >=20 > This will be defined in the =E2=80=9Cusing protocol=E2=80=9D = specification, however i can make > that clearer >=20 > > > > * Section 8 - You have a problem in that there are no rules in RFC > > 7638 for dealing with serialization of integers. Given that some of > > the fields in the JWT are integers this needs to be addressed. You > > might want to move this justification to the top of the document so > > that people are prepared for and look for this. >=20 > wondering if the best way to solve this is to note it and make sure = that for any > passport extensions that use compact form, they specify the handling = integers. That would be the base specification with the "iat" claim. This is a = NumericDate - that is an integer since. Canonicalization is not a = problem for JWT as the claim is transported so the form is fixed. >=20 > > > > * Section 8 - Wording problem with saying that "dest" and "mky" need > > to follow their OWN rules. Are these really defined elsewhere or do > > you just use the standard rules recursively. >=20 > will try to clarify >=20 > > > > * General - I was really tired when I read through this and I kept > > getting tripped up on prose. I did not write down all of the items > > which bothered me and now I have read it enough that it is harder = for me to > locate them. > > However, I would request that the authors perform some method of > > detailed reading to check for this. I frequently read the text = aloud > > to myself for this purpose. Alternatively, you can just wait for = the copy > editors. > > > > Jim > > > > > > From nobody Thu Oct 13 00:55:03 2016 Return-Path: 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 0A7B31296D7 for ; Thu, 13 Oct 2016 00:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bk3Nj6yvvA-K for ; Thu, 13 Oct 2016 00:55:00 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 763D012947E for ; Thu, 13 Oct 2016 00:55:00 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id m5so33137275qtb.3 for ; Thu, 13 Oct 2016 00:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=etOFykTQJ+CDyyluRRs8rb2QMRIV5QJGTaeNKqlEs+U=; b=hYgMQaWwYLwxu7GW4jgPp73hey2eojiCD+hTjKwkr6WPGoRZzUqbS24wY/6tnQwqbv cmHxv0bkiiuwsSj6VgR1HX2cet/RV/MLdLGSSvhzCGm1d/4Lg+JC8aYfb3c/wXx49Fq3 Bzc9yaEgtaXFeAG8qBuwEglL7TO+dqFARIAftP2bcvkWvqkc99wXS/cLfbX3IQ5T9s6C EQNsOiAhB4+lPwB3ITwy8PUR66HamYu5GkBbrBp/AZu/JkO1gxphAJ/e21+6fJO9EhvP putytpNXoJLDkz0aDbKJ62fdL7OyKe/tLmVKMQNFKKnRMkk+WjXeA+UiWrm93dg64/xw Nhgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=etOFykTQJ+CDyyluRRs8rb2QMRIV5QJGTaeNKqlEs+U=; b=CIsXgwLDmZJ6YO4LSsxnpP4M0ER3CjeAepINdRlh/06CEd4zmz3FDIuEinGF/E9TdZ WoDHvSoJZfHDOyXXoAbBoxcRJxVyBmBnmwh82TsL/ovIW9iliJYyPT9Hl40pIklf5zo0 O78Ryq+JdGrzTVoU6N5YlEKeUijH2WKXvDwIrIkewNjLrMzz3dG9FPNOM0rNxBJLb5x5 7cYETgfOoDRTEAOA8EjLSzZFOx3UXbWDYPHH/1HA/R/yUTxYbcMugElTQ087h6fEAgNz ZM2jrDH0zA/OeeZONtG4IcTP9qon0Rjmq+V/yTLJGIZNNW+JscJWggdl+oWKnLQaZEpQ 7QRA== X-Gm-Message-State: AA6/9Rnx/yI7suSURSzphWzstEu4KEgSCc0/rzJ6OsLl3uj5efsJgXUMTvUFEhciixSsHg== X-Received: by 10.28.195.196 with SMTP id t187mr1128306wmf.29.1476345299496; Thu, 13 Oct 2016 00:54:59 -0700 (PDT) Received: from alans-mbp.lan ([37.152.254.14]) by smtp.gmail.com with ESMTPSA id p9sm20404789wjs.11.2016.10.13.00.54.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Oct 2016 00:54:58 -0700 (PDT) From: Alan Ford Content-Type: multipart/alternative; boundary="Apple-Mail=_6CAF83CE-A549-4ACA-BF30-F3F38CB1001B" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 13 Oct 2016 08:56:30 +0100 References: <5C775124-3C87-4725-9545-404E08770022@shockey.us> To: Richard Shockey , stir@ietf.org In-Reply-To: <5C775124-3C87-4725-9545-404E08770022@shockey.us> X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 07:55:02 -0000 --Apple-Mail=_6CAF83CE-A549-4ACA-BF30-F3F38CB1001B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Richard, > On 7 Oct 2016, at 00:58, Richard Shockey wrote: >=20 > RS> In the United States carrier profile of STIR aka SHAKEN, you must = use the full form of PASSporT. There will be more on this after = October 26. =20 Given this, and given my previously expressed thoughts that the = scenarios in which compact would be useful in the SIP world are limited, = is there any need for compact form at all? Regards, Alan --Apple-Mail=_6CAF83CE-A549-4ACA-BF30-F3F38CB1001B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Richard,

On 7 Oct 2016, at 00:58, = Richard Shockey <richard@shockey.us> wrote:

RS> In the United States carrier profile of STIR aka = SHAKEN, you must use the full form of PASSporT.    There = will be more on this after October 26.  

Given this, and given my previously = expressed thoughts that the scenarios in which compact would be useful = in the SIP world are limited, is there any need for compact form at = all?

Regards,
Alan

= --Apple-Mail=_6CAF83CE-A549-4ACA-BF30-F3F38CB1001B-- From nobody Thu Oct 13 01:04:19 2016 Return-Path: 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 615DA1296D8 for ; Thu, 13 Oct 2016 01:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Y2qM0tDztl5W for ; Thu, 13 Oct 2016 01:04:15 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 95035129431 for ; Thu, 13 Oct 2016 01:04:14 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id b75so122420542lfg.3 for ; Thu, 13 Oct 2016 01:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=K+2hBrCUB6wP7v0nzs/rbNCfx0oAcSg1aKRTPt/+v9M=; b=icvkuHl83dH7HxVg6z57fZfmzgjwa2eZBCYQkJG0pwnMqk4WyxqR7KlKi6JwHjlAdd yZmSnzxeooqcUhjlyJOF/2IA9YJkzrjOHO6b+beIOP9RyjiOdL0L7k1JDEHvowIdYvW6 QmZ+xFcVJG1rq/8HxXUKVsqs5WMBHFR+1AkTJG9v/TLk/rOYOvRTPln6XynPtBJjthPR hbxiEwiVIXlUy4LoG9SK1oz+o87Ut2y5ag4wAGKB+dws5n5KEo+qSFJrmj1wG0uunhDQ kQRT8OwyGZ5UJSnc0Vb2sDbFsvSEREEVXXbCZYoWFLCKeYkimp9cGPJZXNlh7yyfbdfz eWRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=K+2hBrCUB6wP7v0nzs/rbNCfx0oAcSg1aKRTPt/+v9M=; b=mABRbbbf3aYa9NqmKAgdgdEE/3nxundWhTbuN1VIEw+87TS6OXrPtPBWbXU/mquPUj VomnQQuKTIOGgStWP/G1W1S8XMD8EVaB8oC+PmLxr4OF40LVXRjYWCol7jjJkd0qYGHv 8SVmm2vyPDo06C7xFn55GnXitHYCYlI82mD+O5W3NIAYDDZUvGqhp9lFXKPirUyFcx+V VGM76OcWMxNi4kk9ZFcgrajR1qruUeoniMCNWbgtG8parm4HWZUgd8x9Q7vQFBzRcIxe eQZjJrkBG4WWSbxV8eTMPhQhz4T01iAlS25LZDPcrvkwAw1M+MmFZJRQBA3+7UYGQQhT RVtQ== X-Gm-Message-State: AA6/9Rn+Hq5abCDIrJY/pkokpiT9Uk69cqu4I/oAHflNUSTP/GsTqOEu+CxSaSRV75dh+A== X-Received: by 10.28.98.10 with SMTP id w10mr1157585wmb.99.1476345851886; Thu, 13 Oct 2016 01:04:11 -0700 (PDT) Received: from alans-mbp.lan ([37.152.254.14]) by smtp.gmail.com with ESMTPSA id lz5sm20358293wjb.24.2016.10.13.01.04.10 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Oct 2016 01:04:11 -0700 (PDT) From: Alan Ford Content-Type: multipart/alternative; boundary="Apple-Mail=_B8D3C684-584B-4E25-B2DB-67946CCF5621" Message-Id: <852B17EF-44D6-4380-AEC4-3E2709092507@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 13 Oct 2016 09:05:43 +0100 References: To: stir@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 08:04:17 -0000 --Apple-Mail=_B8D3C684-584B-4E25-B2DB-67946CCF5621 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, Does anybody else have any thoughts on this? I still fear I may be = missing something, but in its present form I see there being a lot of = unnecessary deployment headaches around canonicalisations and the need = to go into a 438 exchange. Guidance on the use of full form (which in = reality would probably lead to the use of full form in most scenarios) = would seem to make this much easier. I personally think this issue needs = to be resolved before publication. Regards, Alan > On 2 Oct 2016, at 12:17, Alan Ford wrote: >=20 > Hi all, >=20 > In general this clarifies a number of the issues raised, and I feel = the use of the compact/full distinction is much clearer for current and = future implementors than =E2=80=9Ccanon". >=20 > However, there is still opportunity for providing guidance of when to = use each form, to avoid interop issues further down the line. >=20 > In particular, in Section 6.1, it says: >=20 > An authentication service MAY use the full form of the PASSporT in > the Identity header field. The presence of the full form is = OPTIONAL > because the information carried in the baseline PASSporT object's > headers and claims is usually redundant with information already > carried elsewhere in the SIP request. Using the compact form can > significantly reduce SIP message size, especially when the PASSporT > object contains media keys. The syntax of the compact form is = given > in [I-D.ietf-stir-passport = ] Section 6 = ; = essentially, it contains a > base64 encoding of the JSON header and payload in the PASSporT > object. >=20 > Firstly, "essentially, it contains a base64 encoding of the JSON = header and payload in the PASSporT object=E2=80=9D surely is a typo? The = compact form contains a base64 encoding of the signature? >=20 > This text also does not clarify why you would want to use the full = form when not using optional extensions. The point I have been making in = earlier mails, and which I feel would be valuable to add to the = document, is something along the lines of =E2=80=9CIf, however, a sender = does not know how a receiver may canonicalise the source or destination = addresses, for example if it does not know whether tn, uri, or both = would be used, then it SHOULD include the full form.=E2=80=9D. (Section = 8 makes comments along these lines but not as explicitly). >=20 > Also, in Section 6.2.3, it talks about using the full form to help = with canonicalisation of orig: >=20 > As an optimization, when the full form is present, the verification > service MAY compute its own canonicalization of an originating > telephone number and compare it to the values in the "orig" element > of PASSporT before performing any cryptographic functions in order = to > ascertain whether or not the two ends agree on the canonical number > form. >=20 > I think it would be helpful to also point out it helps with the = canonicalisation of dest, by adding a sentence such as: >=20 > =E2=80=9CSimilarly, the presence of the full form allows the receiver = to see how the sender canonicalised the destination address(es), such as = whether it was canonicalised to a tn, a uri, or both, and so this can = help the receiver know how to canonicalise the headers and thus verify = the claims.=E2=80=9D >=20 > Regards, > Alan >=20 --Apple-Mail=_B8D3C684-584B-4E25-B2DB-67946CCF5621 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

Does anybody else have any thoughts on this? I still fear I = may be missing something, but in its present form I see there being a = lot of unnecessary deployment headaches around canonicalisations and the = need to go into a 438 exchange. Guidance on the use of full form (which = in reality would probably lead to the use of full form in most = scenarios) would seem to make this much easier. I personally think this = issue needs to be resolved before publication.

Regards,
Alan

On 2 Oct 2016, at 12:17, Alan = Ford <alan.ford@gmail.com> wrote:

Hi all,

In general this = clarifies a number of the issues raised, and I feel the use of the = compact/full distinction is much clearer for current and future = implementors than =E2=80=9Ccanon".

However, there is still opportunity for = providing guidance of when to use each form, to avoid interop issues = further down the line.

In particular, in Section 6.1, it says:

   An authentication service MAY use the =
full form of the PASSporT in
   the Identity header field.  The presence of the full form is OPTIONAL
   because the information carried in the baseline PASSporT object's
   headers and claims is usually redundant with information already
   carried elsewhere in the SIP request.  Using the compact form can
   significantly reduce SIP message size, especially when the PASSporT
   object contains media keys.  The syntax of the compact form is given
   in [I-D.ietf-stir-passport] Section 6; essentially, it contains a
   base64 encoding of the JSON header and payload in the PASSporT
   object.

Firstly, "essentially, it contains a base64 encoding of the = JSON header and payload in the PASSporT object=E2=80=9D surely is a = typo? The compact form contains a base64 encoding of the signature?

This text also does not clarify why you = would want to use the full form when not using optional extensions. The = point I have been making in earlier mails, and which I feel would be = valuable to add to the document, is something along the lines of =E2=80=9C= If, however, a sender does not know how a receiver may canonicalise the = source or destination addresses, for example if it does not know whether = tn, uri, or both would be used, then it SHOULD include the full = form.=E2=80=9D. (Section 8 makes comments along these lines but not as = explicitly).

Also, in Section 6.2.3, it talks about using the full form to = help with canonicalisation of orig:

   As an optimization, when the full =
form is present, the verification
   service MAY compute its own canonicalization of an originating
   telephone number and compare it to the values in the "orig" element
   of PASSporT before performing any cryptographic functions in order to
   ascertain whether or not the two ends agree on the canonical number
   form.

I= think it would be helpful to also point out it helps with the = canonicalisation of dest, by adding a sentence such as:

=E2=80=9CSimilarly, the = presence of the full form allows the receiver to see how the sender = canonicalised the destination address(es), such as whether it was = canonicalised to a tn, a uri, or both, and so this can help the receiver = know how to canonicalise the headers and thus verify the = claims.=E2=80=9D

Regards,
Alan


= --Apple-Mail=_B8D3C684-584B-4E25-B2DB-67946CCF5621-- From nobody Thu Oct 13 05:45:37 2016 Return-Path: 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 6F5C9129423 for ; Thu, 13 Oct 2016 05:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 2QpI82mfsBF6 for ; Thu, 13 Oct 2016 05:45:34 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 0030B129437 for ; Thu, 13 Oct 2016 05:45:33 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id o68so133101604qkf.3 for ; Thu, 13 Oct 2016 05:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IOKM9wyT3XX1XiGPNzamhAWZUAI3cLOWadzwC7My4YE=; b=QwluUuek7is7ntuu1i7l5YMlNwU3kR0XOW/1GSvYlrwkrfSGYMXA+EcTkcDEvbvplB CHms3MZKic8kyfA4tKu2y3EYReViXQH77ttv2I1GadmjyfnjCfjjU9QElhQXKacqWEtt g97swUVjJTTi9yIXLk6uRvnSiDAynkOs7Rp1TIfzTsOYVvlq1p0ecOOxakTlxRqQ3444 wcd2qtvOrJiQSTSRBnuANk0BKzM5CO5gRv2mFLNzEAvaLw9A+4E8dnoB/QfVbUxANn83 Xxc33Pd+ulk7VBN7wyDd8bGH/mGYMspKLbRFJuTfPrKWAkp0koOPmpQgOttnC+3a/bWU y5aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=IOKM9wyT3XX1XiGPNzamhAWZUAI3cLOWadzwC7My4YE=; b=hCfelKwm8mPZkIc5NErCXOJvamHRkh13btrLR8Ei66JqJnM6pc8ZBAlRZfZyeRVyoQ ueJvWkGcdPhB8A1t4gBKXiYjx5M+tBn5DJ1JYe02T5KFoDPlzhgoLVA82SCUv9ZXN2YG bgJweCUYiQwSUVyTJUEL732zZ778i+PlKzxI+r+2dwFqUSw+Vq3nWmQIx+GPiDDeGv9e KdrYuKXhLfzOHfHmvXkosxRIVMMwqNRdMi5mK7o9/nPWxYV8+lhBKM+s3uLT4jtOGGvz 4IJEhQESjWzRy/GXy9aNjX1z8o7MhcTqFYacim+SNpARCIdbr+RssbI6hMEO068+Ixl+ 752A== X-Gm-Message-State: AA6/9RmXaoP7eItBYj5GAGGnC+UZcBJPNRJduqhjzqfbihEonrPCuXF7woDK0HJaEwYH0g== X-Received: by 10.55.137.3 with SMTP id l3mr5790001qkd.128.1476362733052; Thu, 13 Oct 2016 05:45:33 -0700 (PDT) Received: from ?IPv6:2601:a40:100:d3:1b2:f6f3:144f:901c? ([2601:a40:100:d3:1b2:f6f3:144f:901c]) by smtp.gmail.com with ESMTPSA id p22sm4653867qka.43.2016.10.13.05.45.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Oct 2016 05:45:32 -0700 (PDT) From: Chris Wendt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_84B5D688-BD74-4F9E-BC2A-BCAD8F7FB71F" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Thu, 13 Oct 2016 08:45:31 -0400 In-Reply-To: <852B17EF-44D6-4380-AEC4-3E2709092507@gmail.com> To: Alan Ford References: <852B17EF-44D6-4380-AEC4-3E2709092507@gmail.com> X-Mailer: Apple Mail (2.3226) Archived-At: Cc: stir@ietf.org Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 12:45:36 -0000 --Apple-Mail=_84B5D688-BD74-4F9E-BC2A-BCAD8F7FB71F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We will be using the full form of PASSporT in the SHAKEN framework, but = I don=E2=80=99t think we should necessarily remove compact form, there = are applications that may want to use it, particularly in more = controlled eco-systems. Obviously, Appendix F in RFC7515 is evidence that other people are = thinking about these uses of JWT as well. > On Oct 13, 2016, at 4:05 AM, Alan Ford wrote: >=20 > Hi all, >=20 > Does anybody else have any thoughts on this? I still fear I may be = missing something, but in its present form I see there being a lot of = unnecessary deployment headaches around canonicalisations and the need = to go into a 438 exchange. Guidance on the use of full form (which in = reality would probably lead to the use of full form in most scenarios) = would seem to make this much easier. I personally think this issue needs = to be resolved before publication. >=20 > Regards, > Alan >=20 >> On 2 Oct 2016, at 12:17, Alan Ford > wrote: >>=20 >> Hi all, >>=20 >> In general this clarifies a number of the issues raised, and I feel = the use of the compact/full distinction is much clearer for current and = future implementors than =E2=80=9Ccanon". >>=20 >> However, there is still opportunity for providing guidance of when to = use each form, to avoid interop issues further down the line. >>=20 >> In particular, in Section 6.1, it says: >>=20 >> An authentication service MAY use the full form of the PASSporT in >> the Identity header field. The presence of the full form is = OPTIONAL >> because the information carried in the baseline PASSporT object's >> headers and claims is usually redundant with information already >> carried elsewhere in the SIP request. Using the compact form can >> significantly reduce SIP message size, especially when the = PASSporT >> object contains media keys. The syntax of the compact form is = given >> in [I-D.ietf-stir-passport = ] Section 6 = ; = essentially, it contains a >> base64 encoding of the JSON header and payload in the PASSporT >> object. >>=20 >> Firstly, "essentially, it contains a base64 encoding of the JSON = header and payload in the PASSporT object=E2=80=9D surely is a typo? The = compact form contains a base64 encoding of the signature? >>=20 >> This text also does not clarify why you would want to use the full = form when not using optional extensions. The point I have been making in = earlier mails, and which I feel would be valuable to add to the = document, is something along the lines of =E2=80=9CIf, however, a sender = does not know how a receiver may canonicalise the source or destination = addresses, for example if it does not know whether tn, uri, or both = would be used, then it SHOULD include the full form.=E2=80=9D. (Section = 8 makes comments along these lines but not as explicitly). >>=20 >> Also, in Section 6.2.3, it talks about using the full form to help = with canonicalisation of orig: >>=20 >> As an optimization, when the full form is present, the = verification >> service MAY compute its own canonicalization of an originating >> telephone number and compare it to the values in the "orig" = element >> of PASSporT before performing any cryptographic functions in order = to >> ascertain whether or not the two ends agree on the canonical = number >> form. >>=20 >> I think it would be helpful to also point out it helps with the = canonicalisation of dest, by adding a sentence such as: >>=20 >> =E2=80=9CSimilarly, the presence of the full form allows the receiver = to see how the sender canonicalised the destination address(es), such as = whether it was canonicalised to a tn, a uri, or both, and so this can = help the receiver know how to canonicalise the headers and thus verify = the claims.=E2=80=9D >>=20 >> Regards, >> Alan >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_84B5D688-BD74-4F9E-BC2A-BCAD8F7FB71F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We will be using the full form of PASSporT in the SHAKEN = framework, but I don=E2=80=99t think we should necessarily remove = compact form, there are applications that may want to use it, = particularly in more controlled eco-systems.

Obviously, Appendix F in RFC7515 is = evidence that other people are thinking about these uses of JWT as = well.


On Oct 13, 2016, at 4:05 AM, Alan Ford <alan.ford@gmail.com>= wrote:

Hi all,

Does anybody else have = any thoughts on this? I still fear I may be missing something, but in = its present form I see there being a lot of unnecessary deployment = headaches around canonicalisations and the need to go into a 438 = exchange. Guidance on the use of full form (which in reality would = probably lead to the use of full form in most scenarios) would seem to = make this much easier. I personally think this issue needs to be = resolved before publication.

Regards,
Alan

On 2 Oct = 2016, at 12:17, Alan Ford <alan.ford@gmail.com> wrote:

Hi all,

In general this = clarifies a number of the issues raised, and I feel the use of the = compact/full distinction is much clearer for current and future = implementors than =E2=80=9Ccanon".

However, there is still opportunity for = providing guidance of when to use each form, to avoid interop issues = further down the line.

In particular, in Section 6.1, it says:

   An authentication service MAY use the =
full form of the PASSporT in
   the Identity header field.  The presence of the full form is OPTIONAL
   because the information carried in the baseline PASSporT object's
   headers and claims is usually redundant with information already
   carried elsewhere in the SIP request.  Using the compact form can
   significantly reduce SIP message size, especially when the PASSporT
   object contains media keys.  The syntax of the compact form is given
   in [I-D.ietf-stir-passport] Section 6; essentially, it contains a
   base64 encoding of the JSON header and payload in the PASSporT
   object.

Firstly, "essentially, it contains a base64 encoding of the = JSON header and payload in the PASSporT object=E2=80=9D surely is a = typo? The compact form contains a base64 encoding of the signature?

This text also does not clarify why you = would want to use the full form when not using optional extensions. The = point I have been making in earlier mails, and which I feel would be = valuable to add to the document, is something along the lines of =E2=80=9C= If, however, a sender does not know how a receiver may canonicalise the = source or destination addresses, for example if it does not know whether = tn, uri, or both would be used, then it SHOULD include the full = form.=E2=80=9D. (Section 8 makes comments along these lines but not as = explicitly).

Also, in Section 6.2.3, it talks about using the full form to = help with canonicalisation of orig:

   As an optimization, when the full =
form is present, the verification
   service MAY compute its own canonicalization of an originating
   telephone number and compare it to the values in the "orig" element
   of PASSporT before performing any cryptographic functions in order to
   ascertain whether or not the two ends agree on the canonical number
   form.

I= think it would be helpful to also point out it helps with the = canonicalisation of dest, by adding a sentence such as:

=E2=80=9CSimilarly, the = presence of the full form allows the receiver to see how the sender = canonicalised the destination address(es), such as whether it was = canonicalised to a tn, a uri, or both, and so this can help the receiver = know how to canonicalise the headers and thus verify the = claims.=E2=80=9D

Regards,
Alan


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_84B5D688-BD74-4F9E-BC2A-BCAD8F7FB71F-- From nobody Thu Oct 13 08:13:47 2016 Return-Path: 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 5D984129549 for ; Thu, 13 Oct 2016 08:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 Ut7NWF3rrINr for ; Thu, 13 Oct 2016 08:13:43 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id CB9E312953A for ; Thu, 13 Oct 2016 08:13:43 -0700 (PDT) Received: (qmail 14348 invoked by uid 0); 13 Oct 2016 15:13:40 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy1.mail.unifiedlayer.com with SMTP; 13 Oct 2016 15:13:40 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id v36h1t01V1MNPNq0136kbh; Thu, 13 Oct 2016 09:06:45 -0600 X-Authority-Analysis: v=2.1 cv=PIacp5aC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=1oJP67jkp3AA:10 a=CH0kA5CcgfcA:10 a=ZZnuYtJkoWoA:10 a=PeFO9FbFhS32YxYntvkA:9 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=7mZ6aPp0wfdxc0wSNLAA:9 a=QEXdDO2ut3YA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=LeSxx-XiaCbxNmaDZ6oA:9 a=OekkVGC9yqBCRw_8:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=BKKCjISod1eDJeS0ORpz:22 a=zjWhRoSqWz9hl55Hdlzg:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To: From:Subject:Date; bh=vKGLNdKdOss6y40fQtlovB4PS7hJin4q1/LDHfITUDo=; b=ayN4qA8 LTPPEm6KfVFuhnKgFm7lbGWSqPg54Y9QH9mWKA8aWIi/2aJUqzyWK65jpAYmFTZdNM9d/c8rXiH2i UaMjODIxY5S8Y89prmVWSlEKWmUYW9jxg19x03HinxTM; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:50644 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1bugms-0006R1-7h; Thu, 13 Oct 2016 08:15:10 -0600 User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Thu, 13 Oct 2016 10:15:08 -0400 From: Richard Shockey To: Alan Ford , Message-ID: <0784C789-676D-4520-A5B8-DCBDE42C9107@shockey.us> Thread-Topic: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt References: <5C775124-3C87-4725-9545-404E08770022@shockey.us> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3559198510_1017865818" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1bugms-0006R1-7h X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:50644 X-Source-Auth: richard+shockey.us X-Email-Count: 0 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 15:13:46 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3559198510_1017865818 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =20 I never understood the need for the compact form.=C2=A0=C2=A0 Compact was a silly i= dea IMHO.=C2=A0 =C2=A0=C2=A0 =20 From: stir on behalf of Alan Ford Date: Thursday, October 13, 2016 at 3:56 AM To: Richard Shockey , Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt =20 Hi Richard, =20 On 7 Oct 2016, at 00:58, Richard Shockey wrote: =20 RS> In the United States carrier profile of STIR aka SHAKEN, you must use t= he full form of PASSporT. There will be more on this after October 26. =20 =20 Given this, and given my previously expressed thoughts that the scenarios i= n which compact would be useful in the SIP world are limited, is there any n= eed for compact form at all? =20 Regards, Alan =20 _______________________________________________ stir mailing list stir@ietf= .org https://www.ietf.org/mailman/listinfo/stir=20 --B_3559198510_1017865818 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

 

I never understoo= d the need for the compact form.=C2=A0=C2=A0 Compact was a silly idea IMHO.=C2=A0 =C2=A0=C2=A0

 

From: stir <stir-bounces@ietf.org> on behalf of A= lan Ford <alan.ford@gmail.com>
Date: Thursday, October 13, 2= 016 at 3:56 AM
To: Richard Shockey <richard@shockey.us>, <= ;stir@ietf.org>
Subject: Re: [stir] Comments on draft-ietf-stir= -rfc4474bis-13.txt

&= nbsp;

Hi Richard,

 

On 7 Oct 2016, at 00:58, Richar= d Shockey <richard@shockey.us>= wrote:

 

RS> In the United States carrier profile of STIR aka SHAKEN, = you must use the full form of PASSporT.    There will be more= on this after October 26.  

<= o:p> 

Given this, and given my p= reviously expressed thoughts that the scenarios in which compact would be us= eful in the SIP world are limited, is there any need for compact form at all= ?

 

Regards,

Al= an

 

_______________________________________________ stir mailin= g list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir <= /p> --B_3559198510_1017865818-- From nobody Thu Oct 13 09:57:13 2016 Return-Path: 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 6CE6012955C for ; Thu, 13 Oct 2016 09:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 IpFLpsvgxqfh for ; Thu, 13 Oct 2016 09:57:09 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5DD1293D8 for ; Thu, 13 Oct 2016 09:57:09 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id u9DGrowC027872; Thu, 13 Oct 2016 12:57:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar-biz; bh=wxmc0KYsVB4dzlkPHUn7ay18N5I3AKtFmfHHZ9KLpLo=; b=gUKTAoKONdiyly+SCEQHT5wCIkrNQyo9wGaJaRMGcpFON6eN89nyTun4EERPc2SwNdFT GwfgJ5OotoUxJgoFqiO7dPEy5TC/5SQ0uJxotnKLXDMgbWXzXhOCnRrum1cDnxhxgG60 062VxpDf5zyX3AzYYSnA+rAWIyCcU60afbwWcNz4woH4pIkV1xyWZtQ+XqLQhmZXfhl5 vEZ6RkPyXF0mJTn5uabkrNjaKR66DTY1RJKXtv1CLtffFhNJaPs2q4jo7Pt+N34nf/C0 4CIseZwk2xPJgHxWCxvzVQ3NGHsFRs56RGxQ9jreKToJ7A3wsHH7GVKLzXZcOOElTLXX yA== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 261qsgbc3g-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Oct 2016 12:57:03 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 13 Oct 2016 12:57:02 -0400 From: "Peterson, Jon" To: "nweinronk@btinternet.com" , "stir@ietf.org" Thread-Topic: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt Thread-Index: AQHSH2DbTyBQGFRWDUSXYVpiyFA/m6Cmpt2A Date: Thu, 13 Oct 2016 16:57:02 +0000 Message-ID: References: <24430040.96568.1475710389106.JavaMail.defaultUser@defaultHost> In-Reply-To: <24430040.96568.1475710389106.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.81] Content-Type: multipart/alternative; boundary="_000_D4252C981BE29Ejonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610130287 Archived-At: Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 16:57:11 -0000 --_000_D4252C981BE29Ejonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll be implementing most of the fixes in Nick's comments along with other = last call comments at the end of the week, but I did want to speak to this = one issue in particular: 4.1.1 para 2: I note the recommendation of the compact form of PASSporT he= re. I do have concern over B2BUAs actions on Date header. Will B2BUA actions (s= tripping / replacing this header) actually mean that everyone in reality wi= ll have to use the full format of PASSporT anyway and probably without does= the repeat after failure on the compact form ? It's interesting - speculating about what B2BUAs might do is part of what i= nspired the compact form in the first place. Long before we tried to distin= guish full from compact form or indeed incorporated PASSporT, the original = specification of "canon" as the canonical original telephone number was kep= t optional as an Identity parameter in part because, as Hadriel and others = feared, any place where that telephone number appeared in the message it co= uld be a potential target for SBC modification. If SBCs want to modify the = number in the From, do we really think we're going to stump them by putting= a copy of the number in the "canon" parameter two headers down? They'll ju= st go change that one too, it was argued. But by instead having the two end= s do their own canonicalization, rather than trying to tunnel the canonical= ized number from end to end in some special spot, we effectively removed th= e ability of SBCs to modify that canonical number. We wouldn't even need a = terminating-side verification service canonicalization pass if we didn't ne= ed to defend against this possibility of SBC interference. What that means is that using the full form potentially makes the contents = of the JWS header and payload a target for SBC modification - if the SBC is= modifying the From header, why wouldn't an Identity-aware SBC modify the "= orig" in the JWS payload too? The same argument can, unsurprisingly, be mad= e for the Date header. The full form resend mechanism in there today is a c= ompromise intended to try to address some specific legacy behavior that we = see out there today. I consider it our best guess, but I think I'd like som= e deployment experience before I come down hard on either side of this issu= e. The other motivation for compact form was just to save space in more constr= ained environments: not to add redundant bytes to the message unless you ne= ed to. Full form adds bytes, and it isn't a particularly small number of by= tes. This is basically the motivation given in JWS Appendix F for having an= abbreviated form of the payload when its being used in such an environment= . Our usage of compact form here is well within the spirit of JWS design. Does all of this add up to a RECOMMENDED compact form? It's real close. We = could take out the recommendation and just leave this up to the STIR profil= es to decide for themselves when they want to use compact or full, if peopl= e feel strongly about it. Are there other profiles of STIR than SHAKEN under development? Yes, if you= consider SIPBRANDY a profile, which we probably should. It could use the c= ompact form. Jon Peterson Neustar, Inc. --_000_D4252C981BE29Ejonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <4A6826CBAF8DBE42A845EA1734F41ED9@neustar.biz> Content-Transfer-Encoding: quoted-printable

I'll be implementing most of the fixes in Nick's comments along with o= ther last call comments at the end of the week, but I did want to speak to = this one issue in particular: 

 <= /font>4.1.1 para 2= : I note the recommendation of the compact form of PASSporT here.

I= do have concern over B2BUAs actions on Date header. Will B2BUA actions (st= ripping / replacing this header) actually mean that everyone in reality wil= l have to use the full format of PASSporT anyway and probably without does the repeat after = failure on the compact form ?

It's interesting - speculating about what B2BUAs might do is part of w= hat inspired the compact form in the first place. Long before we tried to d= istinguish full from compact form or indeed incorporated PASSporT, the orig= inal specification of "canon" as the canonical original telephone number was kept optional as an Identity p= arameter in part because, as Hadriel and others feared, any place where tha= t telephone number appeared in the message it could be a potential target f= or SBC modification. If SBCs want to modify the number in the From, do we really think we're going to stump = them by putting a copy of the number in the "canon" parameter two= headers down? They'll just go change that one too, it was argued. But by i= nstead having the two ends do their own canonicalization, rather than trying to tunnel the canonicalized number from end to end in s= ome special spot, we effectively removed the ability of SBCs to modify that= canonical number. We wouldn't even need a terminating-side verification se= rvice canonicalization pass if we didn't need to defend against this possibility of SBC interference.

What that means is that using the full form potentially makes the cont= ents of the JWS header and payload a target for SBC modification - if the S= BC is modifying the From header, why wouldn't an Identity-aware SBC modify = the "orig" in the JWS payload too? The same argument can, unsurprisingly, be made for the Date header. The fu= ll form resend mechanism in there today is a compromise intended to try to = address some specific legacy behavior that we see out there today. I consid= er it our best guess, but I think I'd like some deployment experience before I come down hard on either side= of this issue.

The other motivation for compact form was just to save space in more c= onstrained environments: not to add redundant bytes to the message unless y= ou need to. Full form adds bytes, and it isn't a particularly small number = of bytes. This is basically the motivation given in JWS Appendix F for having an abbreviated form of the p= ayload when its being used in such an environment. Our usage of compact for= m here is well within the spirit of JWS design.

Does all of this add up to a RECOMMENDED compact form? It's real close= . We could take out the recommendation and just leave this up to the STIR p= rofiles to decide for themselves when they want to use compact or full, if = people feel strongly about it. 

Are there other profiles of STIR than SHAKEN under development? Yes, i= f you consider SIPBRANDY a profile, which we probably should. It could use = the compact form.

Jon Peterson
Neustar, Inc.
--_000_D4252C981BE29Ejonpetersonneustarbiz_-- From nobody Thu Oct 13 10:43:40 2016 Return-Path: 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 9908E12960E for ; Thu, 13 Oct 2016 10:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dnGnq4y841YS for ; Thu, 13 Oct 2016 10:43:36 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 27E9F12961A for ; Thu, 13 Oct 2016 10:43:36 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id x79so151392032lff.0 for ; Thu, 13 Oct 2016 10:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=mciN8HWll4uw4H+7DDEFxIQJQfXKzX9n+AxJg+TnsZE=; b=vCk8wm+6sxEWmldQq5h8BYjq554XfU6UvhZdCrJcGQuc0adYc5KUBY4jPsisLszu9r 5OW18KMebEkXs7qDBbkQIvNUTDOl9qO2Qm6XF/lpYSaaXN8NlNa+pcSpiXZKQijjKfdQ B8GMaKCYDcvLsddSZcU3M0rk3sZI94EtmePG3Jn0o+03cc3flOQ5sE1ToclYXUC9RfgT j3RsJCzsTpa/cErPExzHVuFZ0vrm3UayxEFRnC3yWUv6Nq/1ESu4+FT+N3oKPO7aO9W+ rq5gA2458GofOoZdOrJwUf6sPjFNxNNZ5lbzlJPUtRrIIHI17Jxi8+jAVHxvgqTvlEK3 Zd+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=mciN8HWll4uw4H+7DDEFxIQJQfXKzX9n+AxJg+TnsZE=; b=Cby3qCfi0HD08tfW/HOG1J5rcs1CyG0bW0mVkk1dAnVl6kZFPxasRzW8VYj9P0hjsh cNKC4o73Yf2RYeqsGg/6SreTHv4wmMIrZNA6Q46Vj3GehaoKFska7fwrDaLD3GeSJPlH rOSOmUYq5ExW3BNUHO6UNY46OcRFRuiT5pHrqFWgF8bR84HVI37iQYTRAiriHu4FEcep nErH+DFzvvc6HXEo3YCfQoUJeqBwJLXEPNyL0aKQ1Q+55mfPypEAft1anNWplyJaDG4p 15CP5m0Pgq7bBI140UnkmLwuNJAjcyHxKFJR0oy3YSoeokXJlErW5rV7esB9lkqgeF5y ZT1g== X-Gm-Message-State: AA6/9Rna7pVNJAjJZQDhI2VGUKzLhr8TfesbvBxuqBFTP8ziFj+t6IF4m+P33nreCVm5eQ== X-Received: by 10.28.99.133 with SMTP id x127mr2977568wmb.103.1476380614231; Thu, 13 Oct 2016 10:43:34 -0700 (PDT) Received: from alans-mbp.lan ([37.152.254.14]) by smtp.gmail.com with ESMTPSA id q8sm24207671wjj.7.2016.10.13.10.43.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Oct 2016 10:43:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_194ADFF6-E012-4015-9FA5-02E69AEA4BC7" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Thu, 13 Oct 2016 18:43:32 +0100 Message-Id: <18074C4B-7CD6-4E1A-98BF-085E65748AB3@gmail.com> References: <24430040.96568.1475710389106.JavaMail.defaultUser@defaultHost> To: "Peterson, Jon" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "nweinronk@btinternet.com" , "stir@ietf.org" Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 17:43:40 -0000 --Apple-Mail=_194ADFF6-E012-4015-9FA5-02E69AEA4BC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jon, I admit I came to this late, and so never saw this initial discussion = you refer to, but I am really confused by what you write below. I hope = you can clear up my confusion; comments inline... > It's interesting - speculating about what B2BUAs might do is part of = what inspired the compact form in the first place. Long before we tried = to distinguish full from compact form or indeed incorporated PASSporT, = the original specification of "canon" as the canonical original = telephone number was kept optional as an Identity parameter in part = because, as Hadriel and others feared, any place where that telephone = number appeared in the message it could be a potential target for SBC = modification. If SBCs want to modify the number in the From, do we = really think we're going to stump them by putting a copy of the number = in the "canon" parameter two headers down? They'll just go change that = one too, it was argued. OK, I can see that... > But by instead having the two ends do their own canonicalization, = rather than trying to tunnel the canonicalized number from end to end in = some special spot, we effectively removed the ability of SBCs to modify = that canonical number. ...But this I don=E2=80=99t. Since if they modified what was carried in = the canon / full form, the signature would no longer verify. If they rewrote the signature, it would be from a certificate which = isn=E2=80=99t authorised to represent that source domain. Or if it is authorised, then they could do that to the compact form too. So what exactly are you protecting against here? > We wouldn't even need a terminating-side verification service = canonicalization pass if we didn't need to defend against this = possibility of SBC interference. Right now this statement makes no sense to me - but if I can understand = what threat you are protecting against above, this may make sense! > What that means is that using the full form potentially makes the = contents of the JWS header and payload a target for SBC modification - = if the SBC is modifying the =46rom header, why wouldn't an = Identity-aware SBC modify the "orig" in the JWS payload too? The same = argument can, unsurprisingly, be made for the Date header. Sure it could, but it would also have to rewrite the signature. And if = it couldn=E2=80=99t do so, since it doesn=E2=80=99t have an appropriate = certificate, it would no longer verify. Which is surely what you want? > The other motivation for compact form was just to save space in more = constrained environments: not to add redundant bytes to the message = unless you need to. Full form adds bytes, and it isn't a particularly = small number of bytes. This is basically the motivation given in JWS = Appendix F for having an abbreviated form of the payload when its being = used in such an environment. Our usage of compact form here is well = within the spirit of JWS design. Certainly fair, however if you start to throw around 6KB SDPs (which is = the norm in the video SIP world), the size of the Identity header = suddenly doesn=E2=80=99t seem so significant. > Does all of this add up to a RECOMMENDED compact form? It's real = close. We could take out the recommendation and just leave this up to = the STIR profiles to decide for themselves when they want to use compact = or full, if people feel strongly about it.=20 That seems reasonable. Regards, Alan --Apple-Mail=_194ADFF6-E012-4015-9FA5-02E69AEA4BC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Jon,

I admit I = came to this late, and so never saw this initial discussion you refer = to, but I am really confused by what you write below. I hope you can = clear up my confusion; comments inline...

It's interesting - speculating about what B2BUAs might = do is part of what inspired the compact form in the first place. Long = before we tried to distinguish full from compact form or indeed = incorporated PASSporT, the original specification of "canon" as the canonical original telephone number was kept optional as an = Identity parameter in part because, as Hadriel and others feared, any = place where that telephone number appeared in the message it could be a = potential target for SBC modification. If SBCs want to modify the number in the From, do we really think we're going to = stump them by putting a copy of the number in the "canon" parameter two = headers down? They'll just go change that one too, it was argued. =

OK, I can = see that...

But by = instead having the two ends do their own canonicalization, rather than trying to tunnel the canonicalized number from end to end = in some special spot, we effectively removed the ability of SBCs to = modify that canonical number.

...But this I don=E2=80=99t. Since if they = modified what was carried in the canon / full form, the signature would = no longer verify.

If they rewrote = the signature, it would be from a certificate which isn=E2=80=99t = authorised to represent that source domain.

Or if it is authorised, then they could do that to = the compact form too.

So what = exactly are you protecting against here?

We wouldn't even need a terminating-side = verification service canonicalization pass if we didn't need to defend against this possibility of SBC = interference.

Right now this statement makes no sense to me - but if = I can understand what threat you are protecting against above, this may = make sense!

What that means is that using the full form potentially = makes the contents of the JWS header and payload a target for SBC = modification - if the SBC is modifying the =46rom header, why wouldn't = an Identity-aware SBC modify the "orig" in the JWS payload too? The same argument can, unsurprisingly, be made for the Date header. =

Sure it = could, but it would also have to rewrite the signature. And if it = couldn=E2=80=99t do so, since it doesn=E2=80=99t have an appropriate = certificate, it would no longer verify. Which is surely what you = want?

The other motivation = for compact form was just to save space in more constrained = environments: not to add redundant bytes to the message unless you need = to. Full form adds bytes, and it isn't a particularly small number of = bytes. This is basically the motivation given in JWS Appendix F for having an abbreviated form of = the payload when its being used in such an environment. Our usage of = compact form here is well within the spirit of JWS = design.

Certainly = fair, however if you start to throw around 6KB SDPs (which is the norm = in the video SIP world), the size of the Identity header suddenly = doesn=E2=80=99t seem so significant.

Does all of this add up to a RECOMMENDED compact form? = It's real close. We could take out the recommendation and just leave = this up to the STIR profiles to decide for themselves when they want to = use compact or full, if people feel strongly about it. 

That seems = reasonable.

Regards,
Alan

= --Apple-Mail=_194ADFF6-E012-4015-9FA5-02E69AEA4BC7-- From nobody Thu Oct 13 11:03:48 2016 Return-Path: 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 C424B12961A for ; Thu, 13 Oct 2016 11:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 uQtwR-z2VSRr for ; Thu, 13 Oct 2016 11:03:45 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92001279EB for ; Thu, 13 Oct 2016 11:03:44 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9DI3PPW013615; Thu, 13 Oct 2016 14:03:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar-biz; bh=mOQpV+fmu89S4ZbvCccuO8lgHVMnt+lxbKlivtswkF8=; b=S2K0uXcFd34LQ/bIj73XCxi5eGvqkCbD4haY1IB+CY6vCpEinhoqlv89Y6y+4m5UINQx OB15hAA2ZoLmhCGQbBS1uv6YX9+iSypZLCU/Vfp52RZZcV7TOlPwtLqSiwCO0OXrb9Ak RtJPwfZNzruUEqu0q027pSgX68b+f/2032u+QytpspaJ/Wp803W9BhFuGwhkn0VX5Iie YWCzC/Udrlf+Krqqz9OxYmj31rL5soEOjToTUhaPPtg/zAg/cb+kJxD3PlUzToA8lHHs 2jES7KVSDveXFpBlicQJmueGhZNVJ2+oOvjp9UagmewbDn5OGHR0HUfVOrDPvYy3ISjK rQ== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 261qs33kk7-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Oct 2016 14:03:37 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 13 Oct 2016 14:03:36 -0400 From: "Peterson, Jon" To: Alan Ford Thread-Topic: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt Thread-Index: AQHSH2DbTyBQGFRWDUSXYVpiyFA/m6Cmpt2AgABQEAD//8KKgA== Date: Thu, 13 Oct 2016 18:03:35 +0000 Message-ID: References: <24430040.96568.1475710389106.JavaMail.defaultUser@defaultHost> <18074C4B-7CD6-4E1A-98BF-085E65748AB3@gmail.com> In-Reply-To: <18074C4B-7CD6-4E1A-98BF-085E65748AB3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.81] Content-Type: multipart/alternative; boundary="_000_D42541951BE2FCjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610130309 Archived-At: Cc: "nweinronk@btinternet.com" , "stir@ietf.org" Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 18:03:47 -0000 --_000_D42541951BE2FCjonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable But by instead having the two ends do their own canonicalization, rather th= an trying to tunnel the canonicalized number from end to end in some specia= l spot, we effectively removed the ability of SBCs to modify that canonical= number. ...But this I don=92t. Since if they modified what was carried in the canon= / full form, the signature would no longer verify. The distinction I am drawing is between the verifier using the bit-exact ve= rsion of the originating telephone number in "canon" versus a verifier perf= orming its own canonicalization procedure on the From header field. In the = former case, if the SBC modifies "canon", obviously the signature won't be = valid. In the latter case, provided that whatever is in the From can be can= onicalized by the verifier, it uses that. This argument (and again, to be clear, it was not my argument at the time) = is effectively a regress argument. If we're afraid that SBCs could modify f= ield A, we are tempted to create field A-prime which contains the "real" va= lue of A, just in case A gets modified by an SBC. The problem is that as lo= ng as A-prime also goes through the SBC, the SBC can (and surely will) modi= fy A-prime too - SBCs modify A in the first place to enforce some policy or= constraint, and those policies apply equally well to A-prime. "canon" was = just an A-prime in its original incarnation. The full form of PASSporT is r= eadily analogous. If they rewrote the signature, it would be from a certificate which isn=92t= authorised to represent that source domain. I don't mean creating a new PASSporT or redoing the signature. Or if it is authorised, then they could do that to the compact form too. Sure, hypothetically. So what exactly are you protecting against here? By forcing both sides to build their own "real" version of A (the canonical= telephone number) rather than having the originating side generate an A-pr= ime that would be used by the terminating side, we remove the ability of an= SBC to modify A-prime - because there is no A-prime. Instead the SBC can j= ust modify A, but our canonicalization on the verifier side is (supposedly = anyway) sufficient to turn that modified A into the "real" A. I do get that this is a complicated argument: this was however the argument= that moved the working group back in the day. I hesitate to reopen this di= scussion, but I do think people really need to understand that if we think = using "iat" solves the problem of SBCs altering Date, it only does partiall= y: it solves the problem of some legacy SBC modifying Date, but why is Date= modified in the first place? Will the policies and constraints that cause = that today extend to Identity-aware SBCs, as they come into being? The prob= lem with designing anything that is supposed to cope with SBCs is that SBCs= are undefined entities with unlimited powers. We need to see what happens = in deployment to see how effective full form is at addressing this problem. Jon Peterson Neustar, Inc. --_000_D42541951BE2FCjonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

But by instead having the two ends do their own canonicaliz= ation, rather than trying to tunnel the canonicalized number from end to en= d in some special spot, we effectively removed the ability of SBCs to modif= y that canonical number.

...But this I don=92t. Since if they modified what was carried in the = canon / full form, the signature would no longer verify.

The distinction I am drawing is between the verifier using the bit-exa= ct version of the originating telephone number in "canon" versus = a verifier performing its own canonicalization procedure on the From header= field. In the former case, if the SBC modifies "canon", obviously the signature won't be valid. In the latter c= ase, provided that whatever is in the From can be canonicalized by the veri= fier, it uses that.

This argument (and again, to be clear, it was not my argument at the t= ime) is effectively a regress argument. If we're afraid that SBCs could mod= ify field A, we are tempted to create field A-prime which contains the &quo= t;real" value of A, just in case A gets modified by an SBC. The problem is that as long as A-prime also goes throu= gh the SBC, the SBC can (and surely will) modify A-prime too - SBCs modify = A in the first place to enforce some policy or constraint, and those polici= es apply equally well to A-prime. "canon" was just an A-prime in its original incarnation. The ful= l form of PASSporT is readily analogous. 

If they rewrote the signature, it would be from a certificate which is= n=92t authorised to represent that source domain.

I don't mean creating a new PASSporT or redoing the signature.

Or if it is authorised, then they could do that to the compact form to= o.

Sure, hypothetically.

So what exactly are you protecting against here?

By forcing both sides to build their own "real" version of A= (the canonical telephone number) rather than having the originating side g= enerate an A-prime that would be used by the terminating side, we remove th= e ability of an SBC to modify A-prime - because there is no A-prime. Instead the SBC can just modify A, but our canonicali= zation on the verifier side is (supposedly anyway) sufficient to turn that = modified A into the "real" A.

I do get that this is a complicated argument: this was however the arg= ument that moved the working group back in the day. I hesitate to reopen th= is discussion, but I do think people really need to understand that if we t= hink using "iat" solves the problem of SBCs altering Date, it only does partially: it solves the problem of so= me legacy SBC modifying Date, but why is Date modified in the first place? = Will the policies and constraints that cause that today extend to Identity-= aware SBCs, as they come into being? The problem with designing anything that is supposed to cope with SBCs is = that SBCs are undefined entities with unlimited powers. We need to see what= happens in deployment to see how effective full form is at addressing this= problem. 

Jon Peterson
Neustar, Inc.
--_000_D42541951BE2FCjonpetersonneustarbiz_-- From nobody Thu Oct 13 13:07:42 2016 Return-Path: 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 537EE1295DC for ; Thu, 13 Oct 2016 13:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JqLJ8BIoDneO for ; Thu, 13 Oct 2016 13:07:38 -0700 (PDT) Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com [209.85.216.180]) (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 8860912954D for ; Thu, 13 Oct 2016 13:07:38 -0700 (PDT) Received: by mail-qt0-f180.google.com with SMTP id q7so59110202qtq.1 for ; Thu, 13 Oct 2016 13:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=KoqgHri1I75P1wKoHa5d2zPR1HVit/afbZGuELykofE=; b=KeOu9kJ7ojeC5jvW6PRYdoO95PU5yBx26Ma5+Q1afhAKNeHFK6erqqp+qK6/7RUyuS T3YYCgcdzemx2YRgw7GbJsGPT9CnsNCnOHY8CXnz8ugGuIQ3/y2hUxbLbOQZkudARPSD juBOMhoLbAzpebQJQuSZLV/h5axH7qFKrrMEDwLHmgBwz1rK8iKSoz8AJRzRqK3z53Pk xnfDrc7bVUAu0aahICSzBw51MgnzsHh7yuX4R2JT+bk5IPU4/CsqGKRmXnJM/XHz6a8J 5yKyExGDAiMR0S4XeLR87IUW9UQ8rvJffxHNbwjCq2QdWFomfVN6CHt7nHcCDXKV2d6P uDSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KoqgHri1I75P1wKoHa5d2zPR1HVit/afbZGuELykofE=; b=ClcVg1p81Vk10Zj15RWnCUDPMX01OJuERqXJ/x2dzzVHneyxKw5cL596b/McxCt0Tn gOv0FfZRDgbbV9FYNaVZXq8Bk/MFMpRbJqrkISl573foL2q1togcAcyu/8pdWqZALByJ E0KlGx+JsQFEybm8CYtDpZtqt42Sud+uaG4/lP0UlFCTowwgNtaL9Sqm4gDrneFPbPy2 pZl+zGXlIDXuz00V2PIYC8aOEVtnllVXwUdiVDaKolLSu2sNXsydTfLoZEyGNdCeHE6U xB8CQnZr6raQfoQu/qOx5JfXb6DBHgpdfkaVt5Pjq/K1gr7Y4+AjrsN2ozhAouTccZUw uL1w== X-Gm-Message-State: AA6/9RkgLR6Z+Ggg5ZIfpUtisd2eViKzGz+3tAu08VXc7rfn8peP7cPh7bEHmJYsw4APIw== X-Received: by 10.194.229.7 with SMTP id sm7mr8048262wjc.150.1476389197387; Thu, 13 Oct 2016 13:06:37 -0700 (PDT) Received: from alans-mbp.lan ([37.152.254.14]) by smtp.gmail.com with ESMTPSA id za1sm21197312wjb.8.2016.10.13.13.06.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Oct 2016 13:06:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4B61EFB4-BF1A-4037-807E-BADD7EF35421" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Thu, 13 Oct 2016 21:06:36 +0100 Message-Id: <4C2B76C7-083E-4AD9-83BC-91EE93F251B4@gmail.com> References: <24430040.96568.1475710389106.JavaMail.defaultUser@defaultHost> <18074C4B-7CD6-4E1A-98BF-085E65748AB3@gmail.com> To: "Peterson, Jon" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 20:07:41 -0000 --Apple-Mail=_4B61EFB4-BF1A-4037-807E-BADD7EF35421 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jon, Thanks for the feedback. Comments inline=85 I think I=92ve got what this = is all about at long last, but I=92ve left thought processes in place in = case I=92ve still got the wrong end of the stick ;-) > On 13 Oct 2016, at 19:03, Peterson, Jon = wrote: >=20 >>=20 >>> But by instead having the two ends do their own canonicalization, = rather than trying to tunnel the canonicalized number from end to end in = some special spot, we effectively removed the ability of SBCs to modify = that canonical number. >>=20 >> ...But this I don=92t. Since if they modified what was carried in the = canon / full form, the signature would no longer verify. >=20 >=20 > The distinction I am drawing is between the verifier using the = bit-exact version of the originating telephone number in "canon" versus = a verifier performing its own canonicalization procedure on the =46rom = header field. In the former case, if the SBC modifies "canon", obviously = the signature won't be valid. In the latter case, provided that whatever = is in the =46rom can be canonicalized by the verifier, it uses that. But in the latter case, the signature still won=92t be valid. Unless it = can be canonicalised to the same thing. In which case it is valid. Are you saying that is if something=92s in canon, the verifier may look = at that and treat it as gospel, and assume that even though the =46rom = header has been changed, it =93must=94 be a valid canonicalisation since = the signature verifies? Surely that=92s not what you=92re saying? If full form / canon is present, then surely the verifier must know if = it is a valid canonicalisation (by its own rules) before it chooses = whether to validate the signature? > This argument (and again, to be clear, it was not my argument at the = time) is effectively a regress argument. If we're afraid that SBCs could = modify field A, we are tempted to create field A-prime which contains = the "real" value of A, just in case A gets modified by an SBC. The = problem is that as long as A-prime also goes through the SBC, the SBC = can (and surely will) modify A-prime too - SBCs modify A in the first = place to enforce some policy or constraint, and those policies apply = equally well to A-prime. "canon" was just an A-prime in its original = incarnation. The full form of PASSporT is readily analogous.=20 Yes, that=92s fine. However, A is not protected by a signature, but = A-prime is. So given it=92s protected, what=92s the problem that canon / = full form introduces? > By forcing both sides to build their own "real" version of A (the = canonical telephone number) rather than having the originating side = generate an A-prime that would be used by the terminating side, we = remove the ability of an SBC to modify A-prime - because there is no = A-prime. Instead the SBC can just modify A, but our canonicalization on = the verifier side is (supposedly anyway) sufficient to turn that = modified A into the "real" A. Ah! Suddenly a lightbulb moment... I=92ve been coming at this from the wrong angle. I=92ve been assuming we = want to stop (or at least, detect) modification of A. But in fact, what = you=92re saying is you want to permit modification _as long as it can be = canonicalised to the same thing_. Is that correct? In which case I get this - I think. However, the cases where this would be useful are surely limited. This = requires the verifier to know and understand modifications that could be = applied along the path by non-STIR-aware entities. =93Full form=94, being base64 encoded, gets around a simple = search/replace here, which is probably an improvement. Regards, Alan --Apple-Mail=_4B61EFB4-BF1A-4037-807E-BADD7EF35421 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Jon,

Thanks for the feedback. Comments inline=85 I think I=92ve = got what this is all about at long last, but I=92ve left thought = processes in place in case I=92ve still got the wrong end of the stick = ;-)

On 13 Oct 2016, at 19:03, Peterson, Jon = <jon.peterson@neustar.biz> wrote:


But by instead having the two ends do their own = canonicalization, rather than trying to tunnel the canonicalized number = from end to end in some special spot, we effectively removed the ability = of SBCs to modify that canonical number.

...But this I don=92t. Since if they modified what was = carried in the canon / full form, the signature would no longer = verify.

The distinction I am drawing is between the verifier = using the bit-exact version of the originating telephone number in = "canon" versus a verifier performing its own canonicalization procedure = on the =46rom header field. In the former case, if the SBC modifies "canon", obviously the signature won't be valid. In the latter case, = provided that whatever is in the =46rom can be canonicalized by the = verifier, it uses that.

But in the latter case, the signature still won=92t = be valid. Unless it can be canonicalised to the same thing. In which = case it is valid.

Are you saying that is = if something=92s in canon, the verifier may look at that and treat it as = gospel, and assume that even though the =46rom header has been changed, = it =93must=94 be a valid canonicalisation since the signature verifies? = Surely that=92s not what you=92re saying?

If full form / canon is present, then surely the = verifier must know if it is a valid canonicalisation (by its own rules) = before it chooses whether to validate the signature?

This argument (and again, to be clear, it was not my = argument at the time) is effectively a regress argument. If we're afraid = that SBCs could modify field A, we are tempted to create field A-prime = which contains the "real" value of A, just in case A gets modified by an SBC. The problem is that as long as A-prime also goes = through the SBC, the SBC can (and surely will) modify A-prime too - SBCs = modify A in the first place to enforce some policy or constraint, and = those policies apply equally well to A-prime. "canon" was just an A-prime in its original incarnation. The full form = of PASSporT is readily = analogous. 

Yes, that=92s fine. However, A is not protected by = a signature, but A-prime is. So given it=92s protected, what=92s the = problem that canon / full form introduces?

By forcing both sides to build their own "real" version = of A (the canonical telephone number) rather than having the originating = side generate an A-prime that would be used by the terminating side, we = remove the ability of an SBC to modify A-prime - because there is no A-prime. Instead the SBC can just modify A, but our = canonicalization on the verifier side is (supposedly anyway) sufficient = to turn that modified A into the "real" = A.

Ah! = Suddenly a lightbulb moment...

I=92ve = been coming at this from the wrong angle. I=92ve been assuming we want = to stop (or at least, detect) modification of A. But in fact, what = you=92re saying is you want to permit modification _as = long as it can be canonicalised to the same thing_. Is that = correct?

In which case I get this - = I think.

However, the cases where = this would be useful are surely limited. This requires the verifier to = know and understand modifications that could be applied along the path = by non-STIR-aware entities.

=93Full = form=94, being base64 encoded, gets around a simple search/replace here, = which is probably an improvement.

Regards,
Alan

= --Apple-Mail=_4B61EFB4-BF1A-4037-807E-BADD7EF35421-- From nobody Thu Oct 13 13:54:38 2016 Return-Path: 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 4DC0F129441; Thu, 13 Oct 2016 13:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 Wr0mkqM1a-bb; Thu, 13 Oct 2016 13:54:33 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE9D12960A; Thu, 13 Oct 2016 13:54:32 -0700 (PDT) Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 13 Oct 2016 14:07:46 -0700 From: Jim Schaad To: 'Chris Wendt' References: <065e01d2218f$fea323b0$fbe96b10$@augustcellars.com> In-Reply-To: Date: Thu, 13 Oct 2016 13:54:22 -0700 Message-ID: <00cb01d22593$fba8ce50$f2fa6af0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CC_01D22559.4F4CDC80" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQLP9b2L90RPVe3qxR2K8L+Qwo/TggIiodRCnpokH+A= X-Originating-IP: [173.8.216.38] Archived-At: Cc: stir@ietf.org, draft-ietf-stir-passport@ietf.org Subject: Re: [stir] draft-ietf-stir-passport-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 20:54:36 -0000 ------=_NextPart_000_00CC_01D22559.4F4CDC80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I went back to re-read the document and figure out where my confusion = was on the issue of who the 'orig' and 'dest' referred to. This is what = I find. =20 Origination in the context of PASSporT and for a given application's use = of PASSporT is the point in the network that has the authority to assert = the caller identity. =20 The text then goes on to talk about certificates, which I made the = assumption referred to the same certificate as appears in the JWT header = under the =E2=80=98x5u=E2=80=99 name. =20 I think from this is it not unreasonable that I made the assumption that = the =E2=80=98orig=E2=80=99 field referred not the caller originator but = to the issuer of the PASSporT. =20 jim =20 > -----Original Message----- > From: Chris Wendt [mailto:chris-ietf@chriswendt.net] > Sent: Wednesday, October 12, 2016 12:31 PM > To: Jim Schaad > Cc: draft-ietf-stir-passport@ietf.org; stir@ietf.org > Subject: Re: draft-ietf-stir-passport-08 >=20 > HI Jim, >=20 > Thanks for the comprehensive review. I am working through some of the = fixes > based on your comments. > Meanwhile i have the following responses inline. >=20 > -Chris >=20 >=20 > > On Oct 8, 2016, at 2:15 PM, Jim Schaad < = ietf@augustcellars.com> wrote: > > > > Here is a review of the document as a whole. > > > > * Section 4 - para 3 - The term "key values" is potentially = ambiguous. > > This could refer either to the value of the key or the value the key > > is pointing to. I would suggest making this clear. >=20 > I will use the term =E2=80=9Cclaim value=E2=80=9D which is a RFC 7519 = term. One additional > question is whether we say same thing for =E2=80=9Cclaim name=E2=80=9D = as well? I suppose we > allow it. >=20 > > > > * Section 4 - para 3 - The form you are using for encoding of claims > > values has two problems. The first is that this does not match what > > the JSON document says to use "\uXXXX". The second is that as > > written, it is ambiguous. If I have the US-ASCII string of "%ABCD" > > then it does not need to be percent encoded as the string is not = outside of the > US-ASCII range. >=20 > Could you provide a pointer to the use of =E2=80=9C\uXXX" = specifically, we had a working > group discussion on this text, but if there is something existing, i = haven=E2=80=99t been > able to find it. >=20 > > > > * Section 4.2.1 - General - I am having a hard time with this = section > > because it is not highlighting the last piece of information that I > > think I need to understand for this. From what I read, I think that > > dest =3D=3D aud in terms of JWT - that is the target of the = statement. > > Orig =3D=3D iss in terms of JWT - that is the entity that issued the > > statement. I don't see anything that is telling me what the sub of = the JWT is > supposed to be. > > > > It would also be good to say why different items are being defined > > that appear to be the same thing as already exist in JWT terms. = (Yes, > > at the core it is because the types are different.) >=20 > I don=E2=80=99t believe the mapping of aud and iss are appropriate = here. The =E2=80=9Corig=E2=80=9D and > =E2=80=9Cdest=E2=80=9D claim is specifically the asserted identity, = telephone number of caller and > callee, but may not correspond to the issuer/signer of the JWT, e.g. = service > provider. >=20 > I can explain this in the text if that is helpful. >=20 > > > > * Section 4.2.X - you are not telling me that these are arrays of > > "some type" rather than the "some type=E2=80=9D. >=20 > sorry, i=E2=80=99m having trouble figuring out what you mean by this >=20 > > > > * Section 4.2.2 - You are stating that things must occur in a = specific > > order. This is not "normal" JSON behavior and not all JSON > > serializers may be able to support this behavior. I think you need > > some justification someplace. >=20 > I plan to move this to the compact form section, since ordering is = only really > needed for compact form now. >=20 > > > > * Section 5 - I am having a hard time finding the lexicographic = order > > and white space rules quickly. A pointer might be reasonable. >=20 > same answer as above. >=20 > > > > * Section 7 - One issue that I think you need to address in the > > extension section is that signaling protocols need to identify what > > these new items are so that they can be picked up and placed into = the > > PASSporT when it is reconstructed. The destination does not have to > > understand the extension, but it does need to understand that the = extension > exists. >=20 > This will be defined in the =E2=80=9Cusing protocol=E2=80=9D = specification, however i can make > that clearer >=20 > > > > * Section 8 - You have a problem in that there are no rules in RFC > > 7638 for dealing with serialization of integers. Given that some of > > the fields in the JWT are integers this needs to be addressed. You > > might want to move this justification to the top of the document so > > that people are prepared for and look for this. >=20 > wondering if the best way to solve this is to note it and make sure = that for any > passport extensions that use compact form, they specify the handling = integers. >=20 > > > > * Section 8 - Wording problem with saying that "dest" and "mky" need > > to follow their OWN rules. Are these really defined elsewhere or do > > you just use the standard rules recursively. >=20 > will try to clarify >=20 > > > > * Section 9.2 - Consider using a list structure for the asterisk > > leading list in this section. >=20 > Yep, this was just a missed formatting problem >=20 > > > > * Section 10.1.1 - Encoding Considerations - This could be 7 bit as > > the value is base64 encoded for normal values and would be UTF8 if = you > > used the full JOSE signature structure which you do not. >=20 > Ok, will look at changing this. >=20 > > > > * General - I was really tired when I read through this and I kept > > getting tripped up on prose. I did not write down all of the items > > which bothered me and now I have read it enough that it is harder = for me to > locate them. > > However, I would request that the authors perform some method of > > detailed reading to check for this. I frequently read the text = aloud > > to myself for this purpose. Alternatively, you can just wait for = the copy > editors. > > > > Jim > > > > > > ------=_NextPart_000_00CC_01D22559.4F4CDC80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I went back to re-read the document and figure out = where my confusion was on the issue of who the 'orig' and 'dest' = referred to.=C2=A0 This is what I find.

 

Origination in the context of PASSporT and for a = given application's use of PASSporT is the = point in the network that has the authority to assert the caller = identity.

 

The text then goes on to talk about certificates, = which I made the assumption referred to the same certificate as appears = in the JWT header under the =E2=80=98x5u=E2=80=99 name.

 

I = think from this is it not unreasonable that I made the assumption that = the =E2=80=98orig=E2=80=99 field referred not the caller originator but = to the issuer of the PASSporT.

 

jim

 

> = -----Original Message-----

> From: Chris = Wendt [mailto:chris-ietf@chriswendt.net]

> = Sent: Wednesday, October 12, 2016 12:31 PM

> To: Jim Schaad = <ietf@augustcellars.com>

> Cc: = draft-ietf-stir-passport@ietf.org; stir@ietf.org

> Subject: Re: draft-ietf-stir-passport-08

>

> HI Jim,

>

> Thanks for = the comprehensive review.=C2=A0 I am working through some of the = fixes

> based on your comments.

> Meanwhile i have the following responses = inline.

>

> = -Chris

>

> =

> > On Oct 8, 2016, at 2:15 PM, Jim = Schaad <ietf@augustcellars.com> wrote:

> >

> > Here is a review of the document as a = whole.

> >

> > * Section 4 - para 3 - The term "key = values" is potentially ambiguous.

> = > This could refer either to the value of the key or the value the = key

> > is pointing to.=C2=A0 I would = suggest making this clear.

>

> I will use the term=C2=A0 =E2=80=9Cclaim = value=E2=80=9D which is a RFC 7519 term.=C2=A0 One additional

> question is whether we say same thing for = =E2=80=9Cclaim name=E2=80=9D as well?=C2=A0 I suppose we

> allow it.

> =

> >

> = > * Section 4 - para 3 - The form you are using for encoding of = claims

> > values has two = problems.=C2=A0 The first is that this does not match what

> > the JSON document says to use = "\uXXXX".=C2=A0 The second is that as

> > written, it is ambiguous.=C2=A0 If I have = the US-ASCII string of "%ABCD"

> = > then it does not need to be percent encoded as the string is not = outside of the

> US-ASCII range.

>

> Could you = provide a pointer to the use of =E2=80=9C\uXXX" specifically, we = had a working

> group discussion on this = text, but if there is something existing, i haven=E2=80=99t been

> able to find it.

>

> >

> >=C2=A0 * Section 4.2.1 - General - I am = having a hard time with this section

> = > because it is not highlighting the last piece of information that = I

> > think I need to understand for = this.=C2=A0 From what I read, I think that

> > dest =3D=3D aud in terms of JWT - that is = the target of the statement.

> > Orig = =3D=3D iss in terms of JWT - that is the entity that issued the

> > statement.=C2=A0 I don't see anything = that is telling me what the sub of the JWT is

> supposed to be.

> >

> > It = would also be good to say why different items are being defined

> > that appear to be the same thing as = already exist in JWT terms. (Yes,

> > = at the core it is because the types are different.)

>

> I = don=E2=80=99t believe the mapping of aud and iss are appropriate = here.=C2=A0 The =E2=80=9Corig=E2=80=9D and

> =E2=80=9Cdest=E2=80=9D claim is specifically = the asserted identity, telephone number of caller and

> callee, but may not correspond to the = issuer/signer of the JWT, e.g. service

> = provider.

>

> I can explain this in the text if that is = helpful.

>

> >

> > * = Section 4.2.X - you are not telling me that these are arrays of

> > "some type" rather than the = "some type=E2=80=9D.

>

> sorry, i=E2=80=99m having trouble figuring out = what you mean by this

>

> >

> > * = Section 4.2.2 - You are stating that things must occur in a = specific

> > order.=C2=A0 This is not = "normal" JSON behavior and not all JSON

> > serializers may be able to support this = behavior.=C2=A0 I think you need

> > = some justification someplace.

>

> I plan to move this to the compact form = section, since ordering is only really

> = needed for compact form now.

>

> >

> > * = Section 5 - I am having a hard time finding the lexicographic = order

> > and white space rules = quickly.=C2=A0 A pointer might be reasonable.

>

> same answer = as above.

>

> >

> > * = Section 7 - One issue that I think you need to address in the

> > extension section is that signaling = protocols need to identify what

> > = these new items are so that they can be picked up and placed into = the

> > PASSporT when it is = reconstructed.=C2=A0 The destination does not have to

> > understand the extension, but it does = need to understand that the extension

> = exists.

>

> = This will be defined in the =E2=80=9Cusing protocol=E2=80=9D = specification, however i can make

> that = clearer

>

> = >

> > * Section 8 - You have a = problem in that there are no rules in RFC

> > 7638 for dealing with serialization of = integers.=C2=A0 Given that some of

> > = the fields in the JWT are integers this needs to be addressed.=C2=A0 = You

> > might want to move this = justification to the top of the document so

> > that people are prepared for and look for = this.

>

> = wondering if the best way to solve this is to note it and make sure that = for any

> passport extensions that use = compact form, they specify the handling integers.

>

> >

> > * Section 8 - Wording problem with saying = that "dest" and "mky" need

> > to follow their OWN rules.=C2=A0 Are = these really defined elsewhere or do

> = > you just use the standard rules recursively.

>

> will try to = clarify

>

> = >

> > * Section 9.2 - Consider using = a list structure for the asterisk

> > = leading list in this section.

>

> Yep, this was just a missed formatting = problem

>

> = >

> > * Section 10.1.1 - Encoding = Considerations - This could be 7 bit as

> = > the value is base64 encoded for normal values and would be UTF8 if = you

> > used the full JOSE signature = structure which you do not.

>

> Ok, will look at changing this.

>

> >

> > * General - I was really tired when I = read through this and I kept

> > = getting tripped up on prose.=C2=A0 I did not write down all of the = items

> > which bothered me and now I = have read it enough that it is harder for me to

> locate them.

> = > However, I would request that the authors perform some method = of

> > detailed reading to check for = this.=C2=A0 I frequently read the text aloud

> > to myself for this purpose.=C2=A0 = Alternatively, you can just wait for the copy

> editors.

> = >

> > Jim

> >

> = >

> >

------=_NextPart_000_00CC_01D22559.4F4CDC80-- From nobody Thu Oct 13 19:29:45 2016 Return-Path: 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 8E12A1295A9 for ; Thu, 13 Oct 2016 19:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 qzqymJwNnOsz for ; Thu, 13 Oct 2016 19:29:40 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 601B81295AA for ; Thu, 13 Oct 2016 19:29:40 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id m5so61965036qtb.3 for ; Thu, 13 Oct 2016 19:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Un2+X5la8HnA/nUEM+DaZ3VYX887ENMu6+U1ygmbZUs=; b=v6HxpzgzS3xb2w5K3vaSQPq7y8Run2/KisBTjUZ5bK2kCdmLFC3IF9n5F3goFbIy3E 1oYZrkgm/jx+iSDBLBGJ7qfGVzKitVJW6vC7DCmLcOFrqf6isGkPdUIrHpcQhFRQl2DE 2vDe+nvy5FDtkKqugYfetZRquisuSFF1+Z4eIQeTEVqvKDRd1iCqiuxlzNWRs3wXUp0b 61UPehKIxBg6wIrAou8ivRHUhQZioOCwfYiCAiCcgvwoB27s+czd/kQhkeEbQE9l40xk y24qyqbsFQQoNBdP8kkzlF6aslwsf1H3zO1DpSF/OJSdixBv4EhDKSCPJCw9//fjM70G qB5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Un2+X5la8HnA/nUEM+DaZ3VYX887ENMu6+U1ygmbZUs=; b=RTlqusLq/dlHJbmCBzvvWzqCRkv0m1s8EaZWFSE95F/VnBCBgae631TM/IIcyyd69w ZMiLdJdPxadseoj+pA9TO2ngeaZh/piyE+4z8X7ba5+dmakKYu91Q1FJZXRCzxbL+vOG yPsnkq01E3630XzGhzz9EYrr15GliBLyb7PpUoCEWDvrW3J7WmYYzVOT8Jbv86uJ1tQB 9VcjVXdkBZV5uHcFP27JqubbmkiOb/p/rMMDKO/0vtW33QnGYgLin1lJ1p4r5QDAgaVp wGoyt0i2/tu7R6KbNVUO0rUrvh5TcZKNGL8I+3NESeQb6gwo+7+ycHvKZ20X3rXDlbH0 QALg== X-Gm-Message-State: AA6/9RnarT21xF9y8WhXtJvP/D9XUCKE13WACUEkCarWzMrnXCakUxz8E/EpAPN5c8xIDQ== X-Received: by 10.200.35.229 with SMTP id r34mr10155353qtr.22.1476412179434; Thu, 13 Oct 2016 19:29:39 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:c85d:e32b:717d:d299? ([2601:41:c101:9364:c85d:e32b:717d:d299]) by smtp.gmail.com with ESMTPSA id a26sm6438709qka.2.2016.10.13.19.29.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Oct 2016 19:29:38 -0700 (PDT) From: Chris Wendt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E10BAE6E-A873-4A01-BCB0-41544921A6E6" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Thu, 13 Oct 2016 22:29:35 -0400 In-Reply-To: <0c3801d224f3$60030830$20091890$@augustcellars.com> To: Jim Schaad References: <065e01d2218f$fea323b0$fbe96b10$@augustcellars.com> <0c3801d224f3$60030830$20091890$@augustcellars.com> X-Mailer: Apple Mail (2.3226) Archived-At: Cc: stir@ietf.org, draft-ietf-stir-passport@ietf.org Subject: Re: [stir] draft-ietf-stir-passport-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 02:29:43 -0000 --Apple-Mail=_E10BAE6E-A873-4A01-BCB0-41544921A6E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jim, Thanks for the clarifications. Answers inline. > On Oct 12, 2016, at 9:44 PM, Jim Schaad = wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Chris Wendt [mailto:chris-ietf@chriswendt.net] >> Sent: Wednesday, October 12, 2016 12:31 PM >> To: Jim Schaad >> Cc: draft-ietf-stir-passport@ietf.org; stir@ietf.org >> Subject: Re: draft-ietf-stir-passport-08 >>=20 >> HI Jim, >>=20 >> Thanks for the comprehensive review. I am working through some of = the fixes >> based on your comments. >> Meanwhile i have the following responses inline. >>=20 >> -Chris >>=20 >>=20 >>> On Oct 8, 2016, at 2:15 PM, Jim Schaad = wrote: >>>=20 >>> Here is a review of the document as a whole. >>>=20 >>> * Section 4 - para 3 - The term "key values" is potentially = ambiguous. >>> This could refer either to the value of the key or the value the key >>> is pointing to. I would suggest making this clear. >>=20 >> I will use the term =E2=80=9Cclaim value=E2=80=9D which is a RFC = 7519 term. One additional >> question is whether we say same thing for =E2=80=9Cclaim name=E2=80=9D = as well? I suppose we >> allow it >=20 > As long as it is clear what is a key and what is a value for the = purposes of JSON, I don't think it makes any difference. My problem = with the term was that it had both terms so yes "claim name" or "claim = key" would seem to make sense. However both the JSON document and JWT = both seem to prefer "name" to "key". I will note that JWT seems to = prefer prefixing claim to both name and value.=20 good, will also make sure this is consistent in the full document. > . >>=20 >>>=20 >>> * Section 4 - para 3 - The form you are using for encoding of claims >>> values has two problems. The first is that this does not match what >>> the JSON document says to use "\uXXXX". The second is that as >>> written, it is ambiguous. If I have the US-ASCII string of "%ABCD" >>> then it does not need to be percent encoded as the string is not = outside of the >> US-ASCII range. >>=20 >> Could you provide a pointer to the use of =E2=80=9C\uXXX" = specifically, we had a working >> group discussion on this text, but if there is something existing, i = haven=E2=80=99t been >> able to find it. >=20 > This is from the JSON document 7159 section 7 (Strings). Thus it = should be the default behavior for JSON serialization code. Ok, so i will say "Any claim name or claim values outside the US-ASCII = range should follow the default JSON serialization defined in [RFC7519] = Section 7." >=20 >>=20 >>>=20 >>> * Section 4.2.1 - General - I am having a hard time with this = section >>> because it is not highlighting the last piece of information that I >>> think I need to understand for this. =46rom what I read, I think = that >>> dest =3D=3D aud in terms of JWT - that is the target of the = statement. >>> Orig =3D=3D iss in terms of JWT - that is the entity that issued the >>> statement. I don't see anything that is telling me what the sub of = the JWT is >> supposed to be. >>>=20 >>> It would also be good to say why different items are being defined >>> that appear to be the same thing as already exist in JWT terms. = (Yes, >>> at the core it is because the types are different.) >>=20 >> I don=E2=80=99t believe the mapping of aud and iss are appropriate = here. The =E2=80=9Corig=E2=80=9D and >> =E2=80=9Cdest=E2=80=9D claim is specifically the asserted identity, = telephone number of caller and >> callee, but may not correspond to the issuer/signer of the JWT, e.g. = service >> provider. >>=20 >> I can explain this in the text if that is helpful. >=20 > I am more worried about the fact that when I read the document, I = thought that 'orig' was associated with the entity making the claim - = i.e. the service provider and not with the call originator than I am = about the question of equivalence to the existing JWT claims. =20 I will review the text and see if i can make that more clear, however i = think we are stuck with a concept that is a bit unintuitive by default = unfortunately. >=20 >>=20 >>>=20 >>> * Section 4.2.X - you are not telling me that these are arrays of >>> "some type" rather than the "some type=E2=80=9D. >>=20 >> sorry, i=E2=80=99m having trouble figuring out what you mean by this >=20 > I can understand some of your confusion and I got it partly wrong - I = was looking at 4.2.2 not 4.2.1 when I wrote the text. >=20 > 4.2.1 contains the text "The "orig" JSON object MUST only have one key = value pair representing > the asserted identity of any type (currently either "tn" or "uri") = of > the originator of the personal communications signaling."=20 >=20 > The above is the only place that I can see that says that "orig" is a = JSON object. Separating this into two different sentences would make it = clear that 1) it is and object and 2) the object can only have one = name/value pair. Got it thanks for the clarification >=20 > In section 4.2.2 - I did not see any clear text before getting to the = example about the array/object question for the "mky" name. Looking at = just the one example, I would not see that there is a distinction = between having a single value and having multiple values as it is not = clearly highlighted. It might be good to break the first paragraph into = multiple ones each dealing with different parts of the constructed item. = Simple language makes things easier to understand. good, will clarify that >=20 >>=20 >>>=20 >>> * Section 4.2.2 - You are stating that things must occur in a = specific >>> order. This is not "normal" JSON behavior and not all JSON >>> serializers may be able to support this behavior. I think you need >>> some justification someplace. >>=20 >> I plan to move this to the compact form section, since ordering is = only really >> needed for compact form now. >=20 > I need to look; however, memory says that only the PASSporT compact = form was allowed. =20 No, we support both, but would be good to make that clear. >=20 >>=20 >>>=20 >>> * Section 5 - I am having a hard time finding the lexicographic = order >>> and white space rules quickly. A pointer might be reasonable. >>=20 >> same answer as above. >>=20 >>>=20 >>> * Section 7 - One issue that I think you need to address in the >>> extension section is that signaling protocols need to identify what >>> these new items are so that they can be picked up and placed into = the >>> PASSporT when it is reconstructed. The destination does not have to >>> understand the extension, but it does need to understand that the = extension >> exists. >>=20 >> This will be defined in the =E2=80=9Cusing protocol=E2=80=9D = specification, however i can make >> that clearer >>=20 >>>=20 >>> * Section 8 - You have a problem in that there are no rules in RFC >>> 7638 for dealing with serialization of integers. Given that some of >>> the fields in the JWT are integers this needs to be addressed. You >>> might want to move this justification to the top of the document so >>> that people are prepared for and look for this. >>=20 >> wondering if the best way to solve this is to note it and make sure = that for any >> passport extensions that use compact form, they specify the handling = integers. >=20 > That would be the base specification with the "iat" claim. This is a = NumericDate - that is an integer since. Canonicalization is not a = problem for JWT as the claim is transported so the form is fixed. Right, for =E2=80=9Ciat=E2=80=9D i think we are good. >=20 >>=20 >>>=20 >>> * Section 8 - Wording problem with saying that "dest" and "mky" need >>> to follow their OWN rules. Are these really defined elsewhere or do >>> you just use the standard rules recursively. >>=20 >> will try to clarify >>=20 >>>=20 >>> * General - I was really tired when I read through this and I kept >>> getting tripped up on prose. I did not write down all of the items >>> which bothered me and now I have read it enough that it is harder = for me to >> locate them. >>> However, I would request that the authors perform some method of >>> detailed reading to check for this. I frequently read the text = aloud >>> to myself for this purpose. Alternatively, you can just wait for = the copy >> editors. >>>=20 >>> Jim --Apple-Mail=_E10BAE6E-A873-4A01-BCB0-41544921A6E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Jim,  Thanks for the clarifications.  Answers = inline.

On Oct 12, 2016, at 9:44 PM, Jim Schaad = <ietf@augustcellars.com> wrote:



-----Original = Message-----
From: Chris Wendt [mailto:chris-ietf@chriswendt.net]
Sent: = Wednesday, October 12, 2016 12:31 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-stir-passport@ietf.org; stir@ietf.org
Subject: Re: draft-ietf-stir-passport-08

HI Jim,

Thanks for the = comprehensive review.  I am working through some of the fixes
based on your comments.
Meanwhile i have the = following responses inline.

-Chris


On Oct 8, 2016, at 2:15 PM, Jim Schaad <ietf@augustcellars.com> wrote:

Here is a review of the document as a whole.

* Section 4 - para 3 - The term "key values" is potentially = ambiguous.
This could refer either to the value of the key = or the value the key
is pointing to.  I would suggest = making this clear.

I will use = the term  =E2=80=9Cclaim value=E2=80=9D which is a RFC 7519 term. =  One additional
question is whether we say same thing = for =E2=80=9Cclaim name=E2=80=9D as well?  I suppose we
allow it

As long as it is clear what is a key and = what is a value for the purposes of JSON, I don't think it makes any = difference.  My problem with the term was that it had both terms so = yes "claim name" or "claim key" would seem to make sense.  However = both the JSON document and JWT both seem to prefer "name" to "key". =  I will note that JWT seems to prefer prefixing claim to both name = and value. 

good, will also make sure this is consistent in the = full document.

.


* Section 4 - para 3 - The form you are using for encoding of = claims
values has two problems.  The first is that = this does not match what
the JSON document says to use = "\uXXXX".  The second is that as
written, it is = ambiguous.  If I have the US-ASCII string of "%ABCD"
then it does not need to be percent encoded as the string is = not outside of the
US-ASCII range.

Could you provide a pointer to the use of = =E2=80=9C\uXXX" specifically, we had a working
group = discussion on this text, but if there is something existing, i haven=E2=80= =99t been
able to find it.

This is from the = JSON document 7159 section 7 (Strings).  Thus it should be the = default behavior for JSON serialization code.

Ok, so i will say "Any claim name or claim values = outside the US-ASCII range should follow the default JSON serialization = defined in [RFC7519] Section 7."




* Section 4.2.1 - General - I am = having a hard time with this section
because it is not = highlighting the last piece of information that I
think I = need to understand for this.  =46rom what I read, I think that
dest =3D=3D aud in terms of JWT - that is the target of the = statement.
Orig =3D=3D iss in terms of JWT - that is the = entity that issued the
statement.  I don't see = anything that is telling me what the sub of the JWT is
supposed to be.

It would also be good to say why = different items are being defined
that appear to be the = same thing as already exist in JWT terms. (Yes,
at the = core it is because the types are different.)

I don=E2=80=99t believe the = mapping of aud and iss are appropriate here.  The =E2=80=9Corig=E2=80= =9D and
=E2=80=9Cdest=E2=80=9D claim is specifically the = asserted identity, telephone number of caller and
callee, = but may not correspond to the issuer/signer of the JWT, e.g. service
provider.

I can explain this in = the text if that is helpful.

I am more worried = about the fact that when I read the document, I thought that 'orig' was = associated with the entity making the claim - i.e. the service provider = and not with the call originator than I am about the question of = equivalence to the existing JWT claims.  

I will review the text and see if i can make that = more clear, however i think we are stuck with a concept that is a bit = unintuitive by default unfortunately.




* Section 4.2.X - you are not = telling me that these are arrays of
"some type" rather = than the "some type=E2=80=9D.

sorry, i=E2=80=99m having trouble figuring out what you mean = by this

I can understand some of your confusion = and I got it partly wrong - I was looking at 4.2.2 not 4.2.1 when I = wrote the text.

4.2.1 contains the = text "The "orig" JSON object MUST only have one key value pair = representing
  the asserted identity of any type = (currently either "tn" or "uri") of
  the originator of the = personal communications signaling." 

The above is the only place that I can = see that says that "orig" is a JSON object.  Separating this into = two different sentences would make it clear that 1) it is and object and = 2) the object can only have one name/value pair.

Got it thanks for the clarification


In section 4.2.2 - = I did not see any clear text before getting to the example about the = array/object question for the "mky" name.   Looking at just = the one example, I would not see that there is a distinction between = having a single value and having multiple values as it is not clearly = highlighted.  It might be good to break the first paragraph into = multiple ones each dealing with different parts of the constructed item. =  Simple language makes things easier to understand.

good, will clarify that




* Section 4.2.2 - You are stating that things must occur in a = specific
order.  This is not "normal" JSON behavior = and not all JSON
serializers may be able to support this = behavior.  I think you need
some justification = someplace.

I plan to move this = to the compact form section, since ordering is only really
needed for compact form now.

I need to look; = however, memory says that only the PASSporT compact form was allowed. =  

No, we = support both, but would be good to make that clear.




* Section 5 - I am having a hard time finding the = lexicographic order
and white space rules quickly.  A = pointer might be reasonable.

same answer as above.


* Section 7 - One issue that I = think you need to address in the
extension section is that = signaling protocols need to identify what
these new items = are so that they can be picked up and placed into the
PASSporT when it is reconstructed.  The destination does = not have to
understand the extension, but it does need to = understand that the extension
exists.

This will be defined in the =E2=80=9Cusing = protocol=E2=80=9D specification, however i can make
that = clearer


* Section 8 - You have a problem in that there = are no rules in RFC
7638 for dealing with serialization of = integers.  Given that some of
the fields in the JWT = are integers this needs to be addressed.  You
might = want to move this justification to the top of the document so
that people are prepared for and look for this.

wondering if the best way to = solve this is to note it and make sure that for any
passport= extensions that use compact form, they specify the handling = integers.

That would be the base specification with = the "iat" claim.  This is a NumericDate - that is an integer since. =   Canonicalization is not a problem for JWT as the claim is = transported so the form is fixed.

Right, = for =E2=80=9Ciat=E2=80=9D i think we are good.




* Section 8 - Wording problem with saying that "dest" and = "mky" need
to follow their OWN rules.  Are these = really defined elsewhere or do
you just use the standard = rules recursively.

will try to = clarify


* General - I was really tired when I read = through this and I kept
getting tripped up on prose. =  I did not write down all of the items
which bothered = me and now I have read it enough that it is harder for me to
locate them.
However, I would request that the authors = perform some method of
detailed reading to check for this. =  I frequently read the text aloud
to myself for this = purpose.  Alternatively, you can just wait for the copy
editors.

Jim

= --Apple-Mail=_E10BAE6E-A873-4A01-BCB0-41544921A6E6-- From nobody Thu Oct 13 19:33:38 2016 Return-Path: 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 2988012940D for ; Thu, 13 Oct 2016 19:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 wjpweK8SNuy0 for ; Thu, 13 Oct 2016 19:33:35 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 AE8A71295A8 for ; Thu, 13 Oct 2016 19:33:34 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id f128so117709741qkb.1 for ; Thu, 13 Oct 2016 19:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zvn2SIuP5Qfoff3vo8BpcT3DGudBkSkuju8j7/eVTpg=; b=TYzR7CCtuC+rxHqTy+KBKzDtwnqryL2QqSgH4edaLPooKE4XelqCplXmKaLAWB4ays HPYLXfv+WU6sSnGhwQOIlJ5wDVSKZrtDezWun+hvcuQQyTEQho5Ia8IwMHzFZSejaCud ZQ2icdQuTEzHEPcH4rMT0QiDqFnm2t7C7H4k8tdUGGCHrJLEAUjoALYYr0GrI6YS0H53 bRNTe9S+LAlfo3zt5d0qbLrXfPihKMJSV4GBBCSWikppXpjYSktIa74nZap+lXq41hcO DnMHZTGVdkfOjhVp4w0SyGUT5HIbWptMCJfc6qlDot2PZhe+n7VQNezNPKa8iUJOYJAe 9yTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zvn2SIuP5Qfoff3vo8BpcT3DGudBkSkuju8j7/eVTpg=; b=lDyvZg0+0dbNWX/DjLChxGnRLs5h5fnGx7iYrHCUpSUuxRBREO87sRbqBnB9dQNrTj nkNs8C1yunWL3LzVf2UZ2Y76AO3NGpj+OZqyt2kfV43jzuNrNr/SDm8RK6A1VgRbb/pM zf3KvE8AZ7/YXyFnewfLaw0v7xEqhGn3a8AfBAWxA00ijDRjEuaCsC0wj4L/zytRUri/ 0bvwm3D/t6OjtzdRpsaDbU21S5S0erb4Fni1eKurhgXy+Z9T1QUpRmWMbIypSFYEZCii POedlTdJFFHzQDk3AGdx/OZixbFrgt++o1wple6Bp/gPxB9kS5qqOuvYOu2rLRMPGhU6 qeuQ== X-Gm-Message-State: AA6/9RnugfLxt4bf3n7CMThOibeFmA1dsEP/xzazUh1YSgkQvXMG/WJQ7FREaLobmvsEKg== X-Received: by 10.55.39.20 with SMTP id n20mr9395979qkn.252.1476412406237; Thu, 13 Oct 2016 19:33:26 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:c85d:e32b:717d:d299? ([2601:41:c101:9364:c85d:e32b:717d:d299]) by smtp.gmail.com with ESMTPSA id s16sm6443283qtc.25.2016.10.13.19.33.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Oct 2016 19:33:25 -0700 (PDT) From: Chris Wendt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3E073E7E-DB7E-43BC-90D7-A0D8DEADE447" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Thu, 13 Oct 2016 22:33:24 -0400 In-Reply-To: <00cb01d22593$fba8ce50$f2fa6af0$@augustcellars.com> To: Jim Schaad References: <065e01d2218f$fea323b0$fbe96b10$@augustcellars.com> <00cb01d22593$fba8ce50$f2fa6af0$@augustcellars.com> X-Mailer: Apple Mail (2.3226) Archived-At: Cc: stir@ietf.org, draft-ietf-stir-passport@ietf.org Subject: Re: [stir] draft-ietf-stir-passport-08 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 02:33:37 -0000 --Apple-Mail=_3E073E7E-DB7E-43BC-90D7-A0D8DEADE447 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jim, The certificate used for the signature does represent the issuer and is = indicated in the x5u. But i think i get your confusion about what =E2=80=98orig=E2=80=99 = represents as stated in your last message and will see if there is any = more clarity i can provide. Thanks again! -Chris > On Oct 13, 2016, at 4:54 PM, Jim Schaad = wrote: >=20 > I went back to re-read the document and figure out where my confusion = was on the issue of who the 'orig' and 'dest' referred to. This is what = I find. > =20 > Origination in the context of PASSporT and for a given application's = use of PASSporT is the point in the network that has the authority to = assert the caller identity. > =20 > The text then goes on to talk about certificates, which I made the = assumption referred to the same certificate as appears in the JWT header = under the =E2=80=98x5u=E2=80=99 name. > =20 > I think from this is it not unreasonable that I made the assumption = that the =E2=80=98orig=E2=80=99 field referred not the caller originator = but to the issuer of the PASSporT. > =20 > jim > =20 > > -----Original Message----- > > From: Chris Wendt [mailto:chris-ietf@chriswendt.net = ] > > Sent: Wednesday, October 12, 2016 12:31 PM > > To: Jim Schaad > > > Cc: draft-ietf-stir-passport@ietf.org = ; stir@ietf.org = > > Subject: Re: draft-ietf-stir-passport-08 > > > > HI Jim, > > > > Thanks for the comprehensive review. I am working through some of = the fixes > > based on your comments. > > Meanwhile i have the following responses inline. > > > > -Chris > > > > > > > On Oct 8, 2016, at 2:15 PM, Jim Schaad > wrote: > > > > > > Here is a review of the document as a whole. > > > > > > * Section 4 - para 3 - The term "key values" is potentially = ambiguous. > > > This could refer either to the value of the key or the value the = key > > > is pointing to. I would suggest making this clear. > > > > I will use the term =E2=80=9Cclaim value=E2=80=9D which is a RFC = 7519 term. One additional > > question is whether we say same thing for =E2=80=9Cclaim name=E2=80=9D= as well? I suppose we > > allow it. > > > > > > > > * Section 4 - para 3 - The form you are using for encoding of = claims > > > values has two problems. The first is that this does not match = what > > > the JSON document says to use "\uXXXX". The second is that as > > > written, it is ambiguous. If I have the US-ASCII string of = "%ABCD" > > > then it does not need to be percent encoded as the string is not = outside of the > > US-ASCII range. > > > > Could you provide a pointer to the use of =E2=80=9C\uXXX" = specifically, we had a working > > group discussion on this text, but if there is something existing, i = haven=E2=80=99t been > > able to find it. > > > > > > > > * Section 4.2.1 - General - I am having a hard time with this = section > > > because it is not highlighting the last piece of information that = I > > > think I need to understand for this. =46rom what I read, I think = that > > > dest =3D=3D aud in terms of JWT - that is the target of the = statement. > > > Orig =3D=3D iss in terms of JWT - that is the entity that issued = the > > > statement. I don't see anything that is telling me what the sub = of the JWT is > > supposed to be. > > > > > > It would also be good to say why different items are being defined > > > that appear to be the same thing as already exist in JWT terms. = (Yes, > > > at the core it is because the types are different.) > > > > I don=E2=80=99t believe the mapping of aud and iss are appropriate = here. The =E2=80=9Corig=E2=80=9D and > > =E2=80=9Cdest=E2=80=9D claim is specifically the asserted identity, = telephone number of caller and > > callee, but may not correspond to the issuer/signer of the JWT, e.g. = service > > provider. > > > > I can explain this in the text if that is helpful. > > > > > > > > * Section 4.2.X - you are not telling me that these are arrays of > > > "some type" rather than the "some type=E2=80=9D. > > > > sorry, i=E2=80=99m having trouble figuring out what you mean by this > > > > > > > > * Section 4.2.2 - You are stating that things must occur in a = specific > > > order. This is not "normal" JSON behavior and not all JSON > > > serializers may be able to support this behavior. I think you = need > > > some justification someplace. > > > > I plan to move this to the compact form section, since ordering is = only really > > needed for compact form now. > > > > > > > > * Section 5 - I am having a hard time finding the lexicographic = order > > > and white space rules quickly. A pointer might be reasonable. > > > > same answer as above. > > > > > > > > * Section 7 - One issue that I think you need to address in the > > > extension section is that signaling protocols need to identify = what > > > these new items are so that they can be picked up and placed into = the > > > PASSporT when it is reconstructed. The destination does not have = to > > > understand the extension, but it does need to understand that the = extension > > exists. > > > > This will be defined in the =E2=80=9Cusing protocol=E2=80=9D = specification, however i can make > > that clearer > > > > > > > > * Section 8 - You have a problem in that there are no rules in RFC > > > 7638 for dealing with serialization of integers. Given that some = of > > > the fields in the JWT are integers this needs to be addressed. = You > > > might want to move this justification to the top of the document = so > > > that people are prepared for and look for this. > > > > wondering if the best way to solve this is to note it and make sure = that for any > > passport extensions that use compact form, they specify the handling = integers. > > > > > > > > * Section 8 - Wording problem with saying that "dest" and "mky" = need > > > to follow their OWN rules. Are these really defined elsewhere or = do > > > you just use the standard rules recursively. > > > > will try to clarify > > > > > > > > * Section 9.2 - Consider using a list structure for the asterisk > > > leading list in this section. > > > > Yep, this was just a missed formatting problem > > > > > > > > * Section 10.1.1 - Encoding Considerations - This could be 7 bit = as > > > the value is base64 encoded for normal values and would be UTF8 if = you > > > used the full JOSE signature structure which you do not. > > > > Ok, will look at changing this. > > > > > > > > * General - I was really tired when I read through this and I kept > > > getting tripped up on prose. I did not write down all of the = items > > > which bothered me and now I have read it enough that it is harder = for me to > > locate them. > > > However, I would request that the authors perform some method of > > > detailed reading to check for this. I frequently read the text = aloud > > > to myself for this purpose. Alternatively, you can just wait for = the copy > > editors. > > > > > > Jim > > > > > > > > > --Apple-Mail=_3E073E7E-DB7E-43BC-90D7-A0D8DEADE447 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Jim,

The= certificate used for the signature does represent the issuer and is = indicated in the x5u.

But i think i get your confusion about what =E2=80=98orig=E2=80= =99 represents as stated in your last message and will see if there is = any more clarity i can provide.

Thanks again!

-Chris


On Oct 13, 2016, at 4:54 PM, = Jim Schaad <ietf@augustcellars.com> wrote:

I went back to re-read the = document and figure out where my confusion was on the issue of who the = 'orig' and 'dest' referred to.  This is what I find.
 
Origination= in the context of PASSporT and for a given application's use of = PASSporT is the point in the network that has the = authority to = assert the caller identity.
 
The text then goes on to talk about = certificates, which I made the assumption referred to the same = certificate as appears in the JWT header under the =E2=80=98x5u=E2=80=99 = name.
 
I think = from this is it not unreasonable that I made the assumption that the = =E2=80=98orig=E2=80=99 field referred not the caller originator but to = the issuer of the PASSporT.
 
jim
 
> -----Original = Message-----
> From: Chris = Wendt [mailto:chris-ietf@chriswendt.net]
> Sent: Wednesday, October 12, 2016 = 12:31 PM
> To: Jim Schaad <ietf@augustcellars.com>
> Subject: Re: = draft-ietf-stir-passport-08
>
> HI = Jim,
>
> Thanks for the comprehensive = review.  I am working through some of the fixes
> based on your comments.
> Meanwhile i have the following = responses inline.
>
> = -Chris
>
>
> > On Oct 8, 2016, at 2:15 PM, Jim Schaad <ietf@augustcellars.com> wrote:
> >
> > Here is a review of the document as a = whole.
> >
> > * Section 4 - para 3 - The = term "key values" is potentially ambiguous.
> > This could refer either to the value of the key or = the value the key
> > = is pointing to.  I would suggest making this clear.
>
> I will use the term  =E2=80=9Cclaim value=E2=80=9D = which is a RFC 7519 term.  One additional
> question is whether we say same thing for =E2=80=9Cclaim = name=E2=80=9D as well?  I suppose we
> allow it.
>
> >
> > * Section 4 - para 3 - The = form you are using for encoding of claims
> > values has two problems.  The first is that = this does not match what
> > = the JSON document says to use "\uXXXX".  The second is that = as
> > written, it is = ambiguous.  If I have the US-ASCII string of "%ABCD"
> > then it does not need to be = percent encoded as the string is not outside of the
> US-ASCII range.
>
> Could you provide a pointer to the use of =E2=80=9C\uXXX" = specifically, we had a working
> group discussion on this text, but if there is something = existing, i haven=E2=80=99t been
> able to find it.
>
> >
> >  * Section 4.2.1 - = General - I am having a hard time with this section
> > because it is not = highlighting the last piece of information that I
> > think I need to understand = for this.  =46rom what I read, I think that
> > dest =3D=3D aud in terms of = JWT - that is the target of the statement.
> > Orig =3D=3D iss in terms of JWT - that is the = entity that issued the
> > = statement.  I don't see anything that is telling me what the sub of = the JWT is
> supposed to = be.
> >
> > It would also be good to say = why different items are being defined
> > that appear to be the same thing as already exist = in JWT terms. (Yes,
> > = at the core it is because the types are different.)
>
> I don=E2=80=99t believe the mapping of aud and iss are = appropriate here.  The =E2=80=9Corig=E2=80=9D and
> =E2=80=9Cdest=E2=80=9D claim is = specifically the asserted identity, telephone number of caller = and
> callee, but may not = correspond to the issuer/signer of the JWT, e.g. service
> provider.
>
> I can explain = this in the text if that is helpful.
>
> >
> > * Section 4.2.X - you are not = telling me that these are arrays of
> > "some type" rather than the "some = type=E2=80=9D.
>
> sorry, i=E2=80=99m having trouble = figuring out what you mean by this
>
> >
> > * Section 4.2.2 - You are = stating that things must occur in a specific
> > order.  This is not "normal" JSON behavior and = not all JSON
> > = serializers may be able to support this behavior.  I think you = need
> > some = justification someplace.
>
> I plan to move = this to the compact form section, since ordering is only = really
> needed for compact = form now.
>
> >
> > * Section 5 - I am having a hard time finding the = lexicographic order
> > = and white space rules quickly.  A pointer might be = reasonable.
>
> same answer as above.
>
> >
> > = * Section 7 - One issue that I think you need to address in = the
> > extension = section is that signaling protocols need to identify what
> > these new items are so that = they can be picked up and placed into the
> > PASSporT when it is reconstructed.  The = destination does not have to
> > understand the extension, but it does need to = understand that the extension
> exists.
>
> This will be = defined in the =E2=80=9Cusing protocol=E2=80=9D specification, however i = can make
> that = clearer
>
> >
> > * Section 8 - You have a problem in that there are = no rules in RFC
> > 7638 for = dealing with serialization of integers.  Given that some = of
> > the fields in = the JWT are integers this needs to be addressed.  You
> > might want to move this = justification to the top of the document so
> > that people are prepared for and look for = this.
>
> wondering if the best way to solve = this is to note it and make sure that for any
> passport extensions that use compact form, they specify = the handling integers.
>
> >
> > * Section 8 - Wording problem = with saying that "dest" and "mky" need
> > to follow their OWN rules.  Are these really = defined elsewhere or do
> > = you just use the standard rules recursively.
>
> will try to = clarify
>
> >
> > * Section 9.2 - Consider using a list structure for = the asterisk
> > leading = list in this section.
>
> Yep, this was = just a missed formatting problem
>
> >
> > * Section 10.1.1 - Encoding = Considerations - This could be 7 bit as
> > the value is base64 encoded for normal values and = would be UTF8 if you
> > = used the full JOSE signature structure which you do not.
>
> Ok, will look at changing this.
>
> >
> > * General - I was really = tired when I read through this and I kept
> > getting tripped up on prose.  I did not write = down all of the items
> > = which bothered me and now I have read it enough that it is harder for me = to
> locate = them.
> > However, I would = request that the authors perform some method of
> > detailed reading to check for this.  I = frequently read the text aloud
> > to myself for this purpose.  Alternatively, = you can just wait for the copy
> editors.
> = >
> > Jim
> >
> >
> = >

= --Apple-Mail=_3E073E7E-DB7E-43BC-90D7-A0D8DEADE447-- From nobody Fri Oct 14 10:36:17 2016 Return-Path: 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 9CB8E1293D8 for ; Fri, 14 Oct 2016 10:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 0TVx2Z5niCTc for ; Fri, 14 Oct 2016 10:36:13 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FA212987D for ; Fri, 14 Oct 2016 10:36:05 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9EHXOoF015167; Fri, 14 Oct 2016 13:36:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar-biz; bh=3BpzdWgaYoJt5TXrt98VNs1QQHRH57L6JQJiYrZ/oMI=; b=KRw0S7OUlmdc4aUTGU6G1x+tNLQAU7U7fcRPPN+V+V4FfIQHVtlpehI7xEvQJI3GrABo kN0Uk2EwVoNsngUpdm3aHwjDlIA+XR+Sd2DO8yp8jk+V0NDjgcrYakwbgai2X1Z/ePfB lSWV8Ft7a4/1xBOWiEyTTrzJxIr4YZdyFUyPdoBRJsonGC9BnJ90j+M6EvNgP4c9pFDe Rlb2CxSaf9GOF+b/qWkup9z/a5LJYQCjp++3xR3S7E2vxTbeHFGYg7iz6b2drBVLha5J 3OvCjoqDXhG8452dERm9UUyfWGROAjO7zQUio/aB8S8yNAhVQSfy0xnZDMFlIWklWGi0 YQ== Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 261qs36821-16 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Oct 2016 13:36:04 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.225]) with mapi id 14.03.0279.002; Fri, 14 Oct 2016 13:35:44 -0400 From: "Peterson, Jon" To: Alan Ford Thread-Topic: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt Thread-Index: AQHSH2DbTyBQGFRWDUSXYVpiyFA/m6Cmpt2AgABQEAD//8KKgIAAZW8AgAElGwA= Date: Fri, 14 Oct 2016 17:35:44 +0000 Message-ID: References: <24430040.96568.1475710389106.JavaMail.defaultUser@defaultHost> <18074C4B-7CD6-4E1A-98BF-085E65748AB3@gmail.com> <4C2B76C7-083E-4AD9-83BC-91EE93F251B4@gmail.com> In-Reply-To: <4C2B76C7-083E-4AD9-83BC-91EE93F251B4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.81] Content-Type: multipart/alternative; boundary="_000_D4267D641BE3A3jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-14_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610140313 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 17:36:15 -0000 --_000_D4267D641BE3A3jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I=92ve been coming at this from the wrong angle. I=92ve been assuming we wa= nt to stop (or at least, detect) modification of A. But in fact, what you= =92re saying is you want to permit modification _as long as it can be canon= icalised to the same thing_. Is that correct? Right, more or less. We can't prevent the modification of A whether we want= to or not - and detecting that something has been changed is only helpful = if you know that changing things is a problem - and for the kinds of change= s we observe in the wild, it usually isn't a problem. What we're trying to = resist in the design is the temptation to invent an A-prime with the delusi= onal assumption that it would be safe to give A-prime integrity protection,= because we intermediaries will modify A but spare A-prime. As long as ther= e are SBCs, we have to admit the possibility that anything in the message m= ight be modified. But yes, we want to permit A to be modified, and we do ju= st assume that the modifications performed will permit relying parties to c= anonicalize the eventual value of A to the same bit-exact string (the "real= " A) that the creator of the PASSporT canonicalized it to. In which case I get this - I think. However, the cases where this would be useful are surely limited. This requ= ires the verifier to know and understand modifications that could be applie= d along the path by non-STIR-aware entities. The verifier doesn't have to anticipate or understand the modifications per= formed by intermediaries, it just needs to be able to look at the end resul= t of those modifications and perform a canonicalization procedure. This is the basically the same discussion we were previously having on the = list about the value of canonicalization. I submit, anyway, that the sorts = of modifications that are practically applied by non-STIR-aware entities wi= ll still result in call signaling being routable, and that in those conditi= ons the canonicalization we've detailed will work. We can of course imagine= that entities will do weird things to telephone numbers that will make can= onicalization impossible, but in those cases calls probably won't route or = work well anyway. There was a chorus of voices on this list saying things t= o the effect that operators have dealt with this since time immemorial. I d= on't think there's a practical problem here. It'll work when it works, and = in cases where it doesn't work, identity shouldn't be verifiable. =93Full form=94, being base64 encoded, gets around a simple search/replace = here, which is probably an improvement. I don't think that would be material. If this would fix it, then we could h= ave used the original "canon" parameter and rot13'd it. The policies are th= e problem, not the encoding. Jon Peterson Neustar, Inc. Regards, Alan --_000_D4267D641BE3A3jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

I=92ve been coming at this from the wrong angle. I=92ve been assuming = we want to stop (or at least, detect) modification of A. But in fact, what = you=92re saying is you want to permit modification _as long as it can be canonicalised to the same thing_. I= s that correct?

Right, more or less. We can't prevent the modification of A whether we= want to or not - and detecting that something has been changed is only hel= pful if you know that changing things is a problem - and for the kinds of c= hanges we observe in the wild, it usually isn't a problem. What we're trying to resist in the design is the = temptation to invent an A-prime with the delusional assumption that it woul= d be safe to give A-prime integrity protection, because we intermediaries w= ill modify A but spare A-prime. As long as there are SBCs, we have to admit the possibility that anything = in the message might be modified. But yes, we want to permit A to be modifi= ed, and we do just assume that the modifications performed will permit rely= ing parties to canonicalize the eventual value of A to the same bit-exact string (the "real" A) = that the creator of the PASSporT canonicalized it to.

In which case I get this - I think.

However, the cases where this would be useful are surely limited. This= requires the verifier to know and understand modifications that could be a= pplied along the path by non-STIR-aware entities.

The verifier doesn't have to anticipate or understand the modification= s performed by intermediaries, it just needs to be able to look at the end = result of those modifications and perform a canonicalization procedure.

This is the basically the same discussion we were previously having on= the list about the value of canonicalization. I submit, anyway, that the s= orts of modifications that are practically applied by non-STIR-aware entiti= es will still result in call signaling being routable, and that in those conditions the canonicalization we've de= tailed will work. We can of course imagine that entities will do weird thin= gs to telephone numbers that will make canonicalization impossible, but in = those cases calls probably won't route or work well anyway. There was a chorus of voices on this list sayin= g things to the effect that operators have dealt with this since time immem= orial. I don't think there's a practical problem here. It'll work when it w= orks, and in cases where it doesn't work, identity shouldn't be verifiable. 

=93Full form=94, being base64 encoded, gets around a simple search/rep= lace here, which is probably an improvement.

I don't think that would be material. If this would fix it, then we co= uld have used the original "canon" parameter and rot13'd it. The = policies are the problem, not the encoding.

Jon Peterson
Neustar, Inc.


Regards,
Alan

 --_000_D4267D641BE3A3jonpetersonneustarbiz_-- From nobody Sat Oct 15 07:53:40 2016 Return-Path: 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 A64AD1294F1 for ; Sat, 15 Oct 2016 07:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 EU4EJE9r0ENn for ; Sat, 15 Oct 2016 07:53:37 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237C112940E for ; Sat, 15 Oct 2016 07:53:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8467E300A48 for ; Sat, 15 Oct 2016 10:53:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 59IhnhIAA5KZ for ; Sat, 15 Oct 2016 10:53:35 -0400 (EDT) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 5AF1130041B for ; Sat, 15 Oct 2016 10:53:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <67B01470-D522-4519-A1C2-CF22160DC5FF@vigilsec.com> Date: Sat, 15 Oct 2016 10:53:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67B01470-D522-4519-A1C2-CF22160DC5FF@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [stir] Consensus Call: Third WG Last Call for STIR WG Documents X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 14:53:39 -0000 The third WG Last Call on the three STIR WG Documents has completed. = These documents are: - https://www.ietf.org/id/draft-ietf-stir-rfc4474bis-13.txt - https://www.ietf.org/id/draft-ietf-stir-certificates-09.txt - https://www.ietf.org/id/draft-ietf-stir-passport-08.txt The WG has achieved consensus on all three documents. Points of improvement have been raised. For each of them, the document = authors have summarized how they will be handled. None of these changes = will require a fourth WG Last Call. As soon as the revised documents = are posted, the documents will be sent to the IESG for approval. The = requested publication status will be Proposed Standard. Thanks, Russ & Robert From nobody Tue Oct 18 10:05:23 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7931293F3; Tue, 18 Oct 2016 10:05:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147681031842.30742.7022363626499916656.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 10:05:18 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-rfc4474bis-14.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:05:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Authenticated Identity Management in the Session Initiation Protocol (SIP) Authors : Jon Peterson Cullen Jennings Eric Rescorla Chris Wendt Filename : draft-ietf-stir-rfc4474bis-14.txt Pages : 43 Date : 2016-10-18 Abstract: The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity, and for conveying a reference to the credentials of the signer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-rfc4474bis-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 18 10:07:34 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C63E126D73; Tue, 18 Oct 2016 10:07:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147681044800.30718.2341283996250020605.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 10:07:28 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-passport-09.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:07:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Personal Assertion Token (PASSporT) Authors : Chris Wendt Jon Peterson Filename : draft-ietf-stir-passport-09.txt Pages : 21 Date : 2016-10-18 Abstract: This document defines a method for creating and validating a token that cryptographically verifies an originating identity, or more generally a URI or telephone number representing the originator of personal communications. The PASSporT token is cryptographically signed to protect the integrity of the identity the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-passport-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 18 12:09:32 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB31412943B; Tue, 18 Oct 2016 12:09:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147681776769.30718.14691090128083859916.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 12:09:27 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-certificates-10.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 19:09:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Secure Telephone Identity Credentials: Certificates Authors : Jon Peterson Sean Turner Filename : draft-ietf-stir-certificates-10.txt Pages : 23 Date : 2016-10-18 Abstract: In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-certificates-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-certificates-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 18 14:28:00 2016 Return-Path: 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 65784129889 for ; Tue, 18 Oct 2016 14:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=WNOfNLzn; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Cp8QUxmw 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 SiBzoD5ZK-rT for ; Tue, 18 Oct 2016 14:27:58 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED506129865 for ; Tue, 18 Oct 2016 14:27:57 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 623A4206DC for ; Tue, 18 Oct 2016 17:27:57 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 18 Oct 2016 17:27:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=hDY J6fqhsHh51fjG2eAhj7I/YUw=; b=WNOfNLznaVT9JQYy2zfLkKH9f8bJpYOcPux FYFhhYQvV+VI/Q1jlP190qn6ii/iy6WVarQuy9YirBftei8tU3jWwt0Jy4vtKJR3 GxC9U9Gg1mKMyf5T5aScLdEZ4WmONcVayRSf4zBKCtmbGO7oTz2rgKr/vuS7zZ/N BpHDP2fk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=hDYJ6fqhsHh51fjG2eAhj7I/YUw=; b=Cp8QU xmwhkg8JglHSvMpwPihqRpWsc5hwv5UX02t5H4N3dp+CNP0ioOI2piTyfwt2O5Pr j2RaPDJPxHSiGLBSYok8w2O5+cmqtJv4e0Lmz+fyH6krNnmx/G43ht3VOqJGNMS/ gUzAXsUxNYSsKsI+81i8Y0LUP7w4sHlgZo57yE= X-Sasl-enc: ha4WPsqNg17Ya7JeRwsq/zteLq7g9IcefsOPpUe6W+bd 1476826076 Received: from [10.24.82.175] (unknown [128.107.241.185]) by mail.messagingengine.com (Postfix) with ESMTPA id C4E44CC081 for ; Tue, 18 Oct 2016 17:27:56 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <821D2CC3-4FCD-42B5-9D84-AEA9D7CD8943@cooperw.in> Date: Tue, 18 Oct 2016 17:27:55 -0400 To: IETF STIR Mail List Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [stir] AD evaluation: draft-ietf-stir-passport-09 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 21:27:59 -0000 I have re-reviewed this document in preparation for IETF LC. I believe = it is ready for LC and will issue the request for it shortly. Below are some suggested clarifications that should be incorporated or = otherwise addressed together with any last call comments. =3D Section 3 =3D OLD=20 PASSporT specifically uses this token format and defines claims that = convey the identity of the origination and destination of personal = communications. The originating identity, the primary value asserted in = a PASSporT object represents the identity of the calling party or the = initiator of a personal communications session. The signer of a = PASSporT object may or may not correspond to the origination identity. = For a given application's use or using protocol of PASSporT the creation = of the PASSporT object is performed by an entity that is authoritative = to assert the callers identity. This authority is represented by the = certificate credentials and the signature and PASSporT object is created = and initiated to the destination(s) at the applications choice of = authoritative point(s) in the network. For example, the PASSporT object = could be created at a device that has authenticated with a user, or at a = network entity with an authenticated trust relationship with that device = and it's user. Destination identities represent the intended = destination of the personal communications, i.e. the identity(s) being = called by the caller. The destination point(s) determined by the = application need to have the capability to verify the PASSporT token and = the digital signature. The PASSporT associated certificate is used to = validate the authority of the originating signer, generally via a = certificate chain to the trust anchor for that application. NEW=20 PASSporT specifically uses this token format and defines claims that = convey the identity of the origination and destination of personal = communications. The originating identity -- the primary value asserted = in a PASSporT object -- represents the identity of the calling party or = the initiator of a personal communications session. The signer of a = PASSporT object may or may not correspond to the origination identity. = For a given application's or protocol's use of PASSporT, the creation of = the PASSporT object is performed by an entity that is authoritative to = assert the caller's identity. This authority is represented by the = certificate credentials. The signature and PASSporT object are created = at the application's choice of authoritative point(s) in the network. For example, the PASSporT object could be created on a device to which a = user has authenticated, or at a network entity with an authenticated = trust relationship with that device and its user. Destination = identities represent the intended destination of the personal = communications, i.e. the identities being called by the caller. The = destination point(s) determined by the application need to have the = capability to verify the PASSporT token and the digital signature. The = PASSporT associated certificate is used to validate the authority of the = originating signer, generally via a certificate chain to the trust = anchor for that application. =3D Section 5.2.1 =3D s/The "dest" is a JSON object/The "dest" claim is a JSON object/ =3D Section 5.2.2 =3D OLD The "mky" claim value JSON array MUST contain JSON objects with exactly one of both corresponding "alg" and "dig" claim objects. The order of the JSON array should be in lexicographic order of the "alg" claims first followed by the corresponding lexicographic order of the "dig" claim values when there is repeated "alg" claims. NEW The "mky" claim value JSON array MUST contain JSON objects with exactly one of both corresponding "alg" and "dig" claim objects. The order of the JSON array should be in lexicographic order of the "alg" claims. If the array contains = multiple identical "alg" claims, those should be ordered in the = lexicographic order of their associated "dig" claims. =20 =3D Section 7 =3D =20 s/the Compact form/the compact form/ s/In order to construct the Compact form of the PASSporT string, the/In = order to construct the Compact form of the PASSporT string, follow the/ From nobody Tue Oct 18 14:29:15 2016 Return-Path: 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 CC1E3129890 for ; Tue, 18 Oct 2016 14:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=QlG4xQQn; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=sAh767yT 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 AL1_9SIrsnXz for ; Tue, 18 Oct 2016 14:29:07 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46BF129462 for ; Tue, 18 Oct 2016 14:29:07 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 16A2E20748 for ; Tue, 18 Oct 2016 17:29:07 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 18 Oct 2016 17:29:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=a0s TGS8NexdbcoAxC34+RW+K+tY=; b=QlG4xQQnNM6k5fZz4McUdduld+lnjaBr3FR xdoych0W+lMkcLuUIb9xW74N1e98O27mMquQJKUEkDM3F4pLZo6oFu2T41fG9dop JQj2bS/jUqmpPPyGfmd7jDHKdBv5SwAsDWJre6vWIVyT0cgGIJBkH95g50iM5gYt dPeEOAlE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=a0sTGS8NexdbcoAxC34+RW+K+tY=; b=sAh76 7yTC39DZsm+HEZbpoO1x78dXkvm/iV8zWK9+DpuQKshEsCCFqzdJyAq8PFnK92hV elJFCk4i3EjjiUb9gD12LVndU8eIb72gxES4gZLEyEmoh+5AvbxZuZU8YPQWfQLz aVIg1w9NSspcWEPMBX+5F/s7jmkxxSTP2Wzf/U= X-Sasl-enc: kMlNctQTTxs4pVlNkvi5JmvyiLFOOyCeB2CeMXCmyBfg 1476826146 Received: from [10.24.82.175] (unknown [128.107.241.185]) by mail.messagingengine.com (Postfix) with ESMTPA id 8D19FCC0BF for ; Tue, 18 Oct 2016 17:29:06 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1730662E-4462-4CF0-8788-5BCF99CE17B3@cooperw.in> Date: Tue, 18 Oct 2016 17:29:05 -0400 To: IETF STIR Mail List Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [stir] AD evaluation: draft-ietf-stir-certificates-10 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 21:29:12 -0000 I have re-reviewed this document in preparation for IETF LC. I believe = it is ready for LC and will issue the request for it shortly.= From nobody Tue Oct 18 14:30:04 2016 Return-Path: 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 6FC94129893 for ; Tue, 18 Oct 2016 14:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=tZZZIKKA; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=pTzqFDwp 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 8NlKeOiKLmKL for ; Tue, 18 Oct 2016 14:30:01 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B963512940F for ; Tue, 18 Oct 2016 14:30:01 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 255A120816 for ; Tue, 18 Oct 2016 17:30:01 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 18 Oct 2016 17:30:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=a0s TGS8NexdbcoAxC34+RW+K+tY=; b=tZZZIKKA/i84BodYHGKA4QFwpF2LG5FWu70 lGEIQtReyPQEJCOXuRTAg1WIY4Hn3DX6epnVa5kaLHUee07FUL34McY8xh8ST1vk N8P5zqb/NUIVMKutPWMrf87Zh6ra5JDe+QCPBAL+7Z2wBuF37MZGWAy+K4VPUmo2 CZwvma74= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=a0sTGS8NexdbcoAxC34+RW+K+tY=; b=pTzqF DwpsmR1/lIALpTIiOXhyw13mHENapNFTgTD7rmAGzadsgiOMKKbwub0VMaeohnGi 1mVcddTQQbcdBC7KfF6aJX1aR+kxr3fgjpOQmgx1urUqLilhD8P1Ktfjz9f3AHpc MYT5jjDSMBjhmLC5QrOXww7sh+Wtp9W6m2LS2s= X-Sasl-enc: ICh9VhcQ2RtchWPnWq+Zoh/zrYScT9jsN9nGPTJvBFld 1476826200 Received: from [10.24.82.175] (unknown [128.107.241.185]) by mail.messagingengine.com (Postfix) with ESMTPA id 94734CC07F for ; Tue, 18 Oct 2016 17:30:00 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 18 Oct 2016 17:30:00 -0400 To: IETF STIR Mail List Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [stir] AD evaluation: draft-ietf-stir-rfc4474bis-14 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 21:30:02 -0000 I have re-reviewed this document in preparation for IETF LC. I believe = it is ready for LC and will issue the request for it shortly.= From nobody Tue Oct 18 14:39:49 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE381298AF; Tue, 18 Oct 2016 14:39:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147682677973.30758.5840679865024488996.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 14:39:39 -0700 Archived-At: Cc: stir@ietf.org, stir-chairs@ietf.org, alissa@cooperw.in, draft-ietf-stir-certificates@ietf.org, rjsparks@nostrum.com Subject: [stir] Last Call: (Secure Telephone Identity Credentials: Certificates) to Proposed Standard X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 21:39:40 -0000 The IESG has received a request from the Secure Telephone Identity Revisited WG (stir) to consider the following document: - 'Secure Telephone Identity Credentials: Certificates' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-11-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains this normative downward references. See RFC 3967 for additional information: rfc7093: Additional Methods for Generating Key Identifiers Values (Informational - Independent Submission Editor stream) rfc3447: Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 (Informational - IETF stream) rfc5912: New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) (Informational - IETF stream) Note that rfc3447 and rfc5912 are already listed in the acceptable Downref Registry. From nobody Tue Oct 18 14:40:13 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F05951298BF; Tue, 18 Oct 2016 14:40:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147682681098.30847.5656352853931903322.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 14:40:10 -0700 Archived-At: Cc: stir@ietf.org, rjsparks@nostrum.com, alissa@cooperw.in, stir-chairs@ietf.org, draft-ietf-stir-passport@ietf.org Subject: [stir] Last Call: (Personal Assertion Token (PASSporT)) to Proposed Standard X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 21:40:11 -0000 The IESG has received a request from the Secure Telephone Identity Revisited WG (stir) to consider the following document: - 'Personal Assertion Token (PASSporT)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-11-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a method for creating and validating a token that cryptographically verifies an originating identity, or more generally a URI or telephone number representing the originator of personal communications. The PASSporT token is cryptographically signed to protect the integrity of the identity the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Oct 18 14:40:49 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCB61298BD; Tue, 18 Oct 2016 14:40:43 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147682684315.30831.8057409963464856616.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 14:40:43 -0700 Archived-At: Cc: stir@ietf.org, draft-ietf-stir-rfc4474bis@ietf.org, alissa@cooperw.in, stir-chairs@ietf.org, rjsparks@nostrum.com Subject: [stir] Last Call: (Authenticated Identity Management in the Session Initiation Protocol (SIP)) to Proposed Standard X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 21:40:43 -0000 The IESG has received a request from the Secure Telephone Identity Revisited WG (stir) to consider the following document: - 'Authenticated Identity Management in the Session Initiation Protocol (SIP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-11-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity, and for conveying a reference to the credentials of the signer. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2562/ From nobody Tue Oct 18 14:46:41 2016 Return-Path: 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 DDF83129492 for ; Tue, 18 Oct 2016 14:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 BzsvofZigGVJ for ; Tue, 18 Oct 2016 14:46:38 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9156B1295C5 for ; Tue, 18 Oct 2016 14:46:37 -0700 (PDT) Received: from hebrews (50.45.239.150) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Oct 2016 15:02:48 -0700 From: Jim Schaad To: Date: Tue, 18 Oct 2016 14:46:29 -0700 Message-ID: <058a01d22989$173a70d0$45af5270$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdIpfPi0KAWT0nA5Ty2Kj6HUFw9zZw== X-Originating-IP: [50.45.239.150] Archived-At: Cc: stir@ietf.org Subject: [stir] draft-ietf-stir-passport X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 21:46:39 -0000 First, it is a much improved spec to the last version. I had hoped that I would do better reading section 8.3 a second time around, however I seem to have failed. The section appears to have things which make no sense, and doesn't match the example. 1. claims may only be appended to the claims object specified. 2. cannot be removed or re-ordered 3. The example defines a new claim, "bar" which is placed correctly in lexigraphic order but does not match rule #1 above. Jim Grammar Issues: Section 5.1.1 - As defined the "iat" should be set to the date and time of issuance of the JWT and MUST the origination of the personal communications. Section 7 - For a using protocol of PASSporT Section 9 - JSON, as a canonical format - not sure that canonical is appropriate here From nobody Wed Oct 19 07:11:19 2016 Return-Path: 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 C11231294A6 for ; Wed, 19 Oct 2016 07:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no 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 kSa1zdIs7UzA for ; Wed, 19 Oct 2016 07:11:17 -0700 (PDT) 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 91AB012944C for ; Wed, 19 Oct 2016 07:11:17 -0700 (PDT) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9JEBGJa003298 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 19 Oct 2016 09:11:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: stir@ietf.org From: Robert Sparks Message-ID: Date: Wed, 19 Oct 2016 09:11:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] media type review thread for application/passport X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 14:11:19 -0000 Alexey has some comments on the application/passport media type registration. Please see https://mailarchive.ietf.org/arch/msg/media-types/DMikbQk4ignEhWJ-Li3agzrBXKQ RjS From nobody Wed Oct 19 13:41:05 2016 Return-Path: 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 30C2312955F for ; Wed, 19 Oct 2016 13:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no 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 Fv9bjK2vHp3R for ; Wed, 19 Oct 2016 13:41:00 -0700 (PDT) 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 96D24129513 for ; Wed, 19 Oct 2016 13:41:00 -0700 (PDT) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9JKex6X042768 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 19 Oct 2016 15:41:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: stir@ietf.org References: From: Robert Sparks Message-ID: <1fc4699b-cd0d-e205-0f91-ba9a9e471ab1@nostrum.com> Date: Wed, 19 Oct 2016 15:40:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [stir] media type review thread for application/passport X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 20:41:04 -0000 There are additional comments at https://mailarchive.ietf.org/arch/msg/media-types/E7ThBp1K9atsyQ2TgXM1lzRT7Uc On 10/19/16 9:11 AM, Robert Sparks wrote: > Alexey has some comments on the application/passport media type > registration. > > Please see > > https://mailarchive.ietf.org/arch/msg/media-types/DMikbQk4ignEhWJ-Li3agzrBXKQ > > > RjS > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Fri Oct 21 16:27:18 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3F312987C; Fri, 21 Oct 2016 16:21:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709208057.28214.16327554579714450871.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:20 -0700 Archived-At: Cc: stir@ietf.org, alissa@cooperw.in Subject: [stir] stir - Requested session has been scheduled for IETF 97 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:20 -0000 Dear Robert Sparks, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. stir Session 1 (1:30:00) Wednesday, Morning Session I 0930-1100 Room Name: Park Ballroom 2 size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Secure Telephone Identity Revisited Area Name: Applications and Real-Time Area Session Requester: Robert Sparks Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: lamps acme tls ecrit avtcore dane siprec p2psip rtcweb mmusic sipcore dispatch appsawg ice modern ipwave sipbrandy curdle Second Priority: perc slim netvc clue tcpinc cose uta ace saag oauth Special Requests: Monday/Tuesday if possible --------------------------------------------------------- From nobody Sun Oct 23 15:29:42 2016 Return-Path: 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 0FFD5129550; Sun, 23 Oct 2016 15:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 sjrcOJDbJ7QC; Sun, 23 Oct 2016 15:29:40 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A78DC129440; Sun, 23 Oct 2016 15:29:39 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 23 Oct 2016 15:45:41 -0700 From: Jim Schaad To: Date: Sun, 23 Oct 2016 15:29:24 -0700 Message-ID: <001701d22d7c$ea604ce0$bf20e6a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdIs4KYXR1xPIGuRTGKXlgWopYvZMg== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: stir@ietf.org Subject: [stir] draft-ietf-stir-passport X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 22:29:41 -0000 I have started looking at implementation of this and I have two suggestions for changes to the document which I think will make the code easier to implement. I think that, with one exception, this will generate exactly the same output for all of the current cases. Change #1 in section 5.2.2 I suggest that the text be modified to say that the algorithm is: 1. Take the a=fingerprint lines from the SIP header. 2. Sort the lines based on the UTF8 encoding of the strings 3. Encode the array in the order of the sorted lines. - Each element in the array is a map - Each map contains two elements constructed as follows .... I think that this will be the same as the current sorting order. Change #2 in section 9 The current text in JWK-Thumbprint does not cover the cases that you need. The JSON object MUST following the following rules. These rules are based on the thumbprint of a JSON Web Key (JWK) as defined in Section 3 of [RFC7638]. They cover some additional cases that [RFC7638] did not need to document. 1. The JSON object contains no whitespace or line breaks before or after any syntactic elements. 2. Map objects have the keys ordered lexicographically by the Unicode [UNICODE] code points of the member names. If two member names are equal, then the JSON serialization fails. 3. JSON value literals are lowercase 4. JSON numbers are to be encoded as integers unless the field is defined to be encoded otherwise. 5. Encoding rules are applied recursively to member values and array values. The rule on two key names is new, but is implicit as JWKs are not supposed to have two keys of the same name. Having a generic rule on maps means that one will not have a miss someplace if a new element is defined. Jim From nobody Thu Oct 27 14:06:56 2016 Return-Path: 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 0C285129863; Thu, 27 Oct 2016 14:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 ZrhyubedefCi; Thu, 27 Oct 2016 14:06:54 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0202A12985A; Thu, 27 Oct 2016 14:06:53 -0700 (PDT) Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Oct 2016 14:22:58 -0700 From: Jim Schaad To: Date: Thu, 27 Oct 2016 14:06:45 -0700 Message-ID: <010401d23096$07edac50$17c904f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdIwlaP4w+4g2huPRnCLI/ykNGKgeA== Content-Language: en-us X-Originating-IP: [173.8.216.38] Archived-At: Cc: stir@ietf.org Subject: [stir] draft-ietf-stir-rfc4474bis X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 21:06:55 -0000 I have not gotten around to doing a review of this document, which I was trying to do as part of the passport review. However, on a fast pass I did back then I did note the following error. In section 4, I think that signed-identity-digest is supposed to accommodate a PASSporT. However, the ABNF is incorrect. It should be signed-identity-digest = *(base64-char / ".") jim From nobody Fri Oct 28 09:08:14 2016 Return-Path: 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 1B64B12954D; Fri, 28 Oct 2016 09:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 U5kwxPkpUUN3; Fri, 28 Oct 2016 09:08:09 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D00512944A; Fri, 28 Oct 2016 09:08:09 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Oct 2016 09:24:14 -0700 From: Jim Schaad To: Date: Fri, 28 Oct 2016 09:07:58 -0700 Message-ID: <01c301d23135$769464b0$63bd2e10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdIwxjSmqsJMuGIpTVuD67Di5VZudA== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: stir@ietf.org Subject: [stir] review draft-ietf-stir-rfc4474bis-14 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 16:08:11 -0000 Section 3 - I am not sure that it is correct to say the following "an authentication service constructs tokens based on the PASSporT [I-D.ietf-stir-passport] format, a JSON [RFC7159] object" PASSporT is not producing a JSON object. More correct would be to say "an authentication service using PASSporT tokens, a value that uses JSON objects with values derived from ..." Section 4.1 - You have managed to miss a step in the procedure for "orig". Unless things are changed there is no way to populate a "tn" claim in an array, a JSON object is required as well. Section 4.1 - I believe that the procedures for doing "iat" are incorrect as this is a number not a quoted value. Section 4.1 - If the authentication service uses its own clock time, are there any requirements that either a compressed PASSporT not be used or the SIP date header be updated? Section 6.2.3 - This section leaves me unclear about what comparisons of the values in the passport are required to be compared against the values in the SIP header. It appears that checking the telephone numbers is only a MAY. Do the fields in the PASSporT become authoritive and you ignore the header fields? Jim From nobody Sat Oct 29 04:04:52 2016 Return-Path: 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 EC90D1295CC for ; Sat, 29 Oct 2016 04:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 G0Id0-2P_iDB for ; Sat, 29 Oct 2016 04:04:49 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 8A1E61295CA for ; Sat, 29 Oct 2016 04:04:49 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id 205so29052414ybz.3 for ; Sat, 29 Oct 2016 04:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=nzkW40+wexat/NFbZN/itCk26Btv43Tbc8M7ga6WNGc=; b=q6Y6eoGSGXrYWtDD8RaT+Wog8SJWNWWGD3Sw2Rkj7MlEiL71EqG1Z+tqiAB2jwj6n2 M5pZALmwj9Uy+zlgJLU714kXH+pWthis/RNvncBEf0rgs1OxegJ+97S3hOYMy72MPwOz kzJpVqGFjW4jZJ/OEHt5mLhENthCMb+MBmH700KK78uj3q/T6hLhLT0v0rz/M/HfYwA2 NZOFmyZjj9+nnThr4IWlGdDV2Q/9Z8cJjto5VD0zgeqjxh76d/BMo7bdsPy7ZUphZ8EQ PkD/POthPWar6U63dRhfRi7OO+EnbgkHhUiT5xYmIRYtR/53kcurAdO47qi6UjvmMCKj 8mIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nzkW40+wexat/NFbZN/itCk26Btv43Tbc8M7ga6WNGc=; b=L3ctsC3EUi/GJyaicRa8BSv2ZlVdRHFJF46GYfx69so0N3uB26pxDhjA90Gn+L98u/ RxSXvsXnlQBfNcHPj0KefbgoUU91Q2DEIm5fHkmajYnNY1IimKt0CZCc2TrxbRL4dpHs 4KuzYoI5wj90dBbASvz2UQ83BuJlm+1eVOIdIMBcuU+TgQRzRTw/RTi8OtJmVYNOJc0H GmYTucBsjWBOCFZ72xreL3GaO6X8emCkGua/72tv8zuVVCZ1yvVX1Ue9IUbG+p6cJhEQ 6qJkLP5y5DNxb3aKddiPNeUQ9/Yzcv0vcDsD5TiuCK9GjSdAuVo6tPw3UDYYhGGXEsZf eaHw== X-Gm-Message-State: ABUngvcmZsnr/2h+BEH42zl5KWNZfeQ8jXJfLlQJPODd1ej24vj4MiKUvs1bk+GDvYY92qZk3FjV7ZkaN3/tIg== X-Received: by 10.37.171.204 with SMTP id v70mr15026173ybi.80.1477739088583; Sat, 29 Oct 2016 04:04:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.82.210 with HTTP; Sat, 29 Oct 2016 04:04:08 -0700 (PDT) From: Eric Rescorla Date: Sat, 29 Oct 2016 22:04:08 +1100 Message-ID: To: "stir@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0921127263a5053ffef188 Archived-At: Subject: [stir] Comments on draft-ietf-stir-certificates-09 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 11:04:51 -0000 --94eb2c0921127263a5053ffef188 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OVERALL This sees like it's pretty sound, but there are several points that seem like they need some work. S 5.1. NIT: "A CAs" -> "A CA" S 6. The last graf on this kind of comes out of left field and seems like an operational issue. I can think of a lot of different ways you might disseminate keys, and I suspect that people almost never use signed PKCS#8 S 7. You need a better reference here for what it is people are being asked to implement in RFC 7030. It appears that you would want to require the ability to get the originator's certificates at the verifier, but requiring SCET for enrollment is not really what we want. Probably ACME is what we want. S 9. Why bother with the E164Number branch. You already have a range version, so you could just have range of one. You don't define the semantics of TelephoneNumberRange. This seems like it's potentially subtle. The natural design seems like you would interpret start as if it were an integer and then allow everything in the range [start, start + count ). However, aren't there edge cases here. Consider the field that contains: { +1.999.999.9999, 2 } // punctuation added for clarity. Clearly, +1.999.999.9999 is permitted, but are there any other numbers permitted? My algorithm above would include +2.000.000.0000, but that's clearly not right. Does it wrap so that it includes +1.000.000.0000? Seems like some text is required here. S 10. The tradeoff between short lived certificates and using status information is that the former=E2=80=99s burden is on the front end (i.e= ., enrollment) and the latter=E2=80=99s burden is on the back end (i.e., verification). Both impact call setup time, but it is assumed that generating a short-lived certificate for each call, and consequently performing enrollment for each call, is more of an impact than acquiring status information. This seems to confuse enrollment with certificate issuance. However, at least in protocols like ACME, that's not correct: you enroll once and then you can get as many certs issued as you want within a time window. It's not clear why this would be a bigger issue than OCSP, and there are obvious latency advantages because you can get a new cert at the start of dialing (i.e., before the destination number is known). You are also ignoring the possibility of OCSP stapling, which would seem to resolve both concerns. It seems like it would be good to specify this mode. S 10.2. The requirement to consult OCSP in real time results in a network round-trip time of day, Should this say "delay"? S 10.2.1. Am I supposed to be getting here that you are importing a bunch of the HVE requirements, but you don't want to directly refer to HVE because of the requirement to not use per-request extensions. Is that right? If so, maybe it would be better to normatively reference the spec and then override it. S 10.3. How does the mechanism described in this section interact with TN lists that are in the cert? Or do you only use it if you have the spid form? --94eb2c0921127263a5053ffef188 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OVERALL
This sees like it's pretty soun= d, but there are several points that
seem like they need some wor= k.

S 5.1.
NIT: "A CAs" -> &= quot;A CA"

S 6.
The last graf on th= is kind of comes out of left field and seems
like an operational = issue. I can think of a lot of different ways
you might dissemina= te keys, and I suspect that people almost
never use signed PKCS#8=

S 7.
You need a better reference here f= or what it is people are
being asked to implement in RFC 7030. It= appears that you would
want to require the ability to get the or= iginator's certificates
at the verifier, but requiring SCET f= or enrollment is not really what
we want. Probably ACME is what w= e want.

S 9.
Why bother with the E164Num= ber branch. You already have a range
version, so you could just h= ave range of one.=C2=A0

You don't define the s= emantics of TelephoneNumberRange. This seems
like it's potent= ially subtle. The natural design seems like you
would interpret s= tart as if it were an integer and then allow
everything in the ra= nge [start, start + count ). However, aren't
there edge cases= here. Consider the field that contains:

=C2=A0 { = +1.999.999.9999, 2 } =C2=A0// punctuation added for clarity.

=
Clearly, +1.999.999.9999 is permitted, but are there any other
numbers permitted? My algorithm above would include
+2.0= 00.000.0000, but that's clearly not right. Does it wrap
so th= at it includes +1.000.000.0000? Seems like some text
is required = here.


S 10.
=C2=A0 =C2=A0= The tradeoff between short lived certificates and using status
= =C2=A0 =C2=A0information is that the former=E2=80=99s burden is on the fron= t end (i.e.,
=C2=A0 =C2=A0enrollment) and the latter=E2=80=99s bu= rden is on the back end (i.e.,
=C2=A0 =C2=A0verification).=C2=A0 = Both impact call setup time, but it is assumed that
=C2=A0 =C2=A0= generating a short-lived certificate for each call, and consequently
<= div>=C2=A0 =C2=A0performing enrollment for each call, is more of an impact = than
=C2=A0 =C2=A0acquiring status information.

This seems to confuse enrollment with certificate issuance. However= ,
at least in protocols like ACME, that's not correct: you en= roll
once and then you can get as many certs issued as you want w= ithin
a time window. It's not clear why this would be a bigge= r issue
than OCSP, and there are obvious latency advantages becau= se you
can get a new cert at the start of dialing (i.e., before t= he
destination number is known).

You are= also ignoring the possibility of OCSP stapling, which
would seem= to resolve both concerns. It seems like it would
be good to spec= ify this mode.


S 10.2.
= =C2=A0 =C2=A0The requirement to consult OCSP in real time results in a netw= ork
=C2=A0 =C2=A0round-trip time of day,

Should this say "delay"?


S 10.2.1.
Am I supposed to be getting here that you are importin= g a bunch of
the HVE requirements, but you don't want to dire= ctly refer to HVE
because of the requirement to not use per-reque= st extensions. Is
that right? If so, maybe it would be better to = normatively reference
the spec and then override it.

S 10.3.
How does the mechanism descri= bed in this section interact with TN
lists that are in the cert? = Or do you only use it if you have the
spid form?

--94eb2c0921127263a5053ffef188-- From nobody Sat Oct 29 04:33:00 2016 Return-Path: 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 11F351294C3 for ; Sat, 29 Oct 2016 04:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Neh0KaGGPyh6 for ; Sat, 29 Oct 2016 04:32:57 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 5E43C1294C1 for ; Sat, 29 Oct 2016 04:32:57 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id r204so3047980ywb.0 for ; Sat, 29 Oct 2016 04:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=6MwMX7cxB7Ch0TsmiW86ojCYsOOX9mCe+HGZtodVJYc=; b=IC5ub3zeWrWYfjFYaf62uuV0G/yMVMUcvtKBVEKMYn5LB5mV0LEUnfpXRB9fBQiT5+ h+XJlu803bzTDgnTeQ/7XYlxeAFTRsgSVoWvw+p9IHW+8NrEF5DmC0zS5O3EDo2xJy5M pdWnmziGsYqptcFkQMdOTOM9vT23GxnSV+LHCpAXRVKiSAAXltaGXYO69AhcNdYxjNw/ kJA/fM7phLKBIYpSbPvUQtpgfJ7s0M15wy/BkTZGi6M02dpZZ7BjqueRVgLLc5va3061 zN+WWPafRCNgSFbaRYL+Yr+L2QaX4fQg0Kuhc+xgqAEwrY4f+O2EGZtMoG1T8FCbZKkS Pkyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6MwMX7cxB7Ch0TsmiW86ojCYsOOX9mCe+HGZtodVJYc=; b=HTKPiRQ+bJHGMOTr97Wuzet4Kv/HwQTY3rKaHomwLGynvoyPMT0w/qGnR2PAIQJHss /RPaWYTSKQww2IxvDbFwRNq189PEt+3v7i+8vztt3pfb9cAalPJodSGQdjAJgCDLOmkD NM7hwtoIvgW0/dvujAEaucUgIhZ/HsBjYdzIDTgyfVCGh35v3cgkQtFkamm5oP8kWsGK c3oYEYaEmjYDZMN4dRSvj+LYkgy+QXQm1OiSnBYX0HtMcQeD8zw6s1ytrtvYJaqzEPJg rb+6sq7jS6l3DGEJLkF2Wy1ihHxKoXX8scfCwaWqksZ7Hj3SJIEP4ei0HVLTj9FVA36/ flEw== X-Gm-Message-State: ABUngvcGLQu/JnSRTcPGkrFsP7lkEIMygXdPlqEFfOTkIC30zNbikgsJJMnot1LrI+SxbPguF5ZR+uFROFirPA== X-Received: by 10.129.53.194 with SMTP id c185mr9680014ywa.205.1477740776466; Sat, 29 Oct 2016 04:32:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.82.210 with HTTP; Sat, 29 Oct 2016 04:32:16 -0700 (PDT) From: Eric Rescorla Date: Sat, 29 Oct 2016 22:32:16 +1100 Message-ID: To: "stir@ietf.org" Content-Type: multipart/alternative; boundary=001a114214780d61a9053fff5605 Archived-At: Subject: [stir] Review of draft-ietf-stir-passport-09 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 11:32:59 -0000 --001a114214780d61a9053fff5605 Content-Type: text/plain; charset=UTF-8 OVERALL This document would be easier to read if it came with an example at the beginning (perhaps the one in 9.1). I've also been thinking about the use of a URL here. This has the result that it doesn't bind the certificate itself into the digital signature, but only the URL. So this implies that it's at least potentially possible to substitute one certificate for another with the same private key. Is that a concern here? S 4.3. Certificate chains are generally self-validating, so can you explain why you need HTTPS here? Clearly, it's good practice for confidentiality and to prevent other forms of attack, but still. S 5.2. { "dest":{ "tn":["12125551212"], "uri":["sip:alice@example.com", "sip:bob@example.net"] }, "iat":"1443208345", "orig":{"tn":"12155551212"} } This indentation seems weird. Should you be outdenting the "uri" line. S 5.2.2. Given the ambiguity about multiple fingerprints, you should probably cite the 4572-bis draft. S 7. The using protocol of the compact form of PASSporT MUST This "using protocol" language is pretty odd. Maybe define a specific term somewhere else? "application protocol"? S 9. JSON, as a canonical format, can include spaces and line breaks, and key value pairs can occur in any order. Doesn't this mean that JSON isn't canonical? S A.1, A.2 These aren't actually X.509 structure. Also, the private key in S 8.1 is in an OpenSSL-specific structure. Could you encode it in PKCS#8. --001a114214780d61a9053fff5605 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OVERALL
This document would be easier to re= ad if it came with an example
at the beginning (perhaps the one i= n 9.1).

I've also been thinking about the use = of a URL here. This has
the result that it doesn't bind the c= ertificate itself into the
digital signature, but only the URL. S= o this implies that it's
at least potentially possible to sub= stitute one certificate
for another with the same private key. Is= that a concern here?


S 4.3.
<= div>Certificate chains are generally self-validating, so can you explain
why you need HTTPS here? Clearly, it's good practice for confid= entiality
and to prevent other forms of attack, but still.
<= div>

S 5.2.
=C2=A0 =C2=A0{
=C2=A0 =C2=A0"dest":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "tn":["12125551212"],
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "uri":["sip:alice@example.com",
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "sip:bob@example.net"]
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "iat":"1443208345",
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 "orig":{"tn":"12155551212"}
=C2=A0 =C2=A0 =C2=A0 }

This indentation see= ms weird. Should you be outdenting the "uri" line.

=
S 5.2.2.
Given the ambiguity about multiple fingerprin= ts, you should probably
cite the 4572-bis draft.


S 7.
=C2=A0 =C2=A0 The using protocol of = the compact form of PASSporT MUST

This "using= protocol" language is pretty odd. Maybe define a specific
t= erm somewhere else? "application protocol"?

<= div>S 9.
=C2=A0 =C2=A0JSON, as a canonical format, can include sp= aces and line breaks, and
=C2=A0 =C2=A0key value pairs can occur = in any order.

Doesn't this mean that JSON isn&= #39;t canonical?


S A.1, A.2

These aren't actually X.509 structure. Also, the priv= ate key in S 8.1
is in an OpenSSL-specific structure. Could you e= ncode it in PKCS#8.

--001a114214780d61a9053fff5605-- From nobody Sun Oct 30 14:03:59 2016 Return-Path: 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 51432129480 for ; Sun, 30 Oct 2016 14:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, TRACKER_ID=1.306] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 fDYL_Itb9fzi for ; Sun, 30 Oct 2016 14:03:56 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 8A3AD129428 for ; Sun, 30 Oct 2016 14:03:56 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id v138so52289866qka.0 for ; Sun, 30 Oct 2016 14:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kC8SQSYfEi6hi8DsOIRPGDeE0gmav/opyc6VBMtlsio=; b=YTX0ksgObPABKqaRBuANkrlfJSvdq+1ioz26oLGYqO9PFJrwJ16IXCqTHwhEuR5Of0 zPKg6hSFKc97txFWEnn8J8mXuG4CtsTglGg3uZTdXUDAbBwWVLLSzo03mbV0FELfveCx 1YHGWk1k3GRAzrvuDIrnB2gJH1IIvwP52PNjUuqDTnyd4TrAX7riz5icyIlj3O33TOKO Kt7H1t2DPH009lkHfQd+AOOqevySGatEzgE3Uch6D8iibyUBD7P0Gw6r5hWRqF5GkZMX L5Iqk36TMI6j92vwpHdRq3v8jknL1OPd1KLrLhz2DM24FjPHjESte3rA0waFyfaG9L2m mnRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kC8SQSYfEi6hi8DsOIRPGDeE0gmav/opyc6VBMtlsio=; b=R3X6BBmKlrDdZeN9BovQHYrcAIH+QNrQU8ACDQ0rmec0ebFK81BlOFmoKR6HXu40q+ hAFBuptf4iPGNLLb4T+Ov+dtOQftseTSKSyEf2v9cLoMW6gk0qRFau2l4aSJiHHF+Efj ZQ1upM8W8trNl1GKggIPHG5ThWEt2e1kq0ZUa+nPVoz6N182LxNf5bECX6iiikOK2Jgq b08Oz4lMZpMjylZ8e9s3xpztfcLPGAkXQAS/nnDFuAGSGT4fOq0OIlcDl/jefLbSBt82 33Ca/xBSN+42kGNyvv5vV5q1C3fSoMFiDr3yK3n3kcpv4r8aB/WXFM9ZL/vTr9H2l/a3 iruA== X-Gm-Message-State: ABUngvd1KArbViOnIN166Jgp+mf/GV0nV1mWXDKDtxJXEgV5Y8h99HWD5sZkmFtbQWq1Qw== X-Received: by 10.55.8.20 with SMTP id 20mr23497767qki.3.1477861435441; Sun, 30 Oct 2016 14:03:55 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:9cc8:a44f:1541:fc0d? ([2601:41:c101:9364:9cc8:a44f:1541:fc0d]) by smtp.gmail.com with ESMTPSA id 96sm7897333qkz.40.2016.10.30.14.03.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Oct 2016 14:03:54 -0700 (PDT) From: Chris Wendt Message-Id: <6DBDA70B-586B-4383-853F-34675DC8BF2D@chriswendt.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_4F7D53DD-9B7D-4DD2-8288-03B5E724083B" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Sun, 30 Oct 2016 17:03:53 -0400 In-Reply-To: To: Eric Rescorla References: X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Review of draft-ietf-stir-passport-09 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 21:03:59 -0000 --Apple-Mail=_4F7D53DD-9B7D-4DD2-8288-03B5E724083B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, Thanks. Answers inline. -Chris > On Oct 29, 2016, at 7:32 AM, Eric Rescorla wrote: >=20 > OVERALL > This document would be easier to read if it came with an example > at the beginning (perhaps the one in 9.1). >=20 > I've also been thinking about the use of a URL here. This has > the result that it doesn't bind the certificate itself into the > digital signature, but only the URL. So this implies that it's > at least potentially possible to substitute one certificate > for another with the same private key. Is that a concern here? Other than stolen private key scenarios, which are a concern whether you = use URL or not, I=E2=80=99m not sure of a reason why someone would want = to do this for legitimate reasons and there would be any concern for = multiple certificates being able to validate a call, or whether someone = with legitimate access to the private key and would want to use this = technique illegitimately would be a valid scenario unless they are a bad = actor in the first place. >=20 >=20 > S 4.3. > Certificate chains are generally self-validating, so can you explain > why you need HTTPS here? Clearly, it's good practice for = confidentiality > and to prevent other forms of attack, but still. https://tools.ietf.org/html/rfc7515#section-4.1.5 = does call for it. I = could certainly remove the direct reference to this fact and leave it to = the generic reference to RFC7515. It also technically calls for server = identity validation using RFC6125 as well. >=20 >=20 > S 5.2. > { > "dest":{ > "tn":["12125551212"], > "uri":["sip:alice@example.com = ", > "sip:bob@example.net = "] > }, > "iat":"1443208345", > "orig":{"tn":"12155551212"} > } >=20 > This indentation seems weird. Should you be outdenting the "uri" line. Simple format problem, fixed. >=20 > S 5.2.2. > Given the ambiguity about multiple fingerprints, you should probably > cite the 4572-bis draft. Added. >=20 >=20 > S 7. > The using protocol of the compact form of PASSporT MUST >=20 > This "using protocol" language is pretty odd. Maybe define a specific > term somewhere else? "application protocol"? >=20 The =E2=80=9Cusing protocol=E2=80=9D was a suggestion from JP, so i=E2=80=99= ll let him answer that. > S 9. > JSON, as a canonical format, can include spaces and line breaks, = and > key value pairs can occur in any order. >=20 > Doesn't this mean that JSON isn't canonical? good point :) fixed. >=20 >=20 > S A.1, A.2 >=20 > These aren't actually X.509 structure. Also, the private key in S 8.1 > is in an OpenSSL-specific structure. Could you encode it in PKCS#8. Ok so I=E2=80=99ll do this: openssl pkcs8 -topk8 -nocrypt -in key.pem -out p8file.pem -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh -----END PRIVATE KEY=E2=80=94=E2=80=94 Correct? >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_4F7D53DD-9B7D-4DD2-8288-03B5E724083B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Eric,

Thanks.  Answers inline.

-Chris

On = Oct 29, 2016, at 7:32 AM, Eric Rescorla <ekr@rtfm.com> = wrote:

OVERALL
This = document would be easier to read if it came with an example
at the beginning (perhaps the one in 9.1).

I've also been thinking = about the use of a URL here. This has
the result = that it doesn't bind the certificate itself into the
digital signature, but only the URL. So this implies that = it's
at least potentially possible to substitute = one certificate
for another with the same private = key. Is that a concern here?

Other than stolen private key scenarios, which are = a concern whether you use URL or not, I=E2=80=99m not sure of a reason = why someone would want to do this for legitimate reasons and there would = be any concern for multiple certificates being able to validate a call, = or whether someone with legitimate access to the private key and would = want to use this technique illegitimately would be a valid scenario = unless they are a bad actor in the first place.



S 4.3.
Certificate chains are generally self-validating, so can you = explain
why you need HTTPS here? Clearly, it's good = practice for confidentiality
and to prevent other = forms of attack, but still.

https://tools.ietf.org/html/rfc7515#section-4.1.5 does= call for it.  I could certainly remove the direct reference to = this fact and leave it to the generic reference to RFC7515.  It = also technically calls for server identity validation using RFC6125 as = well.




S 5.2.
   {
   "dest":{
    =       "tn":["12125551212"],
  =             "uri":["sip:alice@example.com",
  =                 "sip:bob@example.net"]
    =       },
        =   "iat":"1443208345",
      =     "orig":{"tn":"12155551212"}
  =     }

This indentation seems weird. Should you be outdenting the = "uri" line.

Simple format problem, fixed.


S 5.2.2.
Given the ambiguity about = multiple fingerprints, you should probably
cite the = 4572-bis draft.

Added.



S 7.
    The using protocol of = the compact form of PASSporT MUST

This "using protocol" language is = pretty odd. Maybe define a specific
term somewhere = else? "application protocol"?


The =E2=80=9Cusing protocol=E2=80=9D was a = suggestion from JP, so i=E2=80=99ll let him answer that.

S 9.
  =  JSON, as a canonical format, can include spaces and line breaks, = and
   key value pairs can occur in any = order.

Doesn't = this mean that JSON isn't = canonical?

good point :) fixed.



S A.1, A.2

These aren't actually X.509 structure. Also, the private key = in S 8.1
is in an OpenSSL-specific structure. Could = you encode it in PKCS#8.

Ok so I=E2=80=99ll do this:

openssl pkcs8 -topk8 -nocrypt -in key.pem -out = p8file.pem

-----BEGIN PRIVATE = KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZv= N9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9K= A8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9= vuh
-----END PRIVATE KEY=E2=80=94=E2=80=94

Correct?



_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_4F7D53DD-9B7D-4DD2-8288-03B5E724083B-- From nobody Sun Oct 30 14:59:18 2016 Return-Path: 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 7B253129485 for ; Sun, 30 Oct 2016 14:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.593 X-Spam-Level: X-Spam-Status: No, score=-0.593 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, TRACKER_ID=1.306] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 CwTRfsN-PMcf for ; Sun, 30 Oct 2016 14:59:15 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (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 AE07F1293FE for ; Sun, 30 Oct 2016 14:59:15 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id g68so53146710ybi.0 for ; Sun, 30 Oct 2016 14:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qs9pqjLuoW02lHN6Y1SDPFgPtL7PqwSHOa51L8UGgQc=; b=NS1bTIKsT0yT5KUUSwZOaGSCi1VXhuy8BbKtPWGOhkd+EBU4wLAGw5+2F1rbD5wSYu lPVe1URDCwCfmF+010azOuZEfj2psEBHamMbpI0kU9NinATpAlPJMtJi9uKVnuctxUQ0 xiO/fXhZXmwHt3VuzpeeB3z57I6r1cAnh7GnAcHvj059jWBjGdaNgl7JcOg0HrGuKZzc utA++MWvj8dYXtTCVQsRVLAp8k8ktHU3SChJJXMErZENnGUXK9so0Nx4VWGGr38Wiv3m 0wh8BjnswZ8eA8mDBOB+pj5W88c5QHjGDQwPUPm/KX272p3VkrvbsnblP5M1IkjuKl1l FV5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qs9pqjLuoW02lHN6Y1SDPFgPtL7PqwSHOa51L8UGgQc=; b=BwvMWMcAejjL4+6QtI6/BGfSW38knwSnfGfenNf0vHw4cvdCE1xpHyeXlKi5Fdfnts m6gad8LCmGnfKLpn1EHvNyXwvtB5C4Zf/62PRVV+WIiQEZZ3NFpptG7Z2xTqcTbIgAJx wYLpkdlXMsgaPD3WB2eNoca75vqlzARijkiyQ6+xfYglMnbV6Nvp9HW/dOkumZ3KJ1cb ijugzqH0BT0b31G4Igvaj3oppCaxS45YVAVGFefDIKZn3709aFYPDO47o40nnh05BS+C 2J++WJ1HnxILmdbk2VhITT6oKBL8Y4Bnk7kKDT98s8XRlNtVV2NuBp4onPRx822xmGVg /YPw== X-Gm-Message-State: ABUngve0AnHxn19rZBU3AZ1vPcGQPiNNWN0MUe/sjdEzH1dCqPJbpe1PqCmRWYPoNYh538MqnTMO1Uerdw+5kA== X-Received: by 10.37.246.9 with SMTP id t9mr5983656ybd.107.1477864754907; Sun, 30 Oct 2016 14:59:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.82.210 with HTTP; Sun, 30 Oct 2016 14:58:34 -0700 (PDT) In-Reply-To: <6DBDA70B-586B-4383-853F-34675DC8BF2D@chriswendt.net> References: <6DBDA70B-586B-4383-853F-34675DC8BF2D@chriswendt.net> From: Eric Rescorla Date: Sun, 30 Oct 2016 14:58:34 -0700 Message-ID: To: Chris Wendt Content-Type: multipart/alternative; boundary=f403045db074be45cc05401c33c5 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Review of draft-ietf-stir-passport-09 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 21:59:17 -0000 --f403045db074be45cc05401c33c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Oct 30, 2016 at 2:03 PM, Chris Wendt wrote: > Hi Eric, > > Thanks. Answers inline. > > -Chris > > On Oct 29, 2016, at 7:32 AM, Eric Rescorla wrote: > > OVERALL > This document would be easier to read if it came with an example > at the beginning (perhaps the one in 9.1). > > I've also been thinking about the use of a URL here. This has > the result that it doesn't bind the certificate itself into the > digital signature, but only the URL. So this implies that it's > at least potentially possible to substitute one certificate > for another with the same private key. Is that a concern here? > > > Other than stolen private key scenarios, which are a concern whether you > use URL or not, I=E2=80=99m not sure of a reason why someone would want t= o do this > for legitimate reasons and there would be any concern for multiple > certificates being able to validate a call, or whether someone with > legitimate access to the private key and would want to use this technique > illegitimately would be a valid scenario unless they are a bad actor in t= he > first place. > Sorry for not being clear: my concern is that this might be used as an attack. I don't immediately have one to hand, but.... -Ekr S 4.3. > Certificate chains are generally self-validating, so can you explain > why you need HTTPS here? Clearly, it's good practice for confidentiality > and to prevent other forms of attack, but still. > > > https://tools.ietf.org/html/rfc7515#section-4.1.5 does call for it. I > could certainly remove the direct reference to this fact and leave it to > the generic reference to RFC7515. It also technically calls for server > identity validation using RFC6125 as well. > > > > > S 5.2. > { > "dest":{ > "tn":["12125551212"], > "uri":["sip:alice@example.com", > "sip:bob@example.net"] > }, > "iat":"1443208345", > "orig":{"tn":"12155551212"} > } > > This indentation seems weird. Should you be outdenting the "uri" line. > > > Simple format problem, fixed. > > > S 5.2.2. > Given the ambiguity about multiple fingerprints, you should probably > cite the 4572-bis draft. > > > Added. > > > > S 7. > The using protocol of the compact form of PASSporT MUST > > This "using protocol" language is pretty odd. Maybe define a specific > term somewhere else? "application protocol"? > > > The =E2=80=9Cusing protocol=E2=80=9D was a suggestion from JP, so i=E2=80= =99ll let him answer that. > > S 9. > JSON, as a canonical format, can include spaces and line breaks, and > key value pairs can occur in any order. > > Doesn't this mean that JSON isn't canonical? > > > good point :) fixed. > > > > S A.1, A.2 > > These aren't actually X.509 structure. Also, the private key in S 8.1 > is in an OpenSSL-specific structure. Could you encode it in PKCS#8. > > > Ok so I=E2=80=99ll do this: > > openssl pkcs8 -topk8 -nocrypt -in key.pem -out p8file.pem > > -----BEGIN PRIVATE KEY----- > MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy > qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW > ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh > -----END PRIVATE KEY=E2=80=94=E2=80=94 > > Correct? > That looks like it should be right. -Ekr > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > > --f403045db074be45cc05401c33c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Oct 30, 2016 at 2:03 PM, Chris Wendt <chris-ietf@chris= wendt.net> wrote:
Hi Eric,

Thanks.=C2=A0 Answe= rs inline.

-Chris

On Oct 29, 2016, at 7:32 AM, Eric Resc= orla <ekr@rtfm.com= > wrote:

OVERALL
This document would be eas= ier to read if it came with an example
at the beginning (perhaps = the one in 9.1).

I've also been thinking about= the use of a URL here. This has
the result that it doesn't b= ind the certificate itself into the
digital signature, but only t= he URL. So this implies that it's
at least potentially possib= le to substitute one certificate
for another with the same privat= e key. Is that a concern here?

Other than stolen private key scenarios, which are a concern w= hether you use URL or not, I=E2=80=99m not sure of a reason why someone wou= ld want to do this for legitimate reasons and there would be any concern fo= r multiple certificates being able to validate a call, or whether someone w= ith legitimate access to the private key and would want to use this techniq= ue illegitimately would be a valid scenario unless they are a bad actor in = the first place.

So= rry for not being clear: my concern is that this might be used as an attack= . I don't immediately have one to hand, but....

-Ekr



S 4.3.
Cer= tificate chains are generally self-validating, so can you explain
why you need HTTPS here? Clearly, it's good practice for confidentiali= ty
and to prevent other forms of attack, but still.

https://tools.ietf.org/htm= l/rfc7515#section-4.1.5=C2=A0does call for it.=C2=A0 I could certa= inly remove the direct reference to this fact and leave it to the generic r= eference to RFC7515.=C2=A0 It also technically calls for server identity va= lidation using RFC6125 as well.




S 5.2.
=C2=A0 =C2=A0{
=C2=A0 =C2=A0"dest&quo= t;:{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "tn":["121255512= 12"],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &= quot;uri":["sip:alice@example.com",
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "sip:bob@example.net"]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "iat":"1443208345",
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 "orig":{"tn":"12155551212"= }
=C2=A0 =C2=A0 =C2=A0 }

This indentatio= n seems weird. Should you be outdenting the "uri" line.

Simple format problem, fixe= d.


S 5.2.2.
Given the ambiguity about multiple= fingerprints, you should probably
cite the 4572-bis draft.
=

Added.



S 7.
=C2=A0 =C2=A0 The using protocol of the co= mpact form of PASSporT MUST

This "using proto= col" language is pretty odd. Maybe define a specific
term so= mewhere else? "application protocol"?

<= /div>

The =E2=80=9Cusing protocol=E2= =80=9D was a suggestion from JP, so i=E2=80=99ll let him answer that.
=
S= 9.
=C2=A0 =C2=A0JSON, as a canonical format, can include spaces = and line breaks, and
=C2=A0 =C2=A0key value pairs can occur in an= y order.

Doesn't this mean that JSON isn't= canonical?

good p= oint :) fixed.



S A.1, A.2

<= /div>
These aren't actually X.509 structure. Also, the private key = in S 8.1
is in an OpenSSL-specific structure. Could you encode it= in PKCS#8.

Ok so = I=E2=80=99ll do this:

openssl pkcs8 -topk8 -nocryp= t -in key.pem -out p8file.pem

-----BEGIN PRIV= ATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQ= gi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWf= aj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----END PRIVATE KEY=E2=80=94=E2=80= =94

Correct?

That looks like it should be right.

=
-Ekr
=C2=A0



_______________________________________________
stir mailing liststir@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/stir" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/stir


--f403045db074be45cc05401c33c5-- From nobody Mon Oct 31 05:22:07 2016 Return-Path: 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 A5FA1129518 for ; Mon, 31 Oct 2016 05:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 lfEOiu8A83gg for ; Mon, 31 Oct 2016 05:22:02 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 485F61294CA for ; Mon, 31 Oct 2016 05:22:02 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id q130so39012941qke.1 for ; Mon, 31 Oct 2016 05:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MqViu/8CIUhFONWTdf4zcAqTT02QFUog14EpbRrK0Cc=; b=QS87A8F3EHltf8EDMu3sjgWpOpUih28wWYS+Yllp7IbK+swX9Dlbd9rGku7jePKm+M DdUPb7cqAJtL/Icg4ev29hEPryZBbT0C7MdQq81hWcCbD5LRZYwobj2ibOFaAIlnqZqu BzlylIkKCZwzN7zlX4E/yIRageyLJqiaTk7AfRWdHYlu57ePx77QuBYYqhF8Ct0Vfrxs ZLukTdj4U81jWPhfQSlvCUWc5slXWQ580tclUOqoqc0qOqKT6+OsoYnSbvakO23v8nvv UJGyLQwDF97X0xIRrGzQ/WBC6uVXyH2NOoCvqopoGPsf+IzivKh+XwYsd9UQKqNwlz6d /VNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MqViu/8CIUhFONWTdf4zcAqTT02QFUog14EpbRrK0Cc=; b=YfMyEMNHXZJUVphq6vsCc2QtV2WUZv/lHA83Z6NPgOYuUSiFk1/Au7aE/oBdaK4/wB JG9dXeQ/ziyTQ2jpS1SA9yU6C2aBrjJ8PoX7f37EyOjV0D+xijL8cjoVlDfLWBf9cxG8 7INQKVrnGZTjy7ku4TRX3xXtvBkJKhHOQIUWDuHEpUccuRS7AO4B3Pavr8X+KoRJ2XUD EI9dejviSz8DavyCLK9FRRU+OijVfcu4VADRLmu2ePuzeYOkb2Cs/8s1S5G3aTAxLg9G e5AQ8WKwQklh4HkwNsEvWV17HdxCHoTiCYCJ8F3VJlFjq8TAmDDQsv5jZoxQtHopSidd yBdg== X-Gm-Message-State: ABUngvfYmCMpgLaeAi0//LajRnEB7OXthxx69Vm3bgnBhCRfox6YNjrD0U6DlJBx5J6K5Q== X-Received: by 10.55.78.70 with SMTP id c67mr14613740qkb.270.1477916521346; Mon, 31 Oct 2016 05:22:01 -0700 (PDT) Received: from ?IPv6:2601:a40:100:d3:39bb:f74d:cd2c:e52e? ([2601:a40:100:d3:39bb:f74d:cd2c:e52e]) by smtp.gmail.com with ESMTPSA id 126sm13128893qkl.12.2016.10.31.05.21.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 05:22:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Chris Wendt In-Reply-To: <001701d22d7c$ea604ce0$bf20e6a0$@augustcellars.com> Date: Mon, 31 Oct 2016 08:21:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <406B44A2-6BA2-4D31-84EB-405F961407A8@chriswendt.net> References: <001701d22d7c$ea604ce0$bf20e6a0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3251) Archived-At: Cc: stir@ietf.org, draft-ietf-stir-passport@ietf.org Subject: Re: [stir] draft-ietf-stir-passport X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 12:22:05 -0000 Hi Jim, Inline. > On Oct 23, 2016, at 6:29 PM, Jim Schaad = wrote: >=20 > I have started looking at implementation of this and I have two = suggestions > for changes to the document which I think will make the code easier to > implement. I think that, with one exception, this will generate = exactly the > same output for all of the current cases. >=20 > Change #1 in section 5.2.2 >=20 > I suggest that the text be modified to say that the algorithm is: >=20 > 1. Take the a=3Dfingerprint lines from the SIP header. > 2. Sort the lines based on the UTF8 encoding of the strings > 3. Encode the array in the order of the sorted lines. > - Each element in the array is a map > - Each map contains two elements constructed as follows .... >=20 > I think that this will be the same as the current sorting order. Agree could be a little clearer. I did variation on a theme: >> The "mky" claim is a JSON object with a claim name of "mky" and a claim value of a JSON array denoted by brackets. The "mky" claim value JSON array MUST be constructed as follows: 1. Take each "a=3Dfingerprint" lines carried in the SDP. 2. Sort the lines based on the UTF8 encoding of the concatenation of the "alg" and "dig" claim value strings. 3. Encode the array in the order of the sorted lines, where each "mky" array element is a JSON object with two elements corresponding to the "alg" and "dig" objects, with "alg" first and "dig" second. >> >=20 >=20 > Change #2 in section 9 >=20 > The current text in JWK-Thumbprint does not cover the cases that you = need. >=20 > The JSON object MUST following the following rules. These rules are = based > on the thumbprint of a JSON Web Key (JWK) as defined in Section 3 of > [RFC7638]. They cover some additional cases that [RFC7638] did not = need to > document. >=20 > 1. The JSON object contains no whitespace or line breaks before or = after any > syntactic elements. > 2. Map objects have the keys ordered lexicographically by the Unicode > [UNICODE] code points of the member names. If two member names are = equal, > then the JSON serialization fails. > 3. JSON value literals are lowercase > 4. JSON numbers are to be encoded as integers unless the field is = defined to > be encoded otherwise. > 5. Encoding rules are applied recursively to member values and array = values. >=20 > The rule on two key names is new, but is implicit as JWKs are not = supposed > to have two keys of the same name. Having a generic rule on maps = means that > one will not have a miss someplace if a new element is defined. New Text: >> The JSON object MUST follow the following rules. These rules are based on the thumbprint of a JSON Web Key (JWK) as defined in Section 3 Step 1 = of {{RFC7638}}. =20 1. The JSON object MUST contain no whitespace or line breaks before or = after any syntactic elements. 2. JSON objects MUST have the keys ordered lexicographically by the = Unicode {{UNICODE}} code points of the member names. =20 3. JSON value literals MUST be lowercase. 4. JSON numbers are to be encoded as integers unless the field is = defined to be encoded otherwise. 5. Encoding rules MUST be applied recursively to member values and array = values. Note: For any PASSporT extension claims, member names within the scope = of a JSON object MUST NOT be equal to other member names, otherwise = serialization will not be deterministic. >> >=20 > Jim >=20 >=20 >=20 From nobody Mon Oct 31 09:22:46 2016 Return-Path: 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 5DCB512985C; Mon, 31 Oct 2016 09:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 P-FRnPYVzIUv; Mon, 31 Oct 2016 09:22:43 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F739129873; Mon, 31 Oct 2016 09:22:41 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 31 Oct 2016 09:38:39 -0700 From: Jim Schaad To: 'Chris Wendt' References: <001701d22d7c$ea604ce0$bf20e6a0$@augustcellars.com> <406B44A2-6BA2-4D31-84EB-405F961407A8@chriswendt.net> In-Reply-To: <406B44A2-6BA2-4D31-84EB-405F961407A8@chriswendt.net> Date: Mon, 31 Oct 2016 09:22:27 -0700 Message-ID: <042201d23392$fa18d960$ee4a8c20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFOfmeddTlv/UfcEf0IWttmvFVsYAIC269FoboSPnA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: stir@ietf.org, draft-ietf-stir-passport@ietf.org Subject: Re: [stir] draft-ietf-stir-passport X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 16:22:45 -0000 Looks good to me > -----Original Message----- > From: Chris Wendt [mailto:chris-ietf@chriswendt.net] > Sent: Monday, October 31, 2016 5:22 AM > To: Jim Schaad > Cc: draft-ietf-stir-passport@ietf.org; stir@ietf.org > Subject: Re: draft-ietf-stir-passport > > Hi Jim, > > Inline. > > > On Oct 23, 2016, at 6:29 PM, Jim Schaad wrote: > > > > I have started looking at implementation of this and I have two > > suggestions for changes to the document which I think will make the > > code easier to implement. I think that, with one exception, this will > > generate exactly the same output for all of the current cases. > > > > Change #1 in section 5.2.2 > > > > I suggest that the text be modified to say that the algorithm is: > > > > 1. Take the a=fingerprint lines from the SIP header. > > 2. Sort the lines based on the UTF8 encoding of the strings 3. Encode > > the array in the order of the sorted lines. > > - Each element in the array is a map > > - Each map contains two elements constructed as follows .... > > > > I think that this will be the same as the current sorting order. > > Agree could be a little clearer. > > I did variation on a theme: > > >> > The "mky" claim is a JSON object with a claim name of "mky" and a > claim value of a JSON array denoted by brackets. The "mky" claim > value JSON array MUST be constructed as follows: > > 1. Take each "a=fingerprint" lines carried in the SDP. > > 2. Sort the lines based on the UTF8 encoding of the concatenation of > the "alg" and "dig" claim value strings. > > 3. Encode the array in the order of the sorted lines, where each > "mky" array element is a JSON object with two elements > corresponding to the "alg" and "dig" objects, with "alg" first > and "dig" second. > >> > > > > > > > Change #2 in section 9 > > > > The current text in JWK-Thumbprint does not cover the cases that you need. > > > > The JSON object MUST following the following rules. These rules are > > based on the thumbprint of a JSON Web Key (JWK) as defined in Section > > 3 of [RFC7638]. They cover some additional cases that [RFC7638] did > > not need to document. > > > > 1. The JSON object contains no whitespace or line breaks before or > > after any syntactic elements. > > 2. Map objects have the keys ordered lexicographically by the Unicode > > [UNICODE] code points of the member names. If two member names are > > equal, then the JSON serialization fails. > > 3. JSON value literals are lowercase > > 4. JSON numbers are to be encoded as integers unless the field is > > defined to be encoded otherwise. > > 5. Encoding rules are applied recursively to member values and array values. > > > > The rule on two key names is new, but is implicit as JWKs are not > > supposed to have two keys of the same name. Having a generic rule on > > maps means that one will not have a miss someplace if a new element is > defined. > > New Text: > >> > The JSON object MUST follow the following rules. These rules are based on the > thumbprint of a JSON Web Key (JWK) as defined in Section 3 Step 1 of > {{RFC7638}}. > > 1. The JSON object MUST contain no whitespace or line breaks before or after > any syntactic elements. > 2. JSON objects MUST have the keys ordered lexicographically by the Unicode > {{UNICODE}} code points of the member names. > 3. JSON value literals MUST be lowercase. > 4. JSON numbers are to be encoded as integers unless the field is defined to be > encoded otherwise. > 5. Encoding rules MUST be applied recursively to member values and array > values. > > Note: For any PASSporT extension claims, member names within the scope of a > JSON object MUST NOT be equal to other member names, otherwise > serialization will not be deterministic. > >> > > > > > Jim > > > > > > From nobody Mon Oct 31 11:05:46 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24242129416; Mon, 31 Oct 2016 11:05:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147793714214.32521.14757387834012759162.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 11:05:42 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-passport-10.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 18:05:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Personal Assertion Token (PASSporT) Authors : Chris Wendt Jon Peterson Filename : draft-ietf-stir-passport-10.txt Pages : 22 Date : 2016-10-31 Abstract: This document defines a method for creating and validating a token that cryptographically verifies an originating identity, or more generally a URI or telephone number representing the originator of personal communications. The PASSporT token is cryptographically signed to protect the integrity of the identity the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-passport-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 31 11:08:38 2016 Return-Path: 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 C1E6C12946F for ; Mon, 31 Oct 2016 11:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 Ebne4sDQAO7N for ; Mon, 31 Oct 2016 11:08:36 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 DAB03129615 for ; Mon, 31 Oct 2016 11:08:35 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id p16so78421385qta.0 for ; Mon, 31 Oct 2016 11:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=ZLXCOsZNSoGw2FJTDNXb8J+owbRv+lfBKTmVdAdyPTQ=; b=eVFwFx2pg4xcwleoAMOkwXF61RWxVwiplFdVIxucEFTn71IM3F0M4KTCJ9BHe8Eqbd 5PwkNHitTCk+4zBNACrt2y3BCX/KIfTNveWP2HXDWPp+8rD36ufU3bYGgiRjsByi4FGG 70MCnEcvb3KBOjc4Q+6PtCeZoBWu495jhJhKdTKmnIpOL63g4H9xYnC4iRwe3CLG0Twn k83PUlFbl2LhqmwvXTXoNvXYfOrmJZsd2/N7iZ2twj5fCbj6WeaizvDjOD5M8+5xpnFO MCej9wi0KycP+ansuV8g4HcP9Gw/0Mn8Y66BDeugbquEqsfcsVwA0PgjtRLkwUyvuI3x YK4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=ZLXCOsZNSoGw2FJTDNXb8J+owbRv+lfBKTmVdAdyPTQ=; b=JqtJHipTu6ISC2LfFbGJVWYI4J5C05QiyJY+9mRIAd4O5rn7vsxp/b4s2JA1mHa1JE 9/b2kXF6rvnxlfOFKTdT29hqTUorPZYRDukmS762XbQlTRgda/8N6NOqOM6oq4YsU5X/ YSwcd6OtmguRKOaDpcddHq/CzcVThVkY/v095IGhz5OQBR0oBxyVVv7avsMrCmPwKzaV EHWVa1uFA9kM9Ri+FZy0rwhvMPP9ir1ctozJIYJKve3HkE8njW8GTiZMoz67uoi/2uS/ KKmKxZr6czlkexdTKXO7lCVWzSgwh/eAY1OSG/wDEJbRC7OrFOYFZm6jT1tRfx9vJUXX hcpg== X-Gm-Message-State: ABUngvcGfQbc9beDxhPSOn5WsQPjut+mYbP5cPb2YrWAj3SIJJZphzP/qdeoc8lyP/TMvg== X-Received: by 10.200.54.89 with SMTP id n25mr21724338qtb.82.1477937314851; Mon, 31 Oct 2016 11:08:34 -0700 (PDT) Received: from ?IPv6:2601:a40:100:d3:8037:d043:56d4:370b? ([2601:a40:100:d3:8037:d043:56d4:370b]) by smtp.gmail.com with ESMTPSA id m201sm13827368qke.1.2016.10.31.11.08.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 11:08:34 -0700 (PDT) From: Chris Wendt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Mon, 31 Oct 2016 14:08:33 -0400 References: <147793714214.32521.14757387834012759162.idtracker@ietfa.amsl.com> To: IETF STIR Mail List In-Reply-To: <147793714214.32521.14757387834012759162.idtracker@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3251) Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-10.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 18:08:38 -0000 This draft addresses all of the final review comments that have be = submitted for technical content as well as IANA related requests. -Chris > On Oct 31, 2016, at 2:05 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Telephone Identity Revisited = of the IETF. >=20 > Title : Personal Assertion Token (PASSporT) > Authors : Chris Wendt > Jon Peterson > Filename : draft-ietf-stir-passport-10.txt > Pages : 22 > Date : 2016-10-31 >=20 > Abstract: > This document defines a method for creating and validating a token > that cryptographically verifies an originating identity, or more > generally a URI or telephone number representing the originator of > personal communications. The PASSporT token is cryptographically > signed to protect the integrity of the identity the originator and = to > verify the assertion of the identity information at the destination. > The cryptographic signature is defined with the intention that it = can > confidently verify the originating persona even when the signature = is > sent to the destination party over an insecure channel. PASSporT is > particularly useful for many personal communications applications > over IP networks and other multi-hop interconnection scenarios where > the originating and destination parties may not have a direct = trusted > relationship. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-stir-passport-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-passport-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon Oct 31 11:35:17 2016 Return-Path: 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 E75711299D0 for ; Mon, 31 Oct 2016 11:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 TufIJvId6Vcd for ; Mon, 31 Oct 2016 11:35:14 -0700 (PDT) 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 BA8C51299DA for ; Mon, 31 Oct 2016 11:35:09 -0700 (PDT) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9VIZ8Lr057585 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Mon, 31 Oct 2016 13:35:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: stir@ietf.org From: Robert Sparks Message-ID: <0ef9dce2-b99e-477e-e0bb-83e084f4f923@nostrum.com> Date: Mon, 31 Oct 2016 13:35:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] Initial STIR Agenda for Seoul X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 18:35:16 -0000 STIR - IETF97 Wednesday 0930-1100 0930 ( 5m) : Administrivia (chairs) 0935 (10m) : Status of rfc4474bis, passport, certificates (chairs) 0945 (35m) : Out-of-band (Jon Peterson) 1020 (20m) : Passport Extensions (Jon Peterson, Chris Wendt) 1040 (10m) : Using STIR with ACME (Jon Peterson) 1050 (10m) : Charter checkpoint - recharter? (chairs) From nobody Mon Oct 31 13:59:48 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2881129ADD; Mon, 31 Oct 2016 13:59:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147794758585.23209.3446265083517786981.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 13:59:45 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-rfc4474bis-15.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 20:59:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Authenticated Identity Management in the Session Initiation Protocol (SIP) Authors : Jon Peterson Cullen Jennings Eric Rescorla Chris Wendt Filename : draft-ietf-stir-rfc4474bis-15.txt Pages : 44 Date : 2016-10-31 Abstract: The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity, and for conveying a reference to the credentials of the signer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-rfc4474bis-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 31 15:28:48 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4B112946D; Mon, 31 Oct 2016 15:28:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147795292710.23271.8308574982511219545.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 15:28:47 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-certificates-11.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:28:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Secure Telephone Identity Credentials: Certificates Authors : Jon Peterson Sean Turner Filename : draft-ietf-stir-certificates-11.txt Pages : 23 Date : 2016-10-31 Abstract: In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-certificates-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-certificates-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/