Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT)

Richard Shockey <> Thu, 03 November 2016 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EFB61200DF for <>; Thu, 3 Nov 2016 13:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (768-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xMGHwgfjo2hH for <>; Thu, 3 Nov 2016 13:15:14 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 9A60112973D for <>; Thu, 3 Nov 2016 13:15:13 -0700 (PDT)
Received: (qmail 16960 invoked by uid 0); 3 Nov 2016 20:15:08 -0000
Received: from unknown (HELO cmgw4) ( by with SMTP; 3 Nov 2016 20:15:08 -0000
Received: from ([]) by cmgw4 with id 3Y8Z1u00K1MNPNq01Y8cBw; Thu, 03 Nov 2016 14:08:36 -0600
X-Authority-Analysis: v=2.1 cv=fZg+lSgF 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=L24OOQBejmoA:10 a=ZZnuYtJkoWoA:10 a=48vgC7mUAAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=NwrGN2YM4aAADE8-eYsA:9 a=9Mz32QgxqChfrjMJ:21 a=8DQOrFDq-nKm14Er:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Q-ofuW86YyylptHqTH-7:22 a=d0-0EwFVFT64L02gzcZV:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID: CC:To:From:Subject:Date; bh=7CJBZaxNHtqQ99Ucm6dc2Z64AgRtZMqItCMW7bA0qQQ=; b=O IdY38lFjRfWt5R08mRl75lfb5nMvKTLdruN4Twu7G9y4PUP0XYpDULl+AOGKNPm+A7vJ1zLCRTfz3 uBwnSKlXKq4+utgANV9kmF688bqUDC6hjjdkoYmTXGjS4ywQ1/;
Received: from ([]:52645 helo=[]) by with esmtpa (Exim 4.86_1) (envelope-from <>) id 1c2OJM-0007ef-ST; Thu, 03 Nov 2016 14:08:33 -0600
User-Agent: Microsoft-MacOutlook/f.1b.0.161010
Date: Thu, 03 Nov 2016 16:08:30 -0400
From: Richard Shockey <>
To: "Peterson, Jon" <>, Stephen Farrell <>, The IESG <>
Message-ID: <>
Thread-Topic: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT)
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Exim-ID: 1c2OJM-0007ef-ST
X-Source-Sender: ([]) []:52645
X-Email-Count: 2
X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ==
Archived-At: <>
Cc: "" <>, Robert Sparks <>, "" <>, "" <>
Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT)
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, 03 Nov 2016 20:15:18 -0000

On 11/3/16, 10:00 AM, "stir on behalf of Peterson, Jon" < on behalf of> wrote:

    >(1) TN auth list services - IIUC, these are not free today.  Is
    >that correct?  It's not clear to me that alternatives such as
    >listing all good numbers inside a cert are practical.  Did the WG
    >have an explicit consensus that building in a requirement to have
    >verifiers pay to be an effective RP is ok?  If so, can you send a
    >pointer to the list archive or minutes where that was agreed. If
    >not, don't the WG need to explicitly ok that?
    Um, I think the most immediate plans for stir-certs deployment include
    just using SPIDs, in which case the TNs hardly factor into it. Agreed that
    listing all good numbers inside a cert is likely not practical, except for
    cases where a cert contains just a single number or a manageable block -
    and that's probably the second-most-immediate plan for deployment.

RS> Just to concur with Jon here the preliminary US Profile of STIR, which is called SHAKEN developed out of ATIS and the SIP Forum NNI Task Force, the claims are made by licensed service providers that have a NECA Operating Carrier Number (OCN) which is sort of a SPID. 

The basics of SHAKEN was reported to the FCC by the Industry robocall strikeforce.

There are provisions in our profile for per TN assertions but at this preliminary point, it is only for highly specific applications.  Jon is correct that it is way way too soon to speculate further until there are some preliminary deployments. The good news this it will deploy though there may be national specific differences.  

    I don't think there is any real analog to the services required for
    fancier things here in the marketplace today. This'll be new. If it's done
    with OCSP, as the draft recommends, it'll cost about as much as OCSP does
    - which is a cost built into the certs, not a cost to relying parties. So
    in short, I'm not sure anyone is viewing this as a potential profit
    center. You'll note that some ACME-related drafts are starting to appear
    (draft-peterson-acme-telephone, say) which point in the likely direction
    this is all going.

