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

Stephen Farrell <> Thu, 03 November 2016 14:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06ED3129A56; Thu, 3 Nov 2016 07:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.798
X-Spam-Status: No, score=-5.798 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P73ZXcf2tGKc; Thu, 3 Nov 2016 07:40:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3675129A85; Thu, 3 Nov 2016 07:40:24 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E38CDBE5B; Thu, 3 Nov 2016 14:40:20 +0000 (GMT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W2v_IcCie3DE; Thu, 3 Nov 2016 14:40:20 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 38540BE2C; Thu, 3 Nov 2016 14:40:20 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1478184020; bh=WANyAJcs8JApWdLzlD+y2beduxPvyXiAMDFn1oX/E0I=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=A6PIg6EZQ39riKO7IC7JTWpie9HfKXXuMifHAna56wgyIGn52yqfCjWhtiIvqGU0H 058NGxnWZeAQbekLn9BL49xK9ZdvJepn+11wMGputO/pdLPm4vucf6ZG9Q3EN5ZNhc mhYAROfxYKvpcYPq5NBhL0pO0wX0Z+9QGNuyEIEg=
To: "Peterson, Jon" <>, The IESG <>
References: <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Thu, 03 Nov 2016 14:40:20 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms040005070209050205000500"
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:40:28 -0000


On 03/11/16 14:00, Peterson, Jon 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.
> 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.
> 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.

Fair enough, probably just me not knowing what folks are
planning. Assuming nobody yells, I'll clear this point.

>> (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
>> us;-).
> 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.

If how to use short-lived certs and OCSP are sufficiently
well-defined (cf. other discuss points) then I think it'd
be nearly a no-brainer to say short-lived certs are MTI
with OCSP an option, or to just make both MTI. So maybe
this point will resolve as we discuss the others.

>> (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.

So my concern isn't whether short-lived is good or bad vs. OCSP,
but just whether or not the signer and RP having different ideas
about what is or is not short-lived can lead to interop problems.
E.g. if the signer thinks it's using a short-lived cert but the
RP figures that OCSP is needed, then passports will fail to be
accepted. Don't we need to avoid that kind of falure?

>> (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.

6960 is OCSP, so maybe you mean 5019? (Which I'd forgotten:-)
To clarify though my concern here is as with the previous
one, I just want to check that we don't hit problems if the
signer and RP have different ideas about what's a HVE or not.

>> (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.

AFAIK, this would be breaking new ground yes so probably
does need some thought.


> 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
>> though.)
>> - 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
>> wrong.
>> - 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?