draft-ietf-sidr-rfc6490-bis-00.txt   draft-ietf-sidr-rfc6490-bis-01.txt 
SIDR G. Huston SIDR G. Huston
Internet-Draft APNIC Internet-Draft APNIC
Obsoletes: 6490 (if approved) S. Weiler Obsoletes: 6490 (if approved) S. Weiler
Intended status: Standards Track SPARTA, Inc. Intended status: Standards Track SPARTA, Inc.
Expires: September 5, 2014 G. Michaelson Expires: March 23, 2015 G. Michaelson
APNIC APNIC
S. Kent S. Kent
BBN BBN
March 4, 2014 September 19, 2014
Resource Certificate PKI (RPKI) Trust Anchor Locator Resource Certificate PKI (RPKI) Trust Anchor Locator
draft-ietf-sidr-rfc6490-bis-00 draft-ietf-sidr-rfc6490-bis-01
Abstract Abstract
This document defines a Trust Anchor Locator (TAL) for the Resource This document defines a Trust Anchor Locator (TAL) for the Resource
Certificate Public Key Infrastructure (RPKI). Certificate Public Key Infrastructure (RPKI).
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.
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 September 5, 2014. This Internet-Draft will expire on March 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 5, line 23 skipping to change at page 5, line 23
while issuing all relevant child certificates under the immediate while issuing all relevant child certificates under the immediate
subordinate CA. This measure also allows the CRL issued by that subordinate CA. This measure also allows the CRL issued by that
entity to be used to revoke the subordinate (CA) certificate in the entity to be used to revoke the subordinate (CA) certificate in the
event of suspected key compromise of this potentially more vulnerable event of suspected key compromise of this potentially more vulnerable
online operational key pair. online operational key pair.
The trust anchor MUST be published at a stable URI. When the trust The trust anchor MUST be published at a stable URI. When the trust
anchor is re-issued for any reason, the replacement CA certificate anchor is re-issued for any reason, the replacement CA certificate
MUST be accessible using the same URI. MUST be accessible using the same URI.
Becuase the trust anchor is a self-signed certificate, there is no Because the trust anchor is a self-signed certificate, there is no
corresponding Certificate Revocation List that can be used to revoke corresponding Certificate Revocation List that can be used to revoke
it, nor is there a manifest [RFC6486] that lists this certificate. it, nor is there a manifest [RFC6486] that lists this certificate.
If an entity wishes to withdraw a self-signed CA certificate as a If an entity wishes to withdraw a self-signed CA certificate as a
putative Trust Anchor, for any reason, including key rollover, the putative Trust Anchor, for any reason, including key rollover, the
entity MUST remove the object from the location referenced in the entity MUST remove the object from the location referenced in the
TAL. TAL.
Where the TAL contains two or more rsync URIs, then the same self- Where the TAL contains two or more rsync URIs, then the same self-
signed CA certificate MUST be found at each referenced location. In signed CA certificate MUST be found at each referenced location. In
skipping to change at page 7, line 9 skipping to change at page 7, line 9
4. Security Considerations 4. Security Considerations
Compromise of a trust anchor private key permits unauthorized parties Compromise of a trust anchor private key permits unauthorized parties
to masquerade as a trust anchor, with potentially severe to masquerade as a trust anchor, with potentially severe
consequences. Reliance on an inappropriate or incorrect trust anchor consequences. Reliance on an inappropriate or incorrect trust anchor
has similar potentially severe consequences. has similar potentially severe consequences.
This trust anchor locator does not directly provide a list of This trust anchor locator does not directly provide a list of
resources covered by the referenced self-signed CA certificate. resources covered by the referenced self-signed CA certificate.
Instead, the RP is referred to thetrust anchor itself and the INR Instead, the RP is referred to the trust anchor itself and the INR
extension(s) within this certificate. This provides necessary extension(s) within this certificate. This provides necessary
operational flexibility, but it also allows the certificate issuer to operational flexibility, but it also allows the certificate issuer to
claim to be authoritative for any resource. Relying parties should claim to be authoritative for any resource. Relying parties should
either have great confidence in the issuers of such certificates that either have great confidence in the issuers of such certificates that
they are configuring as trust anchors, or they should issue their own they are configuring as trust anchors, or they should issue their own
self-signed certificate as a trust anchor and, in doing so, impose self-signed certificate as a trust anchor and, in doing so, impose
constraints on the subordinate certificates. constraints on the subordinate certificates.
5. IANA Considerations 5. IANA Considerations
 End of changes. 6 change blocks. 
6 lines changed or deleted 6 lines changed or added

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