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

[Stephen Farrell <[e-mail]>]

Hiya,

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.

S.

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