[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                     T. Bruijnzeels
Internet-Draft                                                  RIPE NCC
Intended status: Standards Track                             C. Martinez
Expires: February 16, 2018                                        LACNIC
                                                         August 15, 2017


                       RPKI signed object for TAL
                draft-tbruijnzeels-sidrops-signed-tal-01

Abstract

   Trust Anchor Locators (TALs) [RFC7730] are used by Relying Parties in
   the RPKI to locate and validate Trust Anchor certificates used in
   RPKI validation.  This document defines an RPKI signed object
   [RFC6488] for a Trust Anchor Locator (TAL) that can be published by
   Trust Anchor to communicate a new TAL to already deployed Relying
   Parties.  The two primary use cases for this are that 1) a Trust
   Anchor may wish to change the locations where its TA certificate may
   be found, and 2) a Trust Anchor may wish to perform a planned
   migration to a new key.  Note that unplanned key rolls are considered
   out of scope for this document.

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 February 16, 2018.

Copyright Notice

   Copyright (c) 2017 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



Bruijnzeels & Martinez  Expires February 16, 2018               [Page 1]


Internet-Draft         RPKI signed object for TAL            August 2017


   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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Signed TAL definition . . . . . . . . . . . . . . . . . . . .   3
     3.1.  The Signed TAL Content Type . . . . . . . . . . . . . . .   4
     3.2.  The Signed TAL eContent . . . . . . . . . . . . . . . . .   4
     3.3.  Signed TAL Validation . . . . . . . . . . . . . . . . . .   4
   4.  Signed TAL Generation . . . . . . . . . . . . . . . . . . . .   4
   5.  Signed TAL Publication  . . . . . . . . . . . . . . . . . . .   5
   6.  Supporting a TA Key Roll  . . . . . . . . . . . . . . . . . .   5
     6.1.  Preparing a new TA key  . . . . . . . . . . . . . . . . .   6
     6.2.  Staging period - Using both the old and the new TA key  .   6
     6.3.  Preserving the Signed TAL . . . . . . . . . . . . . . . .   6
     6.4.  Retiring the old key  . . . . . . . . . . . . . . . . . .   7
     6.5.  Relying Party Use . . . . . . . . . . . . . . . . . . . .   7
   7.  Supporting changing TA certificate publication point(s) . . .   7
     7.1.  Adding a publication point  . . . . . . . . . . . . . . .   7
     7.2.  Withdrawing a publication point . . . . . . . . . . . . .   7
     7.3.  Publishing the Signed TAL . . . . . . . . . . . . . . . .   7
     7.4.  Relying Party Use . . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  OID . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.2.  File Extension  . . . . . . . . . . . . . . . . . . . . .   8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     11.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].








Bruijnzeels & Martinez  Expires February 16, 2018               [Page 2]


Internet-Draft         RPKI signed object for TAL            August 2017


2.  Introduction

   Trust Anchor Locator (TAL) files [RFC7730] are used in the Resource
   Public Key Infrastructure (RPKI) to help Relying Parties locate and
   verify a trust anchor certificate.  A TAL file consists of:

   o  One or more rsync URIs [RFC5781]

   o  A subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in
      Base64

   The TAL can be distributed out-of-band to Relying Parties (RP), and
   it allows the RP to retrieve the most recent version of the Trust
   Anchor (TA) certificate from the cited location, and verify that
   public key of this certificate matches the TAL.  This is useful as it
   allows selected data in the trust anchor to change, without needing
   to effect redistribution of the trust anchor per se.  In particular
   the Internet Number Resources (INRs) extension [RFC3779] and the
   publication points defined in the Subject Information Access
   [RFC6487] may be updated this way.

   The assumption is that both the URIs and key of the TA certificate
   remain stable.  However, an organisation operating a TA may wish to
   change either of these properties, because of a need to:

   o  change one or more URIs

   o  perform a planned key roll

   In this document we describe a method for TA operators to publish a
   an updated TAL in a secure a well-defined fashion, so that RPs can be
   alerted about these changes.

   Note that [RFC5011] describes Automated Updates of DNS Security
   (DNSSEC) Trust Anchors and can provide some useful insight here as
   well.  However, concepts like a set of Trust Anchors, standby Trust
   Anchors, and TTLs are not applicable to the RPKI.  Therefore we
   believe that an alternative approach based on already existing
   concept of the Trust Anchor Locator [RFC7730] is appropriate.

3.  Signed TAL definition

   A signed TAL is an RPKI signed object, as specified in [RFC6488].
   The RPKI signed object template requires specification of the
   following data elements in the context of the manifest structure.






Bruijnzeels & Martinez  Expires February 16, 2018               [Page 3]


Internet-Draft         RPKI signed object for TAL            August 2017


3.1.  The Signed TAL Content Type

   This document requests an OID for signed-Tal as follows:

   signed-Tal OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
              rsadsi(113549) pkcs(1) pkcs9(9) 16 id-smime (1) TBD }

   This OID MUST appear both within the eContentType in the
   encapContentInfo object as well as the content-type signed attribute
   in the signerInfo object (see [RFC6488]).

