Re: [stir] Review: draft-ietf-stir-certificates-07

[Sean Turner <[e-mail]>]

Dave,

Thanks for the review.  Apologies for taking so long to get to back to this; I had a life event recently that made synching up with Jon on a response take longer than anticipated.

> On Aug 12, 2016, at 11:51, Dave Crocker <[e-mail]> wrote:

-snip-
>> Abstract
>> 
>>   In order to prevent the impersonation of telephone numbers on the
>>   Internet, some kind of credential system needs to exist that
>>   cryptographically proves authority over telephone numbers.  This
>>   document describes the use of certificates in establishing authority
>>   over telephone numbers, as a component of a broader architecture for
>>   managing telephone numbers as identities in protocols like SIP.
> 
> It mostly does not 'describe the use'.  It has bits of discussion, about bits of use, but gives no integrated description.  It also contains a few bits of incomplete specification.

It allows things to be done a few different ways because people want to use certs with STIR a few different ways.

-snip-
>> 
>> 
>>   One of the most important components of a system to prevent
>>   impersonation is the implementation of credentials which identify the
>>   parties who control telephone numbers.  With these credentials,
> 
> Credentials normally are for validation, not identification. Typically, the user already has the identifier.  So identification of the owner, per se, is not the goal.

Credentials are normally used to identify the party to which the credentials have been assigned. The dictionary definition of “credential" I see on Google is "a document or certificate proving a person's identity or qualifications". This isn't being used in any different sense here.  There’s also a definition in RFC 4949 of credential (search for ”$ credential”) that lines up with this use.

> In any event, are these credentials really that usage-specific? Normally, credentials are simply a means of validating some information associated with an identifier, but they aren't so tightly coupled with a particular application.

For this application, for STIR and it's threat model, credentials need to serve this purpose (to "identify the parties who control telephone numbers"). That doesn't mean the credentials STIR uses have to be limited to that purpose, just that this have to perform it.

-snip-
>>   present such credentials.  For that reason the STIR threat model
>>   [RFC7375] stipulates, "The design of the credential system envisioned
>>   as a solution to these threats must, for example, limit the scope of
>>   the credentials issued to carriers or national authorities to those
>>   numbers that fall under their purview."  This document describes
> 
> The quoted text is meant to provide an underpinning to the current specification.  Unfortunately there is no obvious meaning to "limit the scope of the credentials".  For example, it might refer to limitations in the semantics, or it might refer to the distribution of the credential.  The reader can't tell.

It says "limit the scope... to those numbers that fall under their purview." So it clearly isn't talking about the distribution of the credential, it's talking about the semantics.

-snip-
>> 3.  Authority for Telephone Numbers in Certificates
>> 
>>   At a high level, this specification details two non-exclusive
> 
> 'non-exclusive' is distracting and doesn't add the clarity it intends. There is no default assumption that adding one set of enhancements now precludes adding others later.

Some people might think these are mutually exclusive approaches, we explain why they aren't.

>>   approaches that can be employed to determine authority over telephone
> 
> I suspect these are not 'approaches' but rather are specific capabilities.

They are different approaches to the problem of determining authority over telephone numbers. The certificates used for these two different approaches contain different information. Not sure if the presence or absence of that information is a "capability," but I suspect not.

>>   numbers with certificates.
> 
> 'can be'...
> 
> This appears to be saying that this specification does not provide a clear and interoperable solution for the use of certificates to validate telephone numbers.  That is, by defining two, the two parties to use of a cert could each make different choices and fail to interoperate.

It is saying that it provides two approaches, both of which are clear and interoperable, but which are intended for use in a different trust model. They are not mutually interoperable in the sense that a relying party who subscribes to one trust model wouldn't trust parties who don't operate within that model. No different than receiving something signed by a trust anchor you don't trust.

> After some re-reading, I'm suspecting that what this paragraph intends to mean is something like:
> 
>     This specification defines two enhancements to common X.509 certificates.  One indicates the subject of the certificate

No, it doesn't describe an enhancement of that form, as the subject of certificates is existing in the specification of certificates.

> But unfortunately I think it does not actually define either of them as complete and implementable.

