draft-ietf-acme-authority-token-tnauthlist-04.txt   draft-ietf-acme-authority-token-tnauthlist-05.txt 
Network Working Group C. Wendt Network Working Group C. Wendt
Internet-Draft D. Hancock Internet-Draft D. Hancock
Intended status: Standards Track Comcast Intended status: Standards Track Comcast
Expires: April 2, 2020 M. Barnes Expires: May 7, 2020 M. Barnes
iconectiv Independent
J. Peterson J. Peterson
Neustar Inc. Neustar Inc.
September 30, 2019 November 04, 2019
TNAuthList profile of ACME Authority Token TNAuthList profile of ACME Authority Token
draft-ietf-acme-authority-token-tnauthlist-04 draft-ietf-acme-authority-token-tnauthlist-05
Abstract Abstract
This document defines a profile of the Automated Certificate This document defines a profile of the Automated Certificate
Management Environment (ACME) Authority Token for the automated and Management Environment (ACME) Authority Token for the automated and
authorized creation of certificates for VoIP Telephone Providers to authorized creation of certificates for VoIP Telephone Providers to
support Secure Telephony Identity (STI) using the TNAuthList defined support Secure Telephony Identity (STI) using the TNAuthList defined
by STI certificates. by STI certificates.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 2, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 27 skipping to change at page 2, line 27
5.2. "exp" claim . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. "exp" claim . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. "jti" claim . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. "jti" claim . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. "atc" claim . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. "atc" claim . . . . . . . . . . . . . . . . . . . . . . . 8
5.5. Acquiring the token from the Token Authority . . . . . . 9 5.5. Acquiring the token from the Token Authority . . . . . . 9
5.6. Token Authority Responsibilities . . . . . . . . . . . . 10 5.6. Token Authority Responsibilities . . . . . . . . . . . . 10
5.7. Scope of the TNAuthList token authority . . . . . . . . . 10 5.7. Scope of the TNAuthList token authority . . . . . . . . . 10
6. Validating the TNAuthList Authority Token . . . . . . . . . . 10 6. Validating the TNAuthList Authority Token . . . . . . . . . . 10
7. Usage Considerations . . . . . . . . . . . . . . . . . . . . 11 7. Usage Considerations . . . . . . . . . . . . . . . . . . . . 11
7.1. Large number of Non-contiguous TNAuthList values . . . . 11 7.1. Large number of Non-contiguous TNAuthList values . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
[RFC8555] is a mechanism for automating certificate management on the [RFC8555] is a mechanism for automating certificate management on the
Internet. It enables administrative entities to prove effective Internet. It enables administrative entities to prove effective
skipping to change at page 3, line 22 skipping to change at page 3, line 22
(TNs), or Telephone Number ranges (TN ranges). Typically, these (TNs), or Telephone Number ranges (TN ranges). Typically, these
identifiers have been assigned to a Communications Service Provider identifiers have been assigned to a Communications Service Provider
(CSP) that is authorized to use a set of telephone numbers or (CSP) that is authorized to use a set of telephone numbers or
telephone number ranges in association with a Service Provider Code telephone number ranges in association with a Service Provider Code
as defined in [RFC8226]. The SPC is a unique code or string managed as defined in [RFC8226]. The SPC is a unique code or string managed
by a national regulatory body that has the authority over those code- by a national regulatory body that has the authority over those code-
to-CSP associations. to-CSP associations.
This document will also incorporate the ability for a telephone This document will also incorporate the ability for a telephone
authority to authorize the creation of CA types of certificates for authority to authorize the creation of CA types of certificates for
delegation as defined in [I-D.peterson-stir-cert-delegation]. delegation as defined in [I-D.ietf-stir-cert-delegation].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. ACME new-order identifiers for TNAuthList 3. ACME new-order identifiers for TNAuthList
In [RFC8555], Section 7.4 defines the procedure that an ACME client In [RFC8555], Section 7.4 defines the procedure that an ACME client
skipping to change at page 7, line 5 skipping to change at page 7, line 5
URL representing the Token Authority that will provide the TNAuthList URL representing the Token Authority that will provide the TNAuthList
Authority Token response to the challenge. If the "token-authority" Authority Token response to the challenge. If the "token-authority"
parameter is not present, then the ACME client MUST identify the parameter is not present, then the ACME client MUST identify the
Token Authority based on locally configured information or local Token Authority based on locally configured information or local
policies. policies.
The ACME client MUST respond to the challenge by posting the The ACME client MUST respond to the challenge by posting the
TNAuthList Authority Token to the challenge URL identified in the TNAuthList Authority Token to the challenge URL identified in the
returned ACME authorization object, an example of which follows. returned ACME authorization object, an example of which follows.
POST /acme/authz/asdf/0 HTTP/1.1 POST /acme/authz/asdf/0 HTTP/1.1
Host: boulder.example.com Host: boulder.example.com
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
"kid": "https://example.com/acme/acct/1", "kid": "https://example.com/acme/acct/1",
"nonce": "Q_s3MWoqT05TrdkM2MTDcw", "nonce": "Q_s3MWoqT05TrdkM2MTDcw",
"url": "https://boulder.example.com/acme/authz/asdf/0" "url": "https://boulder.example.com/acme/authz/asdf/0"
}), }),
"payload": base64url({ "payload": base64url({
"atc": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE" "atc": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"
}), }),
"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
} }
The specifics of the construction of the TNAuthList specific "atc" The specifics of the construction of the TNAuthList specific "atc"
token is defined in the next section. token is defined in the next section.
5. TNAuthList Authority Token 5. TNAuthList Authority Token
The Telephone Number Authority List Authority Token (TNAuthList The Telephone Number Authority List Authority Token (TNAuthList
Authority Token) is an extension of the ACME Authority Token defined Authority Token) is an extension of the ACME Authority Token defined
in [I-D.ietf-acme-authority-token]. in [I-D.ietf-acme-authority-token].
skipping to change at page 8, line 27 skipping to change at page 8, line 27
token [I-D.ietf-acme-authority-token] defined by this document. token [I-D.ietf-acme-authority-token] defined by this document.
o a "tkvalue" key with a string value equal to the TNAuthList o a "tkvalue" key with a string value equal to the TNAuthList
identifier "value" string which MUST contain the base64 encoding identifier "value" string which MUST contain the base64 encoding
of the TN Authorization List certificate extension ASN.1 object. of the TN Authorization List certificate extension ASN.1 object.
"tkvalue" is a required key and MUST be included. "tkvalue" is a required key and MUST be included.
o a "ca" key with a boolean value set to either true when the o a "ca" key with a boolean value set to either true when the
requested certificate is allowed to be a CA cert for delegation requested certificate is allowed to be a CA cert for delegation
uses or false when the requested certificate MUST NOT be a CA cert uses or false when the requested certificate MUST NOT be a CA cert
and only an end-entity certificate. "ca" is an optional key. and only an end-entity certificate. "ca" is an optional key, if it
not included the "ca" value is considered false by default.
o a "fingerprint" key with a fingerprint value equal to the o a "fingerprint" key with a fingerprint value equal to the
fingerprint, as defined in [RFC4949], of the ACME account fingerprint, as defined in [RFC4949], of the ACME account
credentials. Specifically, the fingerprint value is a secure one- credentials. Specifically, the fingerprint value is a secure one-
way hash of the Distinguished Encoding Rules (DER) form of the way hash of the Distinguished Encoding Rules (DER) form of the
public key corresponding to the key pair the SP used to create the public key corresponding to the key pair the SP used to create the
account with the ACME server. The fingerprint value consists of account with the ACME server. The fingerprint value consists of
the name of the hash function, which shall be 'SHA256' for this the name of the hash function, which shall be 'SHA256' for this
specification, followed by the hash value itself. The hash value specification, followed by the hash value itself. The hash value
is represented as a sequence of uppercase hexadecimal bytes, is represented as a sequence of uppercase hexadecimal bytes,
skipping to change at page 11, line 44 skipping to change at page 11, line 44
unbounded set of combinations. It's possible that a complex non- unbounded set of combinations. It's possible that a complex non-
contiguous set of telephone numbers are being managed by a CSP. Best contiguous set of telephone numbers are being managed by a CSP. Best
practice may be simply to split a set of non-contiguous numbers under practice may be simply to split a set of non-contiguous numbers under
management into multiple STI certificates to represent the various management into multiple STI certificates to represent the various
contiguous parts of the greater non-contiguous set of TNs, contiguous parts of the greater non-contiguous set of TNs,
particularly if length of the set of values in identifier object particularly if length of the set of values in identifier object
grows to be too large. grows to be too large.
8. Security Considerations 8. Security Considerations
TBD The token represented by this document obviously has the credentials
to represent the scope of a telephone number, a block of telephone
numbers, or an entire set of telephone numbers represented by a SPC.
The creation, transport, and any storage of this token MUST follow
the strictest of security best practices beyond the recommendations
of the use of encrypted transport protocols in this document to
protect it from getting in the hands of bad actors with illegitimate
intent to impersonate telephone numbers.
9. IANA Considerations 9. IANA Considerations
This document requests the addition of a new identifier object type This document requests the addition of a new identifier object type
that can be present in the identifier field of the ACME authorization that can be present in the identifier field of the ACME authorization
object defined in [RFC8555]. object defined in [RFC8555].
+------------+-----------+ +------------+-----------+
| Label | Reference | | Label | Reference |
+------------+-----------+ +------------+-----------+
skipping to change at page 12, line 25 skipping to change at page 12, line 31
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-acme-authority-token] [I-D.ietf-acme-authority-token]
Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME
Challenges Using an Authority Token", draft-ietf-acme- Challenges Using an Authority Token", draft-ietf-acme-
authority-token-03 (work in progress), March 2019. authority-token-03 (work in progress), March 2019.
[I-D.peterson-stir-cert-delegation] [I-D.ietf-stir-cert-delegation]
Peterson, J., "STIR Certificate Delegation", draft- Peterson, J., "STIR Certificate Delegation", draft-ietf-
peterson-stir-cert-delegation-00 (work in progress), March stir-cert-delegation-00 (work in progress), July 2019.
2019.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>. <https://www.rfc-editor.org/info/rfc2616>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
skipping to change at page 14, line 21 skipping to change at page 14, line 21
USA USA
Email: chris-ietf@chriswendt.net Email: chris-ietf@chriswendt.net
David Hancock David Hancock
Comcast Comcast
Email: davidhancock.ietf@gmail.com Email: davidhancock.ietf@gmail.com
Mary Barnes Mary Barnes
iconectiv Independent
Email: mary.ietf.barnes@gmail.com Email: mary.ietf.barnes@gmail.com
Jon Peterson Jon Peterson
Neustar Inc. Neustar Inc.
1800 Sutter St Suite 570 1800 Sutter St Suite 570
Concord, CA 94520 Concord, CA 94520
US US
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
 End of changes. 12 change blocks. 
29 lines changed or deleted 36 lines changed or added

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