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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 02 Nov 2016 18:55:01 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-stir-certificates-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Sorry but I have a load of discuss points on this one. I don't
think any of 'em are that hard though, except maybe one. (I'll let
us all guess which one:-)

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

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

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

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

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

(6) section 10: as with short-lived, don't you need to define HVE?

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 3 Nov 2016 09:05:13 +0000

Hi,

> On 3 Nov 2016, at 01:55, Stephen Farrell <[email-masked]> wrote:
> 
> the field names but you don't say.

This is basically covering my main DISCUSS point.

I was also wondering if any of these value can possible contain non ASCII Unicode characters, and if they do, how can they be encoded as IA5String.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 3 Nov 2016 14:00:16 +0000

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

>extension can or needs to be critical.

Already talking about this one separately...

>extension (if that's allowed, and if it is, then complexity awaits

This one I'll defer to Sean.

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

>failures seem likely. Bottom line for this point: what's a short

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.

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Nov 2016 14:40:20 +0000

Hiya,

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

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

> approach to doing status information. The jury's still out on which will

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?

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

> obviously that would take some doing.

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

S.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 3 Nov 2016 14:48:03 +0000

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.

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

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

>s/obviously/initially/ would seem more accurate.

OK.

>like this? If so, maybe re-word 'em so that they're not going to

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

Jon Peterson
Neustar, Inc.