The use of a subject of a certificate to determine whether it is trusted or not is a common practice that is neither defined nor specified in this document. What is novel here is adding information to a certificate that explicitly gives a "scope" of authority over telephone numbers. The part of this document this specifies a new technology is that part.

-snip-
> 
>>   The first approach is to leverage the subject of the certificate to
>>   ascertain that the holder of the certificate is authorized to claim
>>   authority over a telephone number.  The subject might be represented
>>   as a domain name in the SubjectAltName, such as an "example.net"
>>   where that domain is known to relying parties as a carrier, or
> 
> This appears to be saying that the consumer of a certificate must have significant, independent knowledge of the semantics and use of the certificate's contents.  That's likely to be a serious issue. How will they obtain this?  What will ensure that certificates are, in fact, interoperably useful?

This model assumes that relying parties all have bilateral trust agreements, yes. It is modeled on similar trust relationships in the telephone network.

>>   represented with other identifiers related to the operation of the
>>   telephone network including Service Provider Identifiers (SPIDs)
>>   could serve as a subject as well.  A relying party could then employ
>>   an external data set or service that determines whether or not a
>>   specific telephone number is under the authority of the carrier
>>   identified as the subject of the certificate, and use that to
>>   ascertain whether or not the carrier should have authority over a
> 
> How is this sort of hypothetical useful for providing concrete specification detail?

Describing this practice is useful for reasons that have nothing to do with providing concrete specification detail.

> If, ultimately, this is saying that the specification here is merely providing some common syntax, but that complete specification of the semantics is out of scope for the document, then it needs to say that early and clearly.  It probably also should explain why.

This isn't saying that the specification here is merely providing some common syntax.

> However, of course, this opens the question for where that additional information is specified. And how is the reader to know?

That additional information is not provided in some other place, so there is no need for a reader to wonder where it is.

>>   telephone number.  Potentially, a certificate extension to convey the
>>   URI of such an information service trusted by the issuer of the
>>   certificate could be developed (though this specification does not
>>   propose one).  Alternatively, some relying parties could form
>>   bilateral or multilateral trust relationships with peer carriers,
>>   trusting one another's assertions just as telephone carriers in the
>>   SS7 network today rely on transitive trust when displaying the
>>   calling party telephone number received through SS7 signaling.
> 
> Again, this explores hypotheticals rather than giving specification. While possibly useful for a general overview of this architecture and its possible application, it doesn't help with the current explanation.

This section is giving an overview of the architecture. The first paragraph of this section indicates that this section gives a high level description.

-snip-
>>   The first approach requires little change to existing Public Key
>>   Infrastructure (PKI) certificates; for the second approach, we must
>>   define an appropriate enrollment and authorization process.  For the
>>   purposes of STIR, the over-the-wire format specified in
>>   [I-D.ietf-stir-rfc4474bis] accommodates either of these approaches:
>>   the methods for canonicalizing, signing, for identifying and
>>   accessing the certificate and so on remain the same; it is only the
>>   verifier behavior and authorization decision that will change
>>   depending on the approach to telephone number authority taken by the
>>   certificate.
> 
> So the verifier must support both, since they won't know which the signer chose.

Ideally, we'd like verifiers to support both, yes. But since the second approach (the TN extension) can be built on top of certificates designed for the first approach (just relying on the subject), we might say that we fall back to the first approach for compatibility.

> What is the compelling benefit in defining these two different mechanisms?

While the former mechanism doesn't address all of the problems in the STIR threat model, it is an acceptable first step for the operating community. We want to define a migration path from that to a solution that will handle more of the threats.

>>   exclusive, and in fact a certificate issued to a traditional
>>   telephone network service provider could contain a TN Authorization
>>   List or not, depending on the CA issuing the credential.  Regardless
> 
> Sounds like good opportunity for conflicting information.

Or a good way to manage transitioning from one to the other.

>>   of which approach is used, certificates that assert authority over
>>   telephone numbers are subject to the ordinary operational procedures
>>   that govern certificate use per [RFC5280].  This means that
>>   verification services must be mindful of the need to ensure that they
>>   trust the trust anchor that issued the certificate, and that they
> 
>    "must be mindful of the need to ensure that they trust the trust anchor"  huh?

This says that you need to trust the CA that issued a certificate in order to trust the certificate. The previous sentence indicated that this sentence would describe some ordinary operational procedures that govern certificate use.

