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

["Stephen Farrell" <[e-mail]>]

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?