RS> Well we’ll see about that.  
    But to be clear, I completely agree that you should not have to pay to be
    a verifier - I just don't think that's what the mechanism does.

RS> This is dependent on the particular national profile of how the standards deploy.  This is NOT IMHO a one size fits all. 

    >(2) setion 8: you need to say more clearly exactly what the
    >IA5String values in the extension map to in the JWT. I assume it's
    >the field names but you don't say. You need to say if this
    >extension can or needs to be critical.
    Already talking about this one separately...
    >(3) section 9: you need to say whether this extension needs to be
    >or can be critical and where in the cert path it's allowed to be
    >and how to interpret things if >1 cert in the path has this
    >extension (if that's allowed, and if it is, then complexity awaits
    This one I'll defer to Sean.
    >(4) section 10: you need to pick one MTI method I think. Why is
    >that wrong? You nearly, but not quite, do. Why not just do it?
    We aren't confident enough to do it yet. We want to throw some ideas out
    there and try them in the marketplace. A lot of people are telling me they
    like short-lived certs for this; others like OCSP. OCSP will look more
    attractive if we figure out how to get stapling to work with SIP.
    I'd say we've got enough here that it's worth a PS and some
    implementation, but I'm interested to see how it goes.
    >(5) section 10: don't you need to somehow define "short-lived"?
    >That could be defined as an RP-configurable value, but even if so,
    >I think you need to say that. Even if you do that, I'm not sure
    >that an RP-configured value is right as short-lived certs, vs.
    >not, puts a different burden on the signer and if the signer and
    >RP have different ideas of what short-lived means, then interop
    >failures seem likely. Bottom line for this point: what's a short
    >lived cert?
    Well, in this section a short-lived cert is largely a strawman discussed
    for rhetorical effect, not a fully-baked proposal. At the end of the
    section we say that the rest of the doc is going to explore the
    alternatives. Now again, I do think there are some good ideas about using
    short-lived certs for STIR, and I wouldn't be surprised if those were
    documented elsewhere. But for this baseline doc, we wanted to show an
    approach to doing status information. The jury's still out on which will
    turn out to be better.
    >(6) section 10: as with short-lived, don't you need to define HVE?
    I would have thought the ref to RFC6960 was sufficient for at least
    defining it? That much said we're kind of just stealing ideas from HVE to
    build up our own profile.
    >(7) section 10.2.1: Can OCSP be made use HTTPs here?  If not, then
    >you have the RP sending out the caller's TN in clear.  That seems
    >bad (cf. BCP188). Did the WG consider that? If this spec needs
    >OCSP/HTTPs then I think you need to have a new MUST for that (it's
    >uncommon or maybe never done?) and address the potential bootstrap
    >issues. (But I didn't think those through - did the WG?)
    I don't think we gave confidentiality for OCSP any serious consideration.
    At the very least that issue should be documented in the draft. If there's
    a reasonable fix, I'd be happy to use it - if it's breaking new ground,
    obviously that would take some doing.
    I'll respond to the comments below separately.
    Jon Peterson
    Neustar, Inc.
    [ (1) was the hard one, right? ]
    >General - So a passport structure or SIP message can have a URI
    >for the cert. And the cert can have URLs for OCSP and AIA and for
    >a TN download service. That's potentially an awful lot of comms
    >out of the RP to do STIR. Has someone put all that together into a
    >usable assembly? If so, where's that documented? (To be open about
    >it, I was more of a fan of the DKIM starting point for this work,
    >but that's really just opinion, so this is definitely a
    >non-blocking comment.  I'd still be intersted in an answer
    >- section 5: "Assignees of E.164 numbering resources participating
    >in this enrollment model should take appropriate steps to
    >establish trust anchors." That's ambiguous. Do you mean they
    >should establish a list of other folk's public keys they trust or
    >that they should generate their key pair and get their public key
    >on other folk's list of trust anchors?
    >- section 7: What's the REQUIRED for EST about? That just seems
    >- section 10: SCVP? Really? Does anyone do that? I'd say get rid
    >of that text, it'll only cause grief.
    >- section 10: "CRLs are an obviously attractive solution" hmm -
    >s/obviously/initially/ would seem more accurate.
    >- 10.2: last two paras are speculative - do they belong in a spec
    >like this? If so, maybe re-word 'em so that they're not going to
    >confuse an implementer?
    stir mailing list