> This is a specification and I have no idea what the above text is specifying.

This is a sentence at the end of some expository text reminding the reader of guidance that is in RFC5280.

>>   have some means to determine the freshness of the certificate (see
>>   Section 9).
>> 
>> 4.  Certificate Usage
> 
> This section has nothing to do with /using/ certificates.  It provides some discussion -- but no specification -- of issues concerning the /creation/ of them.

See for example bullet 1 directly below. Is that about creating certificates? What about bullet 2? What about bullet 3? Or bullet 4? Maybe bullet 5 is salient to how certificates are issued. As the very next sentence reads, this section answers a set of questions that rfc4474bis asks of credential systems. Maybe we could retitle the section "Certificate Usage by STIR" if that would be less jarring.

>>   [I-D.ietf-stir-rfc4474bis] requires that all credential systems used
>>   for signing the Identity header in SIP detail the following:

-snip-
> 
>> 5.  Enrollment and Authorization using the TN Authorization List
> 
> This entire section contains no specification.  It describes a variety of things, and cites and summarizes a variety of things, but it provides no technical specification content.

This section is also largely introducing the certificate architecture.

>>   This document assumes a threefold model for certificate enrollment
>>   when using the TN Authorization List extension.
> 
> I don't know what a 'threefold model' is.  From the rest of the context, I suspect what is meant is something like:
> 
>     Certificates used as telephone identity credentials can follow any of three different certification models.
> 
> But really, that's just a guess at what's meant.

That rewording doesn't capture that this section is specific to the use of the TN Authorization List extension (which was not, say, true of Section 3). The phrase "threefold model" can go away if it's a problem, though.

> But I'm not clear what the benefit of this section's discussion is, since it neither specifies nor constrains anything.  So, for example, there's nothing that prevents having a twofold model or a fourfold model…

It is true this there could be other models that use the TN Authorization List than the one described here; this document however assumes that there are only three under serious consideration

> For that matter, the details of creating a workable cert system for this service border on being an open research task, which makes this section that much more marginal.  There is a long history of problematic cert use.  There is a storied history of problems with inter-provider phone-number-based query services.

It is saved from being an open research task by the fact that it is deployable today.

> But the current effort needs a working service that does both.  However there is /no/ history of a public phone-number-based query service at scale and with adequate privacy protection.

The truth of that statement hinges on what you mean by "adequate privacy protection". Any number of candidates exist, anyway.

> And yet the current task requires solving at least two of these and maybe all three…

No, the task at hand is specifying the TN Authorization List extension, and outlining some use cases in which it might be used. Three, in this section.

-snip-
> 
>> 5.1.  Levels Of Assurance
>> 
>>   This specification supports different level of assurance (LOA).  The
> 
> Where and how does it support this?  Where is it actually specified?

The text that follows answers these questions.

>>   LOA indications, which are Object Identifiers (OIDs) included in the
>>   certificate's certificate policies extension [RFC5280], allow CAs to
>>   differentiate those enrolled from proof-of-possession versus
>>   delegation.  A Certification Policy and a Certification Practice
>>   Statement [RFC3647] are produced as part of the normal PKI
>>   bootstrapping process (i.e., the CP is written first and then the CAs
>>   say how they conform to the CP in the CPS).  OIDs are used to
>>   reference the CP and if the CA wishes it can also include a reference
>>   to the CPS with the certificate policies extension.  CAs that wish to
>>   express different LOAs MUST include the certificate policies
>>   extension in issued certificates.  See Section 11 for additional
>>   information about the LOA registry.

-snip-
>> 5.2.  Certificate Extension Scope and Structure
>> 
>>   This specification places no limits on the number of telephone
>>   numbers that can be associated with any given certificate.  Some
>>   service providers may be assigned millions of numbers, and may wish
>>   to have a single certificate that is capable of signing for any one
>>   of those numbers.  Others may wish to compartmentalize authority over
>>   subsets of the numbers they control.
> 
> I suspect that certificates don't do signing.  I suspect what is meant is that the certificates can be applied to the signing of...  or somesuch.

Rather than "have a single certificate that is capable of signing" we
could say "have a single certificate that can be applied to the signing".

-snip-
>> 6.  Provisioning Private Keying Material
>> 
> Another non-specification section.

