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

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Aug 2016 08:51:19 -0700

Review of:    Secure Telephone Identity Credentials: Certificates
I-D:          draft-ietf-stir-certificates-07.txt
Review date:  12 July 2016
Reviewed by:  D. Crocker

Summary:

An inter-organization crypto-based authentication service, such as is 
needed for telephone caller-id verification, needs a mechanism for 
finding and validating the public key used for verification.  A common, 
core component of such systems are credentials based on X.509 
certificates.  This document deals with that topic, for STIR-based services.

The Abstract only promises "description" of such services, rather than 
specification.  It mostly only delivers some discussion.  There are some 
very small segments of unanchored and incomplete specification.  However 
the document does not specify or even describe a STIR-based certificate 
mechanism.  Rather, the document is a mix of discussions /about/ 
STIR-based certificate-related issues, mostly at a rather abstract 
level.  The document also contains a variety of recommendations about 
choices, in spite of having no specific specification of services that 
are referenced.  That is, the recommendations are based on concepts 
rather than actualities.

In addition to the basic and extensive problems within the document 
itself, the details of creating a workable cert system for a service 
such as this border on being an open research task.  There is a long 
history of problematic cert use.  There is a storied history of problems 
with inter-provider phone-number-based query services.

But the STIR 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.

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

This document says that it is intended for Standards Track.  However it 
is not a specification and thus is entirely unsuited for standards 
track.  Neither does it contain material appropriate for BCP.

Overall, the document is extremely incomplete, even for what it appears 
to be attempting to provide.

This document is very far from being ready for publication.

d/

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

> Status of This Memo
>
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on January 9, 2017.
>
> Copyright Notice
>
>    Copyright (c) 2016 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>
>
>
> Peterson & Turner        Expires January 9, 2017                [Page 1]
> 
> Internet-Draft                 STIR Certs                      July 2016
>
>
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
>
> Table of Contents
>
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>    2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
>    3.  Authority for Telephone Numbers in Certificates . . . . . . .   3
>    4.  Certificate Usage . . . . . . . . . . . . . . . . . . . . . .   5
>    5.  Enrollment and Authorization using the TN Authorization List    6
>      5.1.  Levels Of Assurance . . . . . . . . . . . . . . . . . . .   7
>      5.2.  Certificate Extension Scope and Structure . . . . . . . .   8
>    6.  Provisioning Private Keying Material  . . . . . . . . . . . .   8
>    7.  Acquiring Credentials to Verify Signatures  . . . . . . . . .   9
>    8.  Verifying Certificate Scope with TN Authorization List  . . .  10
>    9.  Certificate Freshness and Revocation  . . . . . . . . . . . .  11
>      9.1.  Choosing a Verification Method  . . . . . . . . . . . . .  12
>      9.2.  Using OCSP with TN Auth List  . . . . . . . . . . . . . .  13
>        9.2.1.  OCSP Extension Specification  . . . . . . . . . . . .  13
>      9.3.  Acquiring TN Lists By Reference . . . . . . . . . . . . .  15
>    10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  16
>    11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
>    12. Security Considerations . . . . . . . . . . . . . . . . . . .  17
>    13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
>    Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .  20
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22
>
> 1.  Introduction
>
>    The STIR problem statement [RFC7340] identifies the primary enabler
>    of robocalling, vishing, swatting and related attacks as the
>    capability to impersonate a calling party number.  The starkest
>    examples of these attacks are cases where automated callees on the
>    PSTN rely on the calling number as a security measure, for example to
>    access a voicemail system.  Robocallers use impersonation as a means
>    of obscuring identity; while robocallers can, in the ordinary PSTN,
>    block (that is, withhold) their caller identity, callees are less
>    likely to pick up calls from blocked identities, and therefore
>    appearing to calling from some number, any number, is preferable.
>    Robocallers however prefer not to call from a number that can trace
>    back to the robocaller, and therefore they impersonate numbers that
>    are not assigned to them.
>
>    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.

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.

>    parties can prove that they are in fact authorized to use telephony
>    numbers, and thus distinguish themselves from impersonators unable to
>
>
>
> Peterson & Turner        Expires January 9, 2017                [Page 2]
> 
> Internet-Draft                 STIR Certs                      July 2016
>
>
>    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.