3.2.  The Signed TAL eContent

   The content of a Signed TAL is ASN.1 encoded using the Distinguished
   Encoding Rules (DER) [X.690], and is defined as follows:

   SignedTalContent ::= IA5String

   The "SignedTalContent" contains the content of the new TAL encoded in
   Base64 [RFC4648].

3.3.  Signed TAL Validation

   Before a Relying Party can use a Signed TAL, the relying party MUST
   first validate the Signed TAL.  To validate a Signed TAL, the relying
   party MUST perform all the validation checks specified in [RFC6488]
   as well as the following additional specific validation step.

   o  The eContentType in the EncapsulatedContentInfo has OID
      1.2.840.113549.1.9.16.1.TBD.

   o  The EE certificate of this Signed TAL is signed by a known Trust
      Anchor

   o  The decoded TAL content conforms to the format defined in
      [RFC7730]

   If the above procedure indicates that the manifest is invalid, then
   the Signed TAL MUST be discarded and treated as though no Signed TAL
   were present.

4.  Signed TAL Generation

   A TA MAY choose to generate a single Singed TAL object to publish in
   its TA certificate publication point(s) in the RPKI.  The TA MUST
   perform the following steps to generate the Signed TAL:





Bruijnzeels & Martinez  Expires February 16, 2018               [Page 4]


Internet-Draft         RPKI signed object for TAL            August 2017


   o  Generate a key pair for a "one-time-use" EE certificate to use for
      the Signed TAL

   o  Generate a one-time-use EE certificate for the Signed TAL

   o  This EE certificate MUST have an SIA extension access description
      field with an accessMethod OID value of id-ad-signedobject, where
      the associated accessLocation references the publication point of
      the Sigend TAL as an object URL.

   o  As described in [RFC6487], an [RFC3779] extension is required in
      the EE certificate used for this object.  However, because the
      resource set is irrelevant to this object type, this certificate
      MUST describe its Internet Number Resources (INRs) using the
      "inherit" attribute, rather than explicit description of a
      resource set.

   o  This EE certificate MUST have a "notBefore" time that is before
      the moment that the Signed TAL will be published.

   o  This EE certificate MUST have a "notAfter" time that reflects the
      intended time that this Signed TAL will be published.  If the EE
      certificate for a Signed TAL is expired, it MUST no longer be
      publish, but of course it MAY be replaced by a newly generated
      Signed TAL object with similar content and an updated "notAfter"
      time.

5.  Signed TAL Publication

   A TA MAY publish a single Signed TAL object directly under its CA
   repository publication points.  A non-normative guideline for naming
   this object is that the filename chosen for the signed TAL in the
   publication repository be a value derived from the public key part of
   the entity's key pair, using the algorithm described for CRLs in
   section 2.2 of [RFC6481] for generation of filenames.  The filename
   extension of ".tal" MUST be used to denote the object as a signed
   TAL.  Note that this is in-line with filename extensions defined in
   section 7.2 of [RFC6481].

6.  Supporting a TA Key Roll

   A Signed TAL MAY be used to communicate a planned key roll for the
   TA.








Bruijnzeels & Martinez  Expires February 16, 2018               [Page 5]


Internet-Draft         RPKI signed object for TAL            August 2017


6.1.  Preparing a new TA key

   Prior to publishing the Signed TAL for the new key the TA MUST
   perform the following steps:

   o  Generate a new key pair for the new TA certificate

   o  Generate a new TA Certificate, using a Subject Information Access
      for CA certificates (see section 4.8.8.1 of [RFC6487]) that
      references the URIs that will be used by the new key to publish
      objects, that are different from the URIs used by the TA
      certificate for the current key.

   o  ALL current signed certificates and other objects, with the
      exception of the old CRL, Manifest and Signed TAL, must be re-
      issued by the new key and published under the new publication
      point(s).

   o  The new TA certificate itself MUST be published in a (number of)
      new location(s) that are different from where the TA certificate
      for the current key is published.

   After these steps are performed a new Signed TAL MUST be generated as
   described in Section 4, and published as described in Section 5.

6.2.  Staging period - Using both the old and the new TA key

   The staging period is initiated by the initial publication of a
   Signed TAL for the new key and must be last at least 24 HOURS.
   During the staging period the TA MUST continue to operate both the
   old and the new TA key.  Note that this is the same staging period
   used for key roll of normal CAs in the RPKI, described in [RFC6489].

6.3.  Preserving the Signed TAL

   The TA SHOULD preserve a Signed TAL for the old key after the staging
   period as a hint for RPs that missed the key roll.  The following
   process can be used to achieve this:

   o  Produce a new long-lived CRL that revokes all previously signed
      certificates

   o  Produce a new long-lived Signed TAL

   o  Produce a new long-lived manifest that includes the CRL and Signed
      TAL

   o  Publish the CRL, MFT and Signed TAL