The specification of the TN Authorization List extension is in Section 8.

-snip-
>>     The specification recommends distribution of private keys through
>>   PKCS#8 objects signed by a trusted entity, for example through the
>>   CMS package specified in [RFC5958].
> 
> Why is this here?  It is such a generic 'recommendation' and so detached from the rest of the private key management issues, that it serves no useful purpose.

It resides in this section because it is a recommendation about the provisioning of private keying material. See the section title.

>> 7.  Acquiring Credentials to Verify Signatures
>> 
>>   This specification documents multiple ways that a verifier can gain
> 
> Where is this documented?

Mostly in the second and third paragraphs.

>>   access to the credentials needed to verify a request.  As the
>>   validity of certificates does not depend on the method of their
>>   acquisition, there is no need to standardize any single mechanism for
> 
> Well, this is an interesting assertion to make, given that it is fundamentally wrong.  Interoperability requires common conventions to be followed by both sides of an interaction, such as providing a credential and finding a credential.  Absent at least one common mechanism for this, there can be no guarantee of interoperability.

The validity of certificates does not depend on their method of acquisition. The cited text above does not guarantee interoperability or even mention it in any way. The second and third paragraphs below describe required support for common mechanisms of accessing credentials in order to guarantee interoperability.

>>   this purpose.  All entities that comply with
>>   [I-D.ietf-stir-rfc4474bis] necessarily support SIP, and consequently
>>   SIP itself can serve as a way to acquire certificates.
> 
> On what basis is it acceptable for the supplier of a request to provide their own credential???  What other security services operate useful with such a model?

On the basis that the validity of a certificate does not depend on who you got it from. A certificate is trusted or not by a relying party based on the relying party's trust for the CA that issued and signed the certificate. This is no different than, say, connecting to a web server and having the TLS connection in the backwards direction deliver a copy of the certificate for the web server. The browser trusts that certificate despite the fact that it was delivered from the party that the certificate exists to identify, because the browser trusts the CA that issued the certificate. 

BTW - sending the credential along with the signature "blob” is something that’s pretty common, see S/MIME, IPsec, and others.

>>   [I-D.ietf-stir-rfc4474bis] provides an "info" parameter of the
> 
> Don't repeat the technical details written elsewhere.

We cannot describe how to populate the "info" parameter without identifying that it exists. rfc4474bis delegates the specification of URIs in that parameter to credential specs (i.e. This).

>>   Identity header which contains a URI where the credential used to
>>   generate the Identity header, and requires documents which define
>>   credential systems to list the URI schemes that may be present in the
>>   "info" parameter.  For implementations compliant with this
>>   specification, three URI schemes are REQUIRED: the CID URI, the SIP
>>   URI, and the HTTP URI.
> 
> Why?

This is the part where we are encouraging interoperability. Bullet 1 of Section 4 outlines why we need to do this.

>>   The simplest way for a verifier to acquire the certificate needed to
>>   verify a signature is for the certificate be conveyed in a SIP
>>   request along with the signature itself.  In SIP, for example, a
>>   certificate could be carried in a multipart MIME body [RFC2046], and
> 
> Since this isn't being specified in enough detail, and as a requirement, then it appears to expect the verifier to guess that the information might be in some MIME body-part, somewhere in the object???

The previous paragraph contained a normative requirement that the CID header be supported; this sentence explains why CID support might be helpful.

> Again:  this is commentary about technical issues.  It isn't an actual spec.

No, that doesn't follow or apply.

>>   the URI in the Identity header "info" parameter could specify that
>>   body with a CID URI [RFC2392].  However, in many environments this is
>>   not feasible due to message size restrictions or lack of necessary
>>   support for multipart MIME.
>> 
>>   More commonly, the Identity header "info" parameter in a SIP request
> 
> "commonly"?  for something that has no field experience and isn't even mandatory?

In what field experience we have, this is how it is being used today.

>>   may contain a URI that the verifier dereferences with a network call.
> 
> "network" call?

We’ll strike “with a network call”.

--snip--
>> 8.  Verifying Certificate Scope with TN Authorization List
> 
> I don't see an algorithm for "verifying certificate scope".  For that matter, it's not entirely clear what this means, although I assume it equates to "discovering what the range of caller-ids covered by the cert is”.