>    credential systems for telephone numbers based on X.509 version 3
>    certificates in accordance with [RFC5280].  While telephone numbers
>    have long been a part of the X.509 standard, this document provides
>    ways to determine authority more aligned with telephone network
>    requirements, including extending X.509 with a Telephone Number
>    Authorization List which binds certificates to authority for
>    particular telephone numbers, or potentially telephone number blocks
>    or ranges.
>
>    In the STIR in-band architecture specified in
>    [I-D.ietf-stir-rfc4474bis], two basic types of entities need access
>    to these credentials: authentication services, and verification
>    services (or verifiers).  An authentication service must be operated
>    by an entity enrolled with the certification authority (CA, see
>    Section 5), whereas a verifier need only trust the trust anchor of
>    the authority, and have a means to access and validate the public
>    keys associated with these certificates.  Although the guidance in
>    this document is written with the STIR in-band architecture in mind,
>    the credential system described in this document could be useful for
>    other protocols that want to make use of certificates to prove
>    authority over telephone numbers on the Internet.
>
>    This document specifies only the credential syntax and semantics
>    necessary to support this architecture.  It does not assume any
>    particular CA or deployment environment.  We anticipate that some
>    deployment experience will be necessary to determine optimal
>    operational models.
>
> 2.  Terminology
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in RFC
>    2119 [RFC2119].
>
> 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.

>    approaches that can be employed to determine authority over telephone

I suspect these are not 'approaches' but rather are specific capabilities.

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

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

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

>
>    The first approach is to leverage the subject of the certificate to

"
>    ascertain that the holder of the certificate is authorized to claim
>
>
>
> Peterson & Turner        Expires January 9, 2017                [Page 3]
> 
> Internet-Draft                 STIR Certs                      July 2016
>
>
>    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?

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

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.

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

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

>    The second approach is to extend the syntax of certificates to
>    include a new attribute, defined here as TN Authorization List, which
>    contains a list of telephone numbers defining the scope of authority
>    of the certificate.  Relying parties, if they trust the issuer of the
>    certificate as a source of authoritative information on telephone
>    numbers, could therefore use the TN Authorization List instead of the
>    subject of the certificate to make a decision about whether or not
>    the signer has authority over a particular telephone number.  The TN
>    Authorization List could be provided in one of two ways: as a literal
>    value in the certificate, or as a network service that allows relying
>    parties to query in real time to determine that a telephone number is
>    in the scope of a certificate.  Using the TN Authorization list
>    rather than the certificate subject makes sense when, for example,
>    for privacy reasons, the certificate owner would prefer not to be
>    identified, or in cases where the holder of the certificate does not
>    participate in the sort of traditional carrier infrastructure taht
>    the first approach assumes.
>
>    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.

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

>    exclusive, and in fact a certificate issued to a traditional
>
>
>
> Peterson & Turner        Expires January 9, 2017                [Page 4]
> 
> Internet-Draft                 STIR Certs                      July 2016
>
>
>    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.

>    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 is a specification and I have no idea what the above text is 
specifying.

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

>    [I-D.ietf-stir-rfc4474bis] requires that all credential systems used
>    for signing the Identity header in SIP detail the following:
>
>    1.  The URI schemes permitted in the SIP Identity header "info"
>        parameter, as well as any special procedures required to
>        dereference the URIs.  While normative text is given below in
>        Section 7, this mechanism permits the HTTP, CID and SIP URI
>        schemes to appear in the "info" parameter.
>
>    2.  Procedures required to extract keying material from the resources
>        designated by the URI.  Implementations perform no special
>        procedures beyond dereferencing the "info" URI.  See Section 7.
>
>    3.  Procedures used by the verification service to determine the
>        scope of the credential.  This specification effectively proposes
>        two methods, as outlined in Section 3: one where the subject (or
>        more properly subjectAltName) of the certificate indicates the
>        scope of authority through a domain name, and relying parties
>        either trust the subject entirely or have some direct means of
>        determining whether or not a number falls under a subject's
>        authority; and another where an extension to the certificate as
>        described in Section 8 identifies the scope of the certificate.
>
>    4.  The cryptographic algorithms required to validate the
>        credentials.  For this specification, that means the signature
>        algorithms used to sign certificates.  This specification
>        REQUIRES that implementations support both ECDSA with the P-256
>        curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447]
>        Section 8.2) for certificate signatures.  Implementers are
>        advised that RS256 is mandated only as a transitional mechanism,
>        due to its widespread use in existing PKI, but we anticipate that
>        this mechanism will eventually be deprecated.
>
>    5.  Finally, note that all certificates compliant with this
>        specification:
>
>
>
>
> Peterson & Turner        Expires January 9, 2017                [Page 5]
> 
> Internet-Draft                 STIR Certs                      July 2016
>
>
>        *  MUST provide cryptographic keying material sufficient to
>           generate the ECDSA using P-256 and SHA-256 signatures
>           necessary to support the ES256 hashed signatures required by
>           PASSporT [I-D.ietf-stir-passport], which in turn follows JSON
>           Web Token (JWT) [RFC7519].
>
>        *  MUST support both ECDSA with P-256 and RSA PKCS#1 v1.5 for
>           certificate signature verification.
>
>    This document also includes additional certificate-related
>    requirements:
>
>    o  See Section 5.1 for requirements related to the certificate
>       policies extension.
>
>    o  See Section 7 for requirements related to the TN Query certificate
>       extension.
>
>    o  See Section 9.2 and Section 9.3 for requirements related to the
>       Authority Information Access (AIA) certificate extension.
>
>    o  See Section 9.2.1 for requirements related to the authority key
>       identifier and subject key identifier certificate extensions.
>
> 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 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.

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

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.

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.

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

