draft-ietf-sidrops-signed-tal-04.txt   draft-ietf-sidrops-signed-tal-05.txt 
Network Working Group C. Martinez Network Working Group C. Martinez
Internet-Draft LACNIC Internet-Draft LACNIC
Intended status: Standards Track G. Michaelson Intended status: Standards Track G. Michaelson
Expires: July 10, 2020 APNIC Expires: July 19, 2020 T. Harrison
APNIC
T. Bruijnzeels T. Bruijnzeels
NLnet Labs NLnet Labs
R. Austein R. Austein
Dragon Research Labs Dragon Research Labs
January 7, 2020 January 16, 2020
RPKI Signed Object for Trust Anchor Keys RPKI Signed Object for Trust Anchor Keys
draft-ietf-sidrops-signed-tal-04 draft-ietf-sidrops-signed-tal-05
Abstract Abstract
Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by A Trust Anchor Locator (TAL) [I-D.ietf-sidrops-https-tal] is used by
Relying Parties in the RPKI to locate and validate Trust Anchor Relying Parties (RP) in the RPKI to locate and validate a Trust
certificates used in RPKI validation. This document defines an RPKI Anchor (TA) CA certificate used in RPKI validation. This document
signed object for Trust Anchor Keys (TAK), that can be used by Trust defines an RPKI signed object for a set of Trust Anchor Keys (TAK),
Anchors to signal their set of current keys and the location(s) of that can be used by TA creators and publishers to signal their set of
the accompanying CA certiifcates to Relying Parties, as well as current keys and the location(s) of the accompanying CA certificates
changes to this set in the form of revoked keys and new keys, in to RPs, as well as changes to this set in the form of revoked keys
order to support both planned and unplanned key rolls without and new keys, in order to support both planned and unplanned key
impacting RPKI validation. rolls without impacting RPKI validation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 10, 2020. This Internet-Draft will expire on July 19, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 43 skipping to change at page 2, line 48
7.3.1. Planned Direction Roll . . . . . . . . . . . . . . . 11 7.3.1. Planned Direction Roll . . . . . . . . . . . . . . . 11
7.3.2. Unplanned Direction Roll . . . . . . . . . . . . . . 12 7.3.2. Unplanned Direction Roll . . . . . . . . . . . . . . 12
7.4. Phase X: Roll to Key 'D', 'E', .. . . . . . . . . . . . . 12 7.4. Phase X: Roll to Key 'D', 'E', .. . . . . . . . . . . . . 12
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.2. File Extension . . . . . . . . . . . . . . . . . . . . . 13 10.2. File Extension . . . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. Revision History . . . . . . . . . . . . . . . . . . . . . . 13 12. Revision History . . . . . . . . . . . . . . . . . . . . . . 13
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Overview 2. Overview
Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by A Trust Anchor Locator (TAL) [I-D.ietf-sidrops-https-tal] is used by
Relying Parties in the RPKI to locate and validate Trust Anchor (TA) a Relying Party (RP) in the RPKI to locate and validate Trust Anchor
certificates used in RPKI validation. However, until now there has (TA) CA certificates used in RPKI validation. However, until now
been no formal way of notifying Relying Parties (RP) of updates to a there has been no formal way of notifying RP of updates to a TAL.
TAL. Such updates may be needed in particular in case a Trust Anchor Such updates may be needed in particular in case a TA needs to
needs to perform a planned, or unplanned, key roll. perform a planned or unplanned key roll.
This document defines a new RPKI signed object that can be used to This document defines a new RPKI signed object that can be used to
document the current set of keys and the location(s) of the document the current set of keys and the location(s) of the
accompanying CA certificates, as well as any changes to this set. accompanying CA certificates, as well as any changes to this set.
This allows RPs to be notified automatically of such changes, and This allows RPs to be notified automatically of such changes, and
enables Trust Anchors to pre-stage a number of operational keys so enables TAs to pre-stage a number of operational keys so that planned
that planned and unplanned key rolls can be performed without risking and unplanned key rolls can be performed without risking the
the invalidation of the RPKI tree under the TA. We call this object invalidation of the RPKI tree under the TA. We call this object the
the Trust Anchor Keys (TAK) object. Trust Anchor Keys (TAK) object.
When Relying Parties (RPs) are first bootstrapped, they use any When RPs are first bootstrapped, they use any current TAL to discover
current TAL to discover a key and location(s) of the TA a key and location(s) of the TA certificate(s) for a TA. The RP can
certificate(s) for a TA. The RP can then retrieve and validating the then retrieve and validate the TA certificate, and subsequently
TA certificate, and subsequently validate the manifest [RFC6486] and validate the manifest [RFC6486] and CRL published by that TA [section
CRL [section 5 of @!RFC6487]. However, before processing any other 5 of @!RFC6487]. However, before processing any other objects it
objects it will then first validate the TAK object, if present. All will then first validate the TAK object, if present. All enumerated
enumerated new keys (and locations) are then added to a new list of new keys (and locations) are then added to a new list of current TA
current TA keys for this TA. The RP will then recursively fetch and keys for this TA. The RP will then recursively fetch and validate
validate the TA certificates, manifest, CRL and TAK objects for each the TA certificates, manifest, CRL and TAK objects for each of these
of these keys. As a part of this process the RP will also compile a keys. As a part of this process the RP will also compile a list of
list of revoked keys enumerated by any of the validly signed TAK revoked keys enumerated by any of the validly signed TAK objects. As
objects. As the final step the RP will then filter out any revoked the final step the RP will then filter out any revoked TA keys from
TA keys from its new set. This new set now replaces the previous its new set. This new set now replaces the previous set.
set.
This process allows Trust Anchors to operate a set of N current keys, This process allows Trust Anchors to operate a set of N current keys,
where any key can effectively revoke any or all of the other keys to where any key can effectively revoke any or all of the other keys to
perform either a planned, or an unplanned, key roll. This also perform either a planned, or an unplanned, key roll. This also
allows Trust Anchors to produce long lived TAK objects as forward allows Trust Anchors to produce long lived TAK objects as forward
pointers to RPs, and retire its old key when doing a key roll. While pointers to RPs, and retire its old key when doing a key roll. While
the generic process is quite involved, the amount of work needed to the generic process is quite involved, the amount of work needed to
support an envisioned normal key roll is fairly limited. Under support an envisioned normal key roll is fairly limited. Under
normal circumstances a TA will typically have two current keys, so normal circumstances a TA will typically have two current keys, so
that is can perform an emergency roll over in case one of the keys is that is can perform an emergency roll over in case one of the keys is
lost. This means that the RP will need to validate one additional CA lost. This means that the RP will need to validate one additional CA
certificate, a CRL, a manifest and two TAK objects. certificate, a CRL, a manifest and two TAK objects.
When a key roll is executed a TA will remove one old key, and When a key roll is executed a TA will remove one old key, and
introduce one new (back-up) key. The RP will remove the old key from introduce one new (back-up) key. The RP will remove the old key from
its set, and it will not be queried again, and it will add the new its set, and it will not be queried again, and it will add the new
key and its TA certifcate location(s). key and its TA certificate location(s).
Only in a situation where an RP is very outdated can it be expected Only in a situation where an RP is very outdated can it be expected
that the RP will have to discover several chained TAK object. But, that the RP will have to discover several chained TAK object. But,
since it will remove the outdated TALs in this process, this presents since it will remove the outdated TALs in this process, this presents
a one time cost only. a one time cost only.
3. TAK Object definition 3. TAK Object definition
The TAK object makes use of the template for RPKI digitally signed The TAK object makes use of the template for RPKI digitally signed
objects [RFC6488], which defines a Crytopgraphic Message Syntax (CMS) objects [RFC6488], which defines a Cryptographic Message Syntax (CMS)
[RFC5652] wrapper for the Signed TALs content as well as a generic [RFC5652] wrapper for the Signed TALs content as well as a generic
validation procedure for RPKI signed objects. Therefore, to complete validation procedure for RPKI signed objects. Therefore, to complete
the specification of the TAK object (see Section 4 of [RFC6488]), the specification of the TAK object (see Section 4 of [RFC6488]),
this document defines: this document defines:
o The OID defined in Section 3.1 that identifies the signed object o The OID defined in Section 3.1 that identifies the signed object
as being a TAK. (This OID appears within the eContentType in the as being a TAK. (This OID appears within the eContentType in the
encapContentInfo object as well as the content-type signed encapContentInfo object as well as the content-type signed
attribute in the signerInfo object). attribute in the signerInfo object).
skipping to change at page 13, line 4 skipping to change at page 13, line 4
keys by accident and make itself obsolete. keys by accident and make itself obsolete.
However, these risks can be mitigated greatly by the use of Hardware However, these risks can be mitigated greatly by the use of Hardware
Security Modules (HSM) by TAs, which will guard against theft of a Security Modules (HSM) by TAs, which will guard against theft of a
private key, and operational processes to guard against (accidental) private key, and operational processes to guard against (accidental)
mis-use of the keys in an HSM by operators. mis-use of the keys in an HSM by operators.
Although HSMs can help against key theft, the risk of key loss is Although HSMs can help against key theft, the risk of key loss is
still very applicable. In some ways more so, because back-ups are still very applicable. In some ways more so, because back-ups are
hard by design. Key loss can easily happen for example when an hard by design. Key loss can easily happen for example when an
operator card set that is used to authorise use of a key in an HSM operator card set that is used to authorize use of a key in an HSM
can no longer be used, e.g. because cards are broken or lost, or a can no longer be used, e.g. because cards are broken or lost, or a
persons who holds a card is sadly no longer with us, or passwords are persons who holds a card is sadly no longer with us, or passwords are
forgotten, etc. forgotten, etc.
In such cases the ability to perform an unplanned roll as described In such cases the ability to perform an unplanned roll as described
in this document will be very useful, provided that access to the in this document will be very useful, provided that access to the
both keys is arranged differently, and the issues affecting one key, both keys is arranged differently, and the issues affecting one key,
do not necessarily affect the other key. do not necessarily affect the other key.
An example where the planned rolls are useful is when a TA is using An example where the planned rolls are useful is when a TA is using
skipping to change at page 14, line 5 skipping to change at page 13, line 48
TBD TBD
12. Revision History 12. Revision History
03 - Last Draft under Tim's authorship. 03 - Last Draft under Tim's authorship.
04 - First Draft with Georges's authorship. No substantive 04 - First Draft with Georges's authorship. No substantive
revisions. revisions.
13. Acknowledgements 05 - First Draft with Toms's authorship. No substantive revisions.
The authors wish to thank Martin Hoffmann for a thourough review of 13. Acknowledgments
The authors wish to thank Martin Hoffmann for a thorough review of
this document. this document.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-sidrops-https-tal] [I-D.ietf-sidrops-https-tal]
Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
Bruijnzeels, "Resource Public Key Infrastructure (RPKI) Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
Trust Anchor Locator", draft-ietf-sidrops-https-tal-08 Trust Anchor Locator", draft-ietf-sidrops-https-tal-08
skipping to change at page 16, line 4 skipping to change at page 16, line 4
Email: carlos@lacnic.net Email: carlos@lacnic.net
URI: https://www.lacnic.net/ URI: https://www.lacnic.net/
George G. Michaelson George G. Michaelson
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
6 Cordelia St 6 Cordelia St
South Brisbane, QLD 4101 South Brisbane, QLD 4101
Australia Australia
Email: ggm@apnic.net Email: ggm@apnic.net
Tom Harrison
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane, QLD 4101
Australia
Email: tomh@apnic.net
Tim Bruijnzeels Tim Bruijnzeels
NLnet Labs NLnet Labs
Email: tim@nlnetlabs.nl Email: tim@nlnetlabs.nl
URI: https://www.nlnetlabs.nl/ URI: https://www.nlnetlabs.nl/
Rob Austein Rob Austein
Dragon Research Labs Dragon Research Labs
Email: sra@hactrn.net Email: sra@hactrn.net
 End of changes. 15 change blocks. 
43 lines changed or deleted 53 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/