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

"Peterson, Jon" <> Thu, 03 November 2016 14:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A0BC12963F; Thu, 3 Nov 2016 07:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.701
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q2DJ2olfNt-M; Thu, 3 Nov 2016 07:48:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C1F312966A; Thu, 3 Nov 2016 07:48:07 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id uA3EjhF9032533; Thu, 3 Nov 2016 10:48:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar-biz; bh=pe1uV2F7N9DzyOxFTTPsOM/9zVkf45P2hy8ecjF43GE=; b=QSHmt1QKdhiE13Ok0O1udhGrSuVb62CibsDrILIgEZ2Pe3x2oogP3JTVh+nVeaXiP9zH CN8sLo084kgHFzeWkmO6+N580NzK+l8cenrPJV/OtsSimmU7wJKlUMLd8EMDAE3vnZIY 7UWajDmEguFlCWkEqQV3wlJgnlnvQCzuKYR4BnsHIwGvWx4sCkLsPQBde0wYFAL4fiGB aRVQy35+DdR8Sp5bNoZl9uxjlYbwb/f6nl8JwVkrRDCKvIWdcg1ucAchNJBO0RcElQ4h 3Hke/aP8X4/WTt6Z5ZJu+eU+2ZfBoxtYaD747c7MOYXPsZbTdZjYbzB06acCZ1Kzo48M Hw==
Received: from ([]) by with ESMTP id 26cqs39fhn-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 03 Nov 2016 10:48:04 -0400
Received: from ([]) by ([::1]) with mapi id 14.03.0279.002; Thu, 3 Nov 2016 10:48:04 -0400
From: "Peterson, Jon" <>
To: Stephen Farrell <>, The IESG <>
Thread-Topic: Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT)
Date: Thu, 03 Nov 2016 14:48:03 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-03_05:, , 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-1611030274
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 14:48:09 -0000

Just the comments here:

>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

We're looking at OCSP staples, we're looking at a variety of optimizations
going forward. As I suggested in my other mail, this is a situation where
I think we have enough agreement on a direction to publish but we still
need some deployment experience.

And incidentally, we haven't entirely closed the door on acquiring
credentials with the DNS either - we left that as a point of architectural
modularity in the design of rfc4474bis. It just wasn't a direction we
happened to have enough energy to pursue.

>- 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?

More the latter, but we're intentionally not being prescriptive here -
national regulators and so forth will do as they see fit, we're just
suggesting they take whatever they might think would be appropriate steps.

>- section 7: What's the REQUIRED for EST about? That just seems

I'll defer this to Sean.

>- section 10: SCVP? Really? Does anyone do that? I'd say get rid
>of that text, it'll only cause grief.

Again, this section is just trying to enumerate the options and explain
why we're exploring the paths we're exploring. We're not suggesting anyone
do SCVP. But since like I said we're still in a situation of some
uncertainty, it seemed valuable to document our thinking.

>- 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?

They are indeed speculative. Perhaps we could cordon these off in their
subsection labeled "future directions" or something to avoid implementer

Jon Peterson
Neustar, Inc.