draft-ietf-stir-certificates-15.txt   draft-ietf-stir-certificates-16.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Standards Track S. Turner Intended status: Standards Track S. Turner
Expires: May 20, 2018 sn3rd Expires: June 12, 2018 sn3rd
November 16, 2017 December 9, 2017
Secure Telephone Identity Credentials: Certificates Secure Telephone Identity Credentials: Certificates
draft-ietf-stir-certificates-15 draft-ietf-stir-certificates-16
Abstract Abstract
In order to prevent the impersonation of telephone numbers on the In order to prevent the impersonation of telephone numbers on the
Internet, some kind of credential system needs to exist that Internet, some kind of credential system needs to exist that
cryptographically asserts authority over telephone numbers. This cryptographically asserts authority over telephone numbers. This
document describes the use of certificates in establishing authority document describes the use of certificates in establishing authority
over telephone numbers, as a component of a broader architecture for over telephone numbers, as a component of a broader architecture for
managing telephone numbers as identities in protocols like SIP. managing telephone numbers as identities in protocols like SIP.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 20, 2018. This Internet-Draft will expire on June 12, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 12 skipping to change at page 6, line 12
described in Section 9 identifies the scope of authority of the described in Section 9 identifies the scope of authority of the
certificate. certificate.
4. The cryptographic algorithms required to validate the 4. The cryptographic algorithms required to validate the
credentials: for this specification, that means the signature credentials: for this specification, that means the signature
algorithms used to sign certificates. This specification algorithms used to sign certificates. This specification
REQUIRES that implementations support both the Elliptic Curve REQUIRES that implementations support both the Elliptic Curve
Digital Signature Algorithm (ECDSA) with the P-256 curve (see Digital Signature Algorithm (ECDSA) with the P-256 curve (see
[DSS]) and RSA PKCS #1 v1.5 ("PKCS" stands for "Public-Key [DSS]) and RSA PKCS #1 v1.5 ("PKCS" stands for "Public-Key
Cryptography Standards") (see [RFC8017], Section 8.2) for Cryptography Standards") (see [RFC8017], Section 8.2) for
certificate signatures. Implementers are advised that RS256 is certificate signatures. Implementers are advised that the latter
mandated only as a transitional mechanism, due to its widespread algorithm is mandated only as a transitional mechanism, due to
use in existing PKIs, but we anticipate that this mechanism will its widespread use in existing PKIs, but we anticipate that this
eventually be deprecated. mechanism will eventually be deprecated.
5. Finally, note that all certificates compliant with this 5. Finally, note that all certificates compliant with this
specification: specification:
* MUST provide cryptographic keying material sufficient to * MUST provide cryptographic keying material sufficient to
generate the ECDSA using P-256 and SHA-256 signatures generate the ECDSA using P-256 and SHA-256 signatures
necessary to support the ES256 hashed signatures required by necessary to support the ES256 hashed signatures required by
PASSporT [RFC8225], which in turn follows the JSON Web Token PASSporT [RFC8225], which in turn follows the JSON Web Token
(JWT) [RFC7519]. (JWT) [RFC7519].
skipping to change at page 16, line 17 skipping to change at page 16, line 17
89 id-mod-tn-module 89 id-mod-tn-module
11.2. Media Type Registrations 11.2. Media Type Registrations
Type name: application Type name: application
Subtype name: tnauthlist Subtype name: tnauthlist
Required parameters: None. Required parameters: None.
Optional parameters: None. Optional parameters: None.
Encoding considerations: Binary. Encoding considerations: Binary.
Security considerations: See Section 12 of this specification. Security considerations: See Section 12 of [RFCTBD].
Interoperability considerations: Interoperability considerations:
The TN Authorization List inside this media type MUST be The TN Authorization List inside this media type MUST be
DER-encoded TNAuthorizationList. DER-encoded TNAuthorizationList.
Published specification: This specification. Published specification: [RFCTBD].
Applications that use this media type: Applications that use this media type:
Issuers and relying parties of secure telephone identity
certificates, to limit the subject's authority to a
particular telephone number or telephone number range.
Additional information: Additional information:
Magic number(s): None Magic number(s): None
File extension(s): None File extension(s): None
Macintosh File Type Code(s): None Macintosh File Type Code(s): None
Person & email address to contact for further information: Person & email address to contact for further information:
Jon Peterson <jon.peterson@team.neustar> Jon Peterson <jon.peterson@team.neustar>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author: Sean Turner <sean@sn3rd.com> Author: Sean Turner <sean@sn3rd.com>
Change controller: The IESG <iesg@ietf.org> Change controller: The IESG <iesg@ietf.org>
[RFC editor's instruction: Please replace RFCTBD with the
RFC number when this document is published.]
12. Security Considerations 12. Security Considerations
This document is entirely about security. For further information on This document is entirely about security. For further information on
certificate security and practices, see [RFC5280], in particular its certificate security and practices, see [RFC5280], in particular its
Security Considerations section. Security Considerations section.
If a certification authority issues a certificate attesting authority If a certification authority issues a certificate attesting authority
over many telephone numbers, the TNAuthList element can divulge to over many telephone numbers, the TNAuthList element can divulge to
relying parties extraneous telephone numbers associated with the relying parties extraneous telephone numbers associated with the
certificate which have no bearing on any given call in progress. The certificate which have no bearing on any given call in progress. The
skipping to change at page 17, line 9 skipping to change at page 17, line 15
databases, potentially the set of numbers associated with that SPC. databases, potentially the set of numbers associated with that SPC.
While these practices may not cause concern in some environments, in While these practices may not cause concern in some environments, in
other scenarios alternative approaches could minimize the data other scenarios alternative approaches could minimize the data
revealed to relying parties. For example, a service provider with revealed to relying parties. For example, a service provider with
authority over a large block of numbers could generate short-lived authority over a large block of numbers could generate short-lived
certificates for individual TNs that are not so easily linked to the certificates for individual TNs that are not so easily linked to the
service provider or any other numbers that the service provider service provider or any other numbers that the service provider
controls. Optimizations to facilitate acquiring short-lived controls. Optimizations to facilitate acquiring short-lived
certificates are a potential area of future work for STIR. certificates are a potential area of future work for STIR.
The TN Authorization List returned through a dereferenced URI is
served over HTTPS; the TN Authorization List is therefore protected
in transit. But, the TN Authorization List served is not a signed
object and therefore the server is trusted to faithfully return the
TN Authorization List provided to it by the list generator.
13. References 13. References
13.1. Normative References 13.1. Normative References
[ATIS-0300251] [ATIS-0300251]
ATIS Recommendation 0300251, "Codes for Identification of ATIS Recommendation 0300251, "Codes for Identification of
Service Providers for Information Exchange", 2007. Service Providers for Information Exchange", 2007.
[DSS] National Institute of Standards and Technology, U.S. [DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard Department of Commerce, "Digital Signature Standard
 End of changes. 9 change blocks. 
10 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/