draft-ietf-stir-certificates-04.txt   draft-ietf-stir-certificates-05.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: November 27, 2016 Sn3rd Expires: December 27, 2016 sn3rd
May 26, 2016 June 25, 2016
Secure Telephone Identity Credentials: Certificates Secure Telephone Identity Credentials: Certificates
draft-ietf-stir-certificates-04.txt draft-ietf-stir-certificates-05.txt
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 proves authority over telephone numbers. This cryptographically proves 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 November 27, 2016. This Internet-Draft will expire on December 27, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 26 skipping to change at page 2, line 26
7. Acquiring Credentials to Verify Signatures . . . . . . . . . 8 7. Acquiring Credentials to Verify Signatures . . . . . . . . . 8
8. Verifying Certificate Scope with TN Authorization List . . . 9 8. Verifying Certificate Scope with TN Authorization List . . . 9
9. Certificate Freshness and Revocation . . . . . . . . . . . . 11 9. Certificate Freshness and Revocation . . . . . . . . . . . . 11
9.1. Choosing a Verification Method . . . . . . . . . . . . . 11 9.1. Choosing a Verification Method . . . . . . . . . . . . . 11
9.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 12 9.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 12
9.2.1. OCSP Extension Specification . . . . . . . . . . . . 13 9.2.1. OCSP Extension Specification . . . . . . . . . . . . 13
9.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 14 9.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
13. Informative References . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 19 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The STIR problem statement [RFC7340] identifies the primary enabler The STIR problem statement [RFC7340] identifies the primary enabler
of robocalling, vishing, swatting and related attacks as the of robocalling, vishing, swatting and related attacks as the
capability to impersonate a calling party number. The starkest capability to impersonate a calling party number. The starkest
examples of these attacks are cases where automated callees on the examples of these attacks are cases where automated callees on the
PSTN rely on the calling number as a security measure, for example to PSTN rely on the calling number as a security measure, for example to
access a voicemail system. Robocallers use impersonation as a means access a voicemail system. Robocallers use impersonation as a means
of obscuring identity; while robocallers can, in the ordinary PSTN, of obscuring identity; while robocallers can, in the ordinary PSTN,
skipping to change at page 6, line 5 skipping to change at page 6, line 4
curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447] curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447]
Section 8.2) for certificate signatures. Implementers are Section 8.2) for certificate signatures. Implementers are
advised that RS256 is mandated only as a transitional mechanism, advised that RS256 is mandated only as a transitional mechanism,
due to its widespread use in existing PKI, but we anticipate that due to its widespread use in existing PKI, but we anticipate that
this mechanism will eventually be deprecated. this mechanism will eventually be deprecated.
5. Finally, note that all certificates compliant with this 5. Finally, note that all certificates compliant with this
specification MUST provide cryptographic keying material specification MUST provide cryptographic keying material
sufficient to generate the ECDSA P-256 signatures necessary to sufficient to generate the ECDSA P-256 signatures necessary to
support the ES256 hashed signatures required by PASSporT support the ES256 hashed signatures required by PASSporT
[I-D.ietf-stir-passport], which in turn follows JWT [RFC7519].
[I-D.ietf-stir-passport], which in turn follows JSON Web Token
(JWT) [RFC7519].
5. Enrollment and Authorization using the TN Authorization List 5. Enrollment and Authorization using the TN Authorization List
This document assumes a threefold model for certificate enrollment This document assumes a threefold model for certificate enrollment
when using the TN Authorization List extension. when using the TN Authorization List extension.
The first enrollment model is one where the certification authority The first enrollment model is one where the certification authority
acts in concert with national numbering authorities to issue acts in concert with national numbering authorities to issue
credentials to those parties to whom numbers are assigned. In the credentials to those parties to whom numbers are assigned. In the
United States, for example, telephone number blocks are assigned to United States, for example, telephone number blocks are assigned to
skipping to change at page 9, line 37 skipping to change at page 9, line 37
identity, local policy always determines the circumstances under identity, local policy always determines the circumstances under
which any particular subject may be trusted, but the purpose of the which any particular subject may be trusted, but the purpose of the
TN Authorization List extension particular is to allow a verifier to TN Authorization List extension particular is to allow a verifier to
ascertain when the certification authority has designed that the ascertain when the certification authority has designed that the
subject has authority over a particular telephone number or number subject has authority over a particular telephone number or number
range. range.
The Telephony Number (TN) Authorization List certificate extension is The Telephony Number (TN) Authorization List certificate extension is
identified by the following object identifier: identified by the following object identifier:
id-ce-TNAuthList OBJECT IDENTIFIER ::= { TBD } id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD }
The TN Authorization List certificate extension has the following The TN Authorization List certificate extension has the following
syntax: syntax:
TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNAuthorization TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNAuthorization
TNAuthorization ::= SEQUENCE SIZE (1..MAX) OF TNEntry
TNEntry ::= CHOICE {
spid ServiceProviderIdentifierList,
range TelephoneNumberRange,
one E164Number }
ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF
OCTET STRING
-- When all three are present: SPID, Alt SPID, and Last Alt SPID TNAuthorization ::= SEQUENCE SIZE (1..MAX) OF TNEntry
TelephoneNumberRange ::= SEQUENCE { TNEntry ::= CHOICE {
spid [0] ServiceProviderIdentifierList,
range [1] TelephoneNumberRange,
one E164Number }
start E164Number, ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF
OCTET STRING
count INTEGER } -- When all three are present: SPID, Alt SPID, and Last Alt SPID
E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789")) TelephoneNumberRange ::= SEQUENCE {
start E164Number,
count INTEGER }
[TBD- do we really need to do IA5String? The alternative would be E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789"))
UTF8String, e.g.: UTF8String (SIZE (1..15)) (FROM ("0123456789")) ]
The TN Authorization List certificate extension indicates the The TN Authorization List certificate extension indicates the
authorized phone numbers for the call setup signer. It indicates one authorized phone numbers for the call setup signer. It indicates one
or more blocks of telephone number entries that have been authorized or more blocks of telephone number entries that have been authorized
for use by the call setup signer. There are three ways to identify for use by the call setup signer. There are three ways to identify
the block: 1) a Service Provider Identifier (SPID) can be used to the block:
indirectly name all of the telephone numbers associated with that
service provider, 2) telephone numbers can be listed in a range, and 1. A Service Provider Identifier (SPID) can be used to indirectly
3) a single telephone number can be listed. name all of the telephone numbers associated with that service
provider,
2. Telephone numbers can be listed in a range, and
3. A single telephone number can be listed.
Note that because large-scale service providers may want to associate Note that because large-scale service providers may want to associate
many numbers, possibly millions of numbers, with a particular many numbers, possibly millions of numbers, with a particular
certificate, optimizations are required for those cases to prevent certificate, optimizations are required for those cases to prevent
certificate size from becoming unmanageable. In these cases, the TN certificate size from becoming unmanageable. In these cases, the TN
Authorization List may be given by reference rather than by value, Authorization List may be given by reference rather than by value,
through the presence of a separate certificate extension that permits through the presence of a separate certificate extension that permits
verifiers to either securely download the list of numbers associated verifiers to either securely download the list of numbers associated
with a certificate, or to verify that a single number is under the with a certificate, or to verify that a single number is under the
authority of this certificate. This optimization will be detailed in authority of this certificate. This optimization will be detailed in
skipping to change at page 11, line 30 skipping to change at page 11, line 24
Dynamic changes to number assignments can occur due to number Dynamic changes to number assignments can occur due to number
portability, for example. So even if a verifier has a valid cached portability, for example. So even if a verifier has a valid cached
certificate for a telephone number (or a range containing the certificate for a telephone number (or a range containing the
number), the verifier must determine that the entity that signed is number), the verifier must determine that the entity that signed is
still a proper authority for that number. still a proper authority for that number.
To verify the status of the certificate, the verifier needs to To verify the status of the certificate, the verifier needs to
acquire the certificate if necessary (via the methods described in acquire the certificate if necessary (via the methods described in
Section 7), and then would need to either: Section 7), and then would need to either:
Rely on short-lived certificates and not check the certificate's (a) Rely on short-lived certificates and not check the certificate's
status, or status, or
Rely on status information from the authority (b) Rely on status information from the authority
The tradeoff between short lived certificates and using status The tradeoff between short lived certificates and using status
information is the former's burden is on the front end (i.e., 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., enrollment) and the latter's burden is on the back end (i.e.,
verification). Both impact call setup time, but it is assumed that verification). Both impact call setup time, but it is assumed that
performing enrollment for each call is more of an impact that using performing enrollment for each call is more of an impact that using
status information. This document therefore recommends relying on status information. This document therefore recommends relying on
status information. status information.
9.1. Choosing a Verification Method 9.1. Choosing a Verification Method
There are three common certificate verification mechanisms employed There are three common certificate verification mechanisms employed
by CAs: by CAs:
Certificate Revocation Lists (CRLs) [RFC5280] 1. Certificate Revocation Lists (CRLs) [RFC5280]
Online Certificate Status Protocol (OCSP) [RFC6960], and 2. Online Certificate Status Protocol (OCSP) [RFC6960], and
Server-based Certificate Validation Protocol (SCVP) [RFC5055].
3. Server-based Certificate Validation Protocol (SCVP) [RFC5055].
When relying on status information, the verifier needs to obtain the When relying on status information, the verifier needs to obtain the
status information - but before that can happen, the verifier needs status information - but before that can happen, the verifier needs
to know where to locate it. Placing the location of the status to know where to locate it. Placing the location of the status
information in the certificate makes the certificate larger, but it information in the certificate makes the certificate larger, but it
eases the client workload. The CRL Distribution Point certificate eases the client workload. The CRL Distribution Point certificate
extension includes the location of the CRL and the Authority extension includes the location of the CRL and the Authority
Information Access certificate extension includes the location of Information Access certificate extension includes the location of
OCSP and/or SCVP servers; both of these extensions are defined in OCSP and/or SCVP servers; both of these extensions are defined in
[RFC5280]. In all cases, the status information location is provided [RFC5280]. In all cases, the status information location is provided
skipping to change at page 14, line 7 skipping to change at page 14, line 5
The OCSP TNQuery extension is included as one of the The OCSP TNQuery extension is included as one of the
requestExtensions in requests. It may also appear in the requestExtensions in requests. It may also appear in the
responseExtensions. When an OCSP server includes a number in the responseExtensions. When an OCSP server includes a number in the
responseExtensions, this informs the client that the certificate is responseExtensions, this informs the client that the certificate is
still valid for the number that appears in the TNQuery extension still valid for the number that appears in the TNQuery extension
field. If the TNQuery is absent from a response to a query field. If the TNQuery is absent from a response to a query
containing a TNQuery in its requestExtensions, then the server is not containing a TNQuery in its requestExtensions, then the server is not
able to validate that the number is still in the scope of authority able to validate that the number is still in the scope of authority
of the certificate. of the certificate.
id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD } id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD }
TNQuery ::= E164Number TNQuery ::= E164Number
Note that HVE OCSP profile [RFC5019] prohibits the use of per-request Note that HVE OCSP profile [RFC5019] prohibits the use of per-request
extensions. As it is anticipated that STIR will use OCSP in a high- extensions. As it is anticipated that STIR will use OCSP in a high-
volume environment, many of the optimizations recommended by HVE are volume environment, many of the optimizations recommended by HVE are
desirable for the STIR environment. This document therefore uses desirable for the STIR environment. This document therefore uses
these extensions in a baseline OCSP environment with some HVE these extensions in a baseline OCSP environment with some HVE
optimizations. [More TBD] optimizations. [More TBD]
Ideally, once a certificate has been acquired by a verifier, some Ideally, once a certificate has been acquired by a verifier, some
sort of asynchronous mechanism could notify and update the verifier sort of asynchronous mechanism could notify and update the verifier
skipping to change at page 15, line 12 skipping to change at page 15, line 7
designates an OID to identify the accessMethod and an accessLocation, designates an OID to identify the accessMethod and an accessLocation,
which would most likely be a URI. A verifier would then follow the which would most likely be a URI. A verifier would then follow the
URI to ascertain whether the list of TNs authorized for use by the URI to ascertain whether the list of TNs authorized for use by the
caller. caller.
HTTPS is the most obvious candidate for a protocol to be used for HTTPS is the most obvious candidate for a protocol to be used for
fetching the list of telephone number associated with a particular fetching the list of telephone number associated with a particular
certificate. This document defines a new AIA accessMethod, called certificate. This document defines a new AIA accessMethod, called
"id-ad-stir-tn", which uses the following AIA OID: "id-ad-stir-tn", which uses the following AIA OID:
id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD } id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD }
When the "id-ad-stir-tn" accessMethod is used, the accessLocation When the "id-ad-stir-tn" accessMethod is used, the accessLocation
MUST be an HTTPS URI. The document returned by dereferencing that MUST be an HTTPS URI. The document returned by dereferencing that
URI will contain the complete TN Authorization List (see Section 8) URI will contain the complete TN Authorization List (see Section 8)
for the certificate. for the certificate.
Delivering the entire list of telephone numbers associated with a Delivering the entire list of telephone numbers associated with a
particular certificate will divulge to STIR verifiers information particular certificate will divulge to STIR verifiers information
about telephone numbers other than the one associated with the about telephone numbers other than the one associated with the
particular call that the verifier is checking. In some environments, particular call that the verifier is checking. In some environments,
skipping to change at page 15, line 36 skipping to change at page 15, line 31
10. Acknowledgments 10. Acknowledgments
Russ Housley, Brian Rosen, Cullen Jennings and Eric Rescorla provided Russ Housley, Brian Rosen, Cullen Jennings and Eric Rescorla provided
key input to the discussions leading to this document. key input to the discussions leading to this document.
11. IANA Considerations 11. IANA Considerations
This document makes use of object identifiers for the TN Certificate This document makes use of object identifiers for the TN Certificate
Extension defined in Section 8, TN-HVE OCSP extension in Extension defined in Section 8, TN-HVE OCSP extension in
Section 9.2.1, and the TN by reference AIA access descriptor defined Section 9.2.1, the TN by reference AIA access descriptor defined in
in Section 9.3. It therefore requests that the IANA make the Section 9.3, and the ASN.1 module identifier defined in Appendix A.
following assignments: It therefore requests that the IANA make the following assignments:
- TN Certificate Extension in the SMI Security for PKIX o TN Certificate Extension in the SMI Security for PKIX Certificate
Certificate Extension registry: http://www.iana.org/assignments/ Extension registry: http://www.iana.org/assignments/smi-numbers/
smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1 smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1
- TN-HVE OCSP extension in the SMI Security for PKIX Online o TN-HVE OCSP extension in the SMI Security for PKIX Online
Certificate Status Protocol (OCSP) registry: Certificate Status Protocol (OCSP) registry:
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-
numbers-1.3.6.1.5.5.7.48.1 numbers-1.3.6.1.5.5.7.48.1
- TNS by reference access descriptor in the SMI Security for PKIX
o TNS by reference access descriptor in the SMI Security for PKIX
Access Descriptor registry: http://www.iana.org/assignments/smi- Access Descriptor registry: http://www.iana.org/assignments/smi-
numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.48 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.48
o The TN ASN.1 module in SMI Security for PKIX Module Identifier
registry: http://www.iana.org/assignments/smi-numbers/smi-
numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0
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 [RFC3280], in particular its certificate security and practices, see [RFC5280], in particular its
Security Considerations. Security Considerations.
13. Informative References 13. References
[I-D.ietf-stir-passport] [I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Persona Assertion Token", Wendt, C. and J. Peterson, "Persona Assertion Token",
draft-ietf-stir-passport-02 (work in progress), May 2016. draft-ietf-stir-passport-03 (work in progress), June 2016.
[I-D.ietf-stir-rfc4474bis] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-09 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-09
(work in progress), May 2016. (work in progress), May 2016.
[I-D.peterson-sipping-retarget]
Peterson, J., "Retargeting and Security in SIP: A
Framework and Requirements", draft-peterson-sipping-
retarget-00 (work in progress), February 2005.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
<http://www.rfc-editor.org/info/rfc2046>. <http://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<http://www.rfc-editor.org/info/rfc2392>. <http://www.rfc-editor.org/info/rfc2392>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
DOI 10.17487/RFC3263, June 2002,
<http://www.rfc-editor.org/info/rfc3263>.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
DOI 10.17487/RFC3280, April 2002,
<http://www.rfc-editor.org/info/rfc3280>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>. 2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
the Elliptic Curve Digital Signature Algorithm (ECDSA)", the Elliptic Curve Digital Signature Algorithm (ECDSA)",
RFC 4754, DOI 10.17487/RFC4754, January 2007, RFC 4754, DOI 10.17487/RFC4754, January 2007,
<http://www.rfc-editor.org/info/rfc4754>. <http://www.rfc-editor.org/info/rfc4754>.
skipping to change at page 17, line 48 skipping to change at page 17, line 16
Polk, "Server-Based Certificate Validation Protocol Polk, "Server-Based Certificate Validation Protocol
(SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007, (SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007,
<http://www.rfc-editor.org/info/rfc5055>. <http://www.rfc-editor.org/info/rfc5055>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<http://www.rfc-editor.org/info/rfc5912>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010, DOI 10.17487/RFC5958, August 2010,
<http://www.rfc-editor.org/info/rfc5958>. <http://www.rfc-editor.org/info/rfc5958>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919, for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013, DOI 10.17487/RFC6919, April 2013,
<http://www.rfc-editor.org/info/rfc6919>. <http://www.rfc-editor.org/info/rfc6919>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
skipping to change at page 18, line 26 skipping to change at page 17, line 46
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961, Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>. <http://www.rfc-editor.org/info/rfc6961>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<http://www.rfc-editor.org/info/rfc7030>. <http://www.rfc-editor.org/info/rfc7030>.
[RFC7299] Housley, R., "Object Identifier Registry for the PKIX
Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014,
<http://www.rfc-editor.org/info/rfc7299>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements", Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014, RFC 7340, DOI 10.17487/RFC7340, September 2014,
<http://www.rfc-editor.org/info/rfc7340>. <http://www.rfc-editor.org/info/rfc7340>.
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model",
RFC 7375, DOI 10.17487/RFC7375, October 2014, RFC 7375, DOI 10.17487/RFC7375, October 2014,
<http://www.rfc-editor.org/info/rfc7375>. <http://www.rfc-editor.org/info/rfc7375>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
skipping to change at page 19, line 20 skipping to change at page 18, line 37
Technology - Abstract Syntax Notation One: Technology - Abstract Syntax Notation One:
Parameterization of ASN.1 Specifications", ITU-T X.683, Parameterization of ASN.1 Specifications", ITU-T X.683,
ISO/IEC 8824-4:2002, 2002. ISO/IEC 8824-4:2002, 2002.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
This appendix provides the normative ASN.1 [X.680] definitions for This appendix provides the normative ASN.1 [X.680] definitions for
the structures described in this specification using ASN.1, as the structures described in this specification using ASN.1, as
defined in [X.680] through [X.683]. defined in [X.680] through [X.683].
TBD This ASN.1 module imports ASN.1 from [RFC5912].
TN-Module {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-tn-module(TBD) }
DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS
id-ad, id-ad-ocsp -- From [RFC5912]
FROM PKIX1Explicit-2009 {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) }
id-ce -- From [RFC5912]
FROM PKIX1Implicit-2009 {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) }
EXTENSION -- From [RFC5912]
FROM PKIX-CommonTypes-2009 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) }
;
-- TN Entry Certificate Extension
ext-tnAuthList EXTENSION ::= {
SYNTAX TNAuthorizationList IDENTIFIED BY id-ce-TNAuthList }
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
-- 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"))
-- TN OCSP Extension
re-ocsp-tn-query EXTENSION ::= {
SYNTAX TNQuery IDENTIFIED BY id-pkix-ocsp-stir-tn }
TNQuery ::= E164Number
-- TN Access Descriptor
id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD }
--
-- Object Identifiers
--
id-pkix-ocsp OBJECT IDENTIFIER ::= id-ad-ocsp
id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD }
id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD }
END
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
Sean Turner Sean Turner
Sn3rd sn3rd
Email: sean@sn3rd.com Email: sean@sn3rd.com
 End of changes. 35 change blocks. 
87 lines changed or deleted 137 lines changed or added

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