>
>    The first enrollment model is one where the CA acts in concert with
>    national numbering authorities to issue credentials to those parties
>    to whom numbers are assigned.  In the United States, for example,
>    telephone number blocks are assigned to Local Exchange Carriers
>    (LECs) by the North American Numbering Plan Administrator (NANPA),
>    who is in turn directed by the national regulator.  LECs may also
>    receive numbers in smaller allocations, through number pooling, or
>    via an individual assignment through number portability.  LECs assign
>    numbers to customers, who may be private individuals or organizations
>    - and organizations take responsibility for assigning numbers within
>    their own enterprise.  This model requires top-down adoption of the
>    model from regulators through to carriers.
>
>    The second enrollment model is a bottom-up approach where a CA
>    requires that an entity prove control by means of some sort of test,
>    which, as with certification authorities for web PKI, might either be
>    automated or a manual administrative process.  As an example of an
>    automated process, an authority might send a text message to a
>    telephone number containing a URL (which might be dereferenced by the
>
>
>
> Peterson & Turner        Expires January 9, 2017                [Page 6]
> 
> Internet-Draft                 STIR Certs                      July 2016
>
>
>    recipient) as a means of verifying that a user has control of
>    terminal corresponding to that number.  Checks of this form are
>    frequently used in commercial systems today to validate telephone
>    numbers provided by users.  This is comparable to existing enrollment
>    systems used by some certificate authorities for issuing S/MIME
>    credentials for email by verifying that the party applying for a
>    credential receives mail at the email address in question.
>
>    The third enrollment model is delegation: that is, the holder of a
>    certificate (assigned by either of the two methods above) might
>    delegate some or all of their authority to another party.  In some
>    cases, multiple levels of delegation could occur: a LEC, for example,
>    might delegate authority to a customer organization for a block of
>    100 numbers used by an IP PBX, and the organization might in turn
>    delegate authority for a particular number to an individual employee.
>    This is analogous to delegation of organizational identities in
>    traditional hierarchical PKIs who use the name constraints extension
>    [RFC5280]; the root CA delegates names in sales to the sales
>    department CA, names in development to the development CA, etc.  As
>    lengthy certificate delegation chains are brittle, however, and can
>    cause delays in the verification process, this document considers
>    optimizations to reduce the complexity of verification.
>
>    Future versions of this specification may also discuss methods of
>    partial delegation, where certificate holders delegate only part of
>    their authority.  For example, individual assignees may want to
>    delegate to a service authority for text messages associated with
>    their telephone number, but not for other functions.
>
> 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?

>    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.
>
>
>
>
>
>
>
> Peterson & Turner        Expires January 9, 2017                [Page 7]
> 
> Internet-Draft                 STIR Certs                      July 2016
>
>
> 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.

>
>    Moreover, service providers may wish to have multiple certificates
>    with the same scope of authority.  For example, a service provider
>    with several regional gateway systems may want each system to be
>    capable of signing for each of their numbers, but not want to have
>    each system share the same private key.
>
>    The set of telephone numbers for which a particular certificate is
>    valid is expressed in the certificate through a certificate
>    extension; the certificate's extensibility mechanism is defined in
>    [RFC5280] but the TN Authorization List extension is specified in
>    this document.
>
>    The subjects of certificates containing the TN Authorization List
>    extension are typically the administrative entities to whom numbers
>    are assigned or delegated.  For example, a LEC might hold a
>    certificate for a range of telephone numbers.  In some cases, the
>    organization or individual issued such a certificate may not want to
>    associate themselves with a certificate; for example, a private
>    individual with a certificate for a single telephone number might not
>    want to distribute that certificate publicly if every verifier
>    immediately knew their name.  The certification authorities issuing
>    certificates with the TN Authorization List extensions may, in
>    accordance with their policies, obscure the identity of the subject,
>    though mechanisms for doing so are outside the scope of this
>    document.
>
> 6.  Provisioning Private Keying Material
>
Another non-specification section.