Bruijnzeels & Martinez  Expires February 16, 2018               [Page 6]


Internet-Draft         RPKI signed object for TAL            August 2017


   o  Destroy the old TA key

6.4.  Retiring the old key

   The TA SHOULD retire and delete its old key after the staging period
   is over.

6.5.  Relying Party Use

   When an RP discovers a valid Signed TAL signed under a TA, and it
   notices that the contained TAL is different from its current TAL for
   this TA and that the "subjectPublicKeyInfo" has changed, then the RP
   MUST replace the TAL for this TA with the new TAL, abort the current
   top-down validation operation, and initiate a new top-down validation
   operation using the updated TAL.

   It is RECOMMENDED that the software informs the operator of this
   event.

7.  Supporting changing TA certificate publication point(s)

   A signed TAL MAY be used to communicate an addition or removal of one
   or more publication locations where the TA certificate can be found.

7.1.  Adding a publication point

   When adding a publication point for a TA certificate, the TA MUST
   publish the certificate in the new location(s) prior to publication
   of the Signed TAL.

7.2.  Withdrawing a publication point

   When removing a publication point for TA certificate, the TA SHOULD
   observe a staging period of at least 24 Hours.  The staging period is
   initiated by the publication of an updated Signed TAL where the
   publication point has been removed.  During the staging period the TA
   SHOULD keep the old publication point up to date and available.

7.3.  Publishing the Signed TAL

   It is RECOMMENDED that a Trust Anchor publishes a valid Signed TAL
   for what it believes its current TAL should be at all times.

7.4.  Relying Party Use

   When an RP discovers a valid Signed TAL signed under a TA, and it
   notices that the contained TAL is different from its current TAL for
   this TA and that the "subjectPublicKeyInfo" has not changed, then the



Bruijnzeels & Martinez  Expires February 16, 2018               [Page 7]


Internet-Draft         RPKI signed object for TAL            August 2017


   RP MUST replace the TAL for this TA with the new TAL for future use,
   but can continue the current top-down validation operation.

   It is RECOMMENDED that the software informs the operator of this
   event.

8.  IANA Considerations

8.1.  OID

   IANA is to add the following to the "RPKI Signed Objects" registry:

         Decimal  Description                       References

         TBD      signed-Tal                       [section 3.1]

8.2.  File Extension

   IANA is to add an item for the Signed TAL file extension to the "RPKI
   Repository Name Scheme" created by [RFC6481] as follows:

         Extension      RPKI Object           Reference
         -------------------------------------------------------
            .tal        Signed TAL            [this document]

9.  Security Considerations

   TBD

10.  Acknowledgements

   TBD

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779,
              DOI 10.17487/RFC3779, June 2004,
              <http://www.rfc-editor.org/info/rfc3779>.





Bruijnzeels & Martinez  Expires February 16, 2018               [Page 8]


Internet-Draft         RPKI signed object for TAL            August 2017


   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <http://www.rfc-editor.org/info/rfc4648>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <http://www.rfc-editor.org/info/rfc5280>.

   [RFC5781]  Weiler, S., Ward, D., and R. Housley, "The rsync URI
              Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010,
              <http://www.rfc-editor.org/info/rfc5781>.

   [RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
              Resource Certificate Repository Structure", RFC 6481,
              DOI 10.17487/RFC6481, February 2012,
              <http://www.rfc-editor.org/info/rfc6481>.

   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", RFC 6487,
              DOI 10.17487/RFC6487, February 2012,
              <http://www.rfc-editor.org/info/rfc6487>.

   [RFC6488]  Lepinski, M., Chi, A., and S. Kent, "Signed Object
              Template for the Resource Public Key Infrastructure
              (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
              <http://www.rfc-editor.org/info/rfc6488>.

   [RFC7730]  Huston, G., Weiler, S., Michaelson, G., and S. Kent,
              "Resource Public Key Infrastructure (RPKI) Trust Anchor
              Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016,
              <http://www.rfc-editor.org/info/rfc7730>.

   [X.509]    ITU-T Recommendation X.509 (2000), "Recommendation X.509:
              The Directory - Authentication Framework", 2000.

   [X.690]    ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
              "Information technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", 2002.

11.2.  Informative References

   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
              Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
              September 2007, <http://www.rfc-editor.org/info/rfc5011>.



Bruijnzeels & Martinez  Expires February 16, 2018               [Page 9]


Internet-Draft         RPKI signed object for TAL            August 2017


   [RFC6489]  Huston, G., Michaelson, G., and S. Kent, "Certification
              Authority (CA) Key Rollover in the Resource Public Key
              Infrastructure (RPKI)", BCP 174, RFC 6489,
              DOI 10.17487/RFC6489, February 2012,
              <http://www.rfc-editor.org/info/rfc6489>.

Authors' Addresses

   Tim Bruijnzeels
   RIPE NCC

   Email: tim@ripe.net


   Carlos Martinez
   LACNIC

   Email: carlos@lacnic.net

































Bruijnzeels & Martinez  Expires February 16, 2018              [Page 10]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/