Subject: [stir] Comments on draft-ietf-stir-certificates-08

From: Anders Kristensen <[email-masked]>
Date: Sun, 2 Oct 2016 16:25:26 -0700

* 3: s/SubjectAltName/subjectAltName/ - for consistency if nothing else.

* 3: The first approach is to use subjectAltName and the second is to use
the TN Auth List defined in this doc. If one wanted to use SPID then
presumably the right way to do it would be to use the TN Auth List but the
text here talks about using SPID in subjectAltName. Probably shouldn't be
encouraged.

* 4:

   o  See Section 7
<https://tools.ietf.org/html/draft-ietf-stir-certificates-08#section-7>
for requirements related to the TN Query certificate
      extension.

Was this meant to refer to TNAuthorizationList rather than TNQuery?

* 7: My preference would be to not list support for SIP as mandatory for
info URIs. Using SUBSCRIBE/NOTIFY feels contrived and unnecessary.

* 7: OTOH using data: might make sense. Avoids cid: issue with
non-multipart support.

* 7: Re caching of certs, the doc could mention that a best practice is for
the server to never modify resources identified by info URIs, e.g. use cert
serial number rather than subjectAltName in the URI.

* 8: So TNAuthorizationList is List<List<TNEntry>>. Why can't it just be
List<TNEntry>?

* 8: I'm not sure if ServiceProviderIdentifierList is supposed to contain
SPID, Alt SPID and Last Alt SPID in that order. For example, if a cert
contains a TNEntry with a spid of length 2 then those two entries would be
expected to match SPID and Alt SPID of the calling number respectively?

* 9: s/all/call/

* 9.2: ISTM that if OCSP is always used to check freshness of TN auth lists
then the actual content of the list is irrelevant. The authority check has
just been delegated to the CA...

* 9.2: I guess OCSP is not really for the SPID case? If so, maybe mention.

* 9.3: s/list of TNs/calling number/ ?

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 6 Oct 2016 23:02:13 +0000

Appreciate the nit fixes here; a few responses on more substantial points.

* 7: My preference would be to not list support for SIP as mandatory for info URIs. Using SUBSCRIBE/NOTIFY feels contrived and unnecessary.

The reason we included this back when was for future compatibility with potential systems that would let you subscribe to certificates and receive updates when they were changed: we imagined this might make sense for some high-volume verification services. Given how far down the OCSP path this document goes today, perhaps that isn't strictly necessary - but I can still imagine deployments where it make might sense. Supporting SIP is basically free for SIP implementations, so it doesn't seem like much of a burden to keep this option open.

* 7: OTOH using data: might make sense. Avoids cid: issue with non-multipart support.

I don't think we'd want to make that data URL yet another parameter of the Identity header, which is already getting quite long with a full form PASSporT. I don't think it's unreasonable to have a way to carry a certificate by-value in a header, though I'd look to future work for that.

* 8: So TNAuthorizationList is List<List<TNEntry>>. Why can't it just be List<TNEntry>?

The original justification for this, I think I dimly recall, was that we were going to have other categories than TNAuthorizationList under TNAuthorization - but that was many moons ago. I think at this point we can safely collapse that down into one level.

* 8: I'm not sure if ServiceProviderIdentifierList is supposed to contain SPID, Alt SPID and Last Alt SPID in that order. For example, if a cert contains a TNEntry with a spid of length 2 then those two entries would be expected to match SPID and Alt SPID of the calling number respectively?

It hadn't occurred to me that the order might be significant to relying parties. Is there any reason it would be? As far as I know, the question is whether the relying party trusts any of the SPIDs that might appear in this array; the ordering shouldn't be significant.

* 9.2: ISTM that if OCSP is always used to check freshness of TN auth lists then the actual content of the list is irrelevant. The authority check has just been delegated to the CA...

Agreed that if you use OCSP the way this section describes, then yes, the cert is basically just delivering you the tools to query OCSP, and you might as well not even bother including the TN Authorization List. I think that at best, in these cases, the TN Authorization List might be used for an initial sanity check before incurring the RTT of checking OCSP. Including the TN Authorization List by value probably more useful for single telephone numbers than for ranges, in any event.

Jon Peterson
Neustar, Inc.