>    In order for authentication services to sign calls via the procedures
>    described in [I-D.ietf-stir-rfc4474bis], they must hold a private key
>    corresponding to a certificate with authority over the calling
>    number.  This specification does not require that any particular
>    entity in a SIP deployment architecture sign requests, only that it
>    be an entity with an appropriate private key; the authentication
>    service role may be instantiated by any entity in a SIP network.  For
>    a certificate granting authority only over a particular number which
>    has been issued to an end user, for example, an end user device might
>    hold the private key and generate the signature.  In the case of a
>
>
>
>
> Peterson & Turner        Expires January 9, 2017                [Page 8]
> 
> Internet-Draft                 STIR Certs                      July 2016
>
>
>    service provider with authority over large blocks of numbers, an
>    intermediary might hold the private key and sign calls.
>
>    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.

>
> 7.  Acquiring Credentials to Verify Signatures
>
>    This specification documents multiple ways that a verifier can gain

Where is this documented?

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

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

>    [I-D.ietf-stir-rfc4474bis] provides an "info" parameter of the

Don't repeat the technical details written elsewhere.

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

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

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

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

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

"network" call?

>    Implementations of this specification are required to support the use
>    of SIP for this function (via the SUBSCRIBE/NOTIFY mechanism), as
>    well as HTTP, via the Enrollment over Secure Transport mechanisms
>    described in RFC 7030 [RFC7030].
>
>    Note well that as an optimization, a verifier may have access to a
>    service, a cache or other local store that grants access to
>    certificates for a particular telephone number.  However, there may
>    be multiple valid certificates that can sign a call setup request for
>    a telephone number, and as a consequence, there needs to be some
>    discriminator that the signer uses to identify their credentials.
>    The Identity header "info" parameter itself can serve as such a
>
>
>
>
> Peterson & Turner        Expires January 9, 2017                [Page 9]
> 
> Internet-Draft                 STIR Certs                      July 2016
>
>
>    discriminator, provided implementations use that parameter as a key
>    when accessing certificates from caches or other sources.
>
> 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".

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

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

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?

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

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

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

>      -- When all three are present: SPID, Alt SPID, and Last Alt SPID
>
>      TelephoneNumberRange ::= SEQUENCE {
>        start E164Number,
>        count INTEGER }
>
>      E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789"))
>
>    The TN Authorization List certificate extension indicates the
>    authorized phone numbers for the call setup signer.  It indicates one
>    or more blocks of telephone number entries that have been authorized
>    for use by the call setup signer.  There are three ways to identify
>    the block:
>
>
>
>
> Peterson & Turner        Expires January 9, 2017               [Page 10]
> 
> Internet-Draft                 STIR Certs                      July 2016
>
>
>    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.

>
>    2.  Telephone numbers can be listed in a range, and

What is the format of the numbers?  cite it.

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

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

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

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

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

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

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

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

>
>
> Peterson & Turner        Expires January 9, 2017               [Page 11]
> 
> Internet-Draft                 STIR Certs                      July 2016
>
>
>    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.

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

>    There are three common certificate verification mechanisms employed
>    by CAs:
>
>    1.  Certificate Revocation Lists (CRLs) [RFC5280]
>
>    2.  Online Certificate Status Protocol (OCSP) [RFC6960], and
>
>    3.  Server-based Certificate Validation Protocol (SCVP) [RFC5055].
>
>    When relying on status information, the verifier needs to obtain the
>    status information - but before that can happen, the verifier needs
>    to know where to locate it.  Placing the location of the status
>    information in the certificate makes the certificate larger, but it
>    eases the client workload.  The CRL Distribution Point certificate
>    extension includes the location of the CRL and the Authority
>    Information Access certificate extension includes the location of
>    OCSP and/or SCVP servers; both of these extensions are defined in
>    [RFC5280].  In all cases, the status information location is provided
>    in the form of an URI.
>
>    CRLs are an obviously attractive solution because they are supported
>    by every CA.  CRLs have a reputation of being quite large (10s of
>    MBytes), because CAs maintain and issue one monolithic CRL with all
>    of their revoked certificates, but CRLs do support a variety of
>    mechanisms to scope the size of the CRLs based on revocation reasons
>    (e.g., key compromise vs CA compromise), user certificates only, and
>    CA certificates only as well as just operationally deciding to keep
>    the CRLs small.  However, scoping the CRL introduces other issues
>    (i.e., does the RP have all of the CRL partitions).
>
>    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.

>    information.  Instead, one of the two "online" options is preferred.
>    Between the two, OCSP is much more widely deployed and this document
>    therefore recommends the use of OCSP in high-volume environments
>    (HVE) for validating the freshness of certificates, based on
>    [RFC6960], incorporating some (but not all) of the optimizations of
>    [RFC5019].  CRLs MUST be signed with the same algorithm as the
>    certificate.
>
>
>
>
>
>
>
> Peterson & Turner        Expires January 9, 2017               [Page 12]
> 
> Internet-Draft                 STIR Certs                      July 2016
>
>
> 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.

...

-- 

         Dave Crocker
         Brandenburg InternetWorking
         bbiw.net

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net