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

["Peterson, Jon" <[e-mail]>]

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

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

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

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