This section presents a TN Authorization List that can be used to verify certificate scope.

>>   The subjects of certificates containing the TN Authorization List
>>   extension are the administrative entities to whom numbers are
>>   assigned or delegated.  When a verifier is validating a caller's
>>   identity, local policy always determines the circumstances under
>>   which any particular subject may be trusted, but the purpose of the
>>   TN Authorization List extension particular is to allow a verifier to
>>   ascertain when the CA has designed that the subject has authority
>>   over a particular telephone number or number range.
> 
> "Local policy always determines the circumstances under which any particular subject may be trusted, "
> 
> This is quite a profound statement, for a specification about an inter-organization certificate service.  While of course there is always the option or even requirement that the verifier retain a final authority over whether to treat a validation as credible, this statement mostly means that there is nothing in the design of the certification service that ensures or even encourages that belief.  Given that the cert system is the core of this entire service, that's sort of wild west model is problematic…

Local policy determines the circumstance under which any particular subject of a certificate may be trusted. This statement is neither profound nor problematic, it is just an obvious statement of fact that is true in virtually every system that relies on certificates, but bears repeating here because this extension described in this section provides additional information that relying parties might use to make a trust decision.

>>   The Telephony Number (TN) Authorization List certificate extension is
>>   identified by the following object identifier:
> 
> This sort of detail is usually provided either as an independent section about format, or during the specification of the /creation/ or /signing/ processes.  Having it be an independent format section works better, IMO, because then all three (signing, packaging, verifying) can refer to it equally, as needed.

This section specifies the extension.

> The formal meta-syntax here needs to be introduced and cited.  What is the meta-syntax language being used?  Since apparently this is meant as an extension, where is the ruleset it plugs into?

That is true, we’ll include some text to say it’s an X.509 extension, defined using ASN.1 (the ASN.1 references were in Appendix A but it’d be fine to move them up here too), etc. We will also add some text in s1 to explicitly note that the TN Authorization List is an X.509 extension; now it just says “extending X.509 with ... ” and doesn’t say we’re defining an “extension” until s4.

> And all of the rules that aren't defined here need to be explicitly defined or a citation given for their important.

Also true.

>>     id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD }
> 
> This rule appears to be unanchored to anything in this document and contains no pointer to any other.  Same for the two rules contained in it (id-ce and TBD).

This is the object identifier for the extension, but we can add more explanation in the paragraph that precedes this to say where the OID goes.  It’s TBD because we’re using an IANA defined OID arc see the IANA considerations section.

>>   The TN Authorization List certificate extension has the following
>>   syntax:
>> 
>>     TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNAuthorization
>> 
>>     TNAuthorization ::= SEQUENCE SIZE (1..MAX) OF TNEntry
>> 
>>     TNEntry ::= CHOICE {
>>       spid  [0] ServiceProviderIdentifierList,
>>       range [1] TelephoneNumberRange,
>>       one       E164Number }
>> 
>>     ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF
>>                                         OCTET STRING
> 
> This rule appears to be unanchored to anything in this document and contains no point to any other.  And note that the intro to this meta-syntax only said it would supply the "Telephony Number (TN) Authorization List certificate extension”.

A TNAuthorizationList is made up of TNAuthorizations, where are in turn a sequence of TNEntrys, which may contain ServiceProviderIdentifierLists. What exactly is unanchored here?

---snip--
>>   1.  A Service Provider Identifier (SPID) can be used to indirectly
>>       name all of the telephone numbers associated with that service
>>       provider,
> 
> Where does this identifier come from?  cite it.

We can cite a spec for SPID.

>>   2.  Telephone numbers can be listed in a range, and
> 
> What is the format of the numbers?  cite it.

That's E164Number.

--snip--
>>   3.  A single telephone number can be listed.
>> 
>>   Note that because large-scale service providers may want to associate
>>   many numbers, possibly millions of numbers, with a particular
>>   certificate, optimizations are required for those cases to prevent
>>   certificate size from becoming unmanageable.  In these cases, the TN
>>   Authorization List may be given by reference rather than by value,
>>   through the presence of a separate certificate extension that permits
>>   verifiers to either securely download the list of numbers associated
>>   with a certificate, or to verify that a single number is under the
>>   authority of this certificate.  This optimization will be detailed in
>>   future version of this specification.
> 
> If you aren't going to specify it here, don't describe it.  Make a reservation for the entry and don't say any more.  Describing the future is almost always wrong.

No, it is worth describing.

>> 9.  Certificate Freshness and Revocation
>> 
>>   Regardless of which of the approaches in Section 3 is followed for
>>   using certificates, some sort of certificate verification mechanism
> 
> No.  "some sort" isn't required.  Rather, an explicit, specific and interoperable sort is required.

We can remove "some sort."

>>   is required.  However, the traditional problem of certificate
>>   freshness gains a new wrinkle when using the TN Authorization List
>>   extension, because verifiers must establish not only that a
>>   certificate remains valid, but also that the certificate's scope
>>   contains the telephone number that the verifier is validating.
> 
> It isn't really a wrinkle.  It's just one more component in the cert that needs to be covered by the validity management mechanisms.

This however is well described as a wrinkle.

>>   Dynamic changes to number assignments can occur due to number
>>   portability, for example.  So even if a verifier has a valid cached
>>   certificate for a telephone number (or a range containing the
>>   number), the verifier must determine that the entity that signed is
>>   still a proper authority for that number.
> 
> This sounds more like a fundamental issue with caching behavior vs. 'freshness' enforcement.

Ordinarily yes, but we're casting the problem differently, which is why
we're talking about it differently.

>>   To verify the status of the certificate, the verifier needs to
>>   acquire the certificate if necessary (via the methods described in
>>   Section 7), and then would need to either:
>> 
>>   (a)  Rely on short-lived certificates and not check the certificate's
>>        status, or
> 
> This option is not an 'either/or' choice.  It is merely a choice of lifetime by the creator of the credential. If the cert is short-lived, the verifier-side problem presumably doesn't exist, as indeed later text here seems also to suggest.

A relying party can choose to do one of these two things.

>>   (b)  Rely on status information from the authority
> 
> What does 'rely on status information' mean?  What status information? Where is this specified? How is interoperability ensured?

We are going to specify that in 9.2 so we can add a pointer to that section.

>>   The tradeoff between short lived certificates and using status
>>   information is the former's burden is on the front end (i.e.,
>>   enrollment) and the latter's burden is on the back end (i.e.,
> 
> former = who?  latter = who?

This is clear in the text as written.

>>   verification).  Both impact call setup time, but it is assumed that
>>   performing enrollment for each call is more of an impact that using
> 
> What is meant by "performing enrollment for each call" and where is this specified?

It means such short-lived certificates that you generate a new one (and thus require a new enrollment) each time a call is placed. That can be expanded

>>   status information.  This document therefore recommends relying on
>>   status information.
> 
> Recommending between two unspecified mechanisms makes no sense.  There isn't enough detail here to justify making a recommendation.

The next section talks about approaches to status information. This section introduces why we need to choose a verification method.

>> 9.1.  Choosing a Verification Method
> 
> This section appears to basically cite some technology (not service) specifications and then discuss their use.  So we are back to not specifying the details of an interoperable credential service.

This section is motivating the use of a verification method. The following section specifies the details of that method, and 9.2.1 ultimately defined the extension.

--snip--
> 
>>   CAs in the STIR architecture will likely all create CRLs for audit
>>   purposes, but it NOT RECOMMENDED that they be relying upon for status
> 
> Again: making a recommendation in the absence of detail.  This is actually counter-productive.

The previous paragraph details why this recommendation has been made.

--snip--
> 
>> 9.2.  Using OCSP with TN Auth List
>> 
>>   Certificates compliant with this specification therefore SHOULD
> 
> A normative requirement of this type, here, makes no sense, since there is no OCSP service that is specified.

I looked at this one as running an OCSP Server is providing an "OCSP service”, we’re saying folks who issue certificates should run an OCSP server to provide a service.  The OCSP RFC also refers to it as a service: "An OCSP request contains the following data: …  - service request".  Further, one can locate the OCSP server with the AIA extension [RFC5280] and the AIA definition is as follows:

 The authority information access extension indicates how to
 access information and services for the issuer of the certificate
 in which the extension appears.

so “service” seemed to fit here.

spt (coordinated with Jon)