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

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

Just the comments here:

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

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

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.

OK.

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

Jon Peterson
Neustar, Inc.