draft-ietf-sidr-ghostbusters-07.txt   draft-ietf-sidr-ghostbusters-08.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Intended status: Standards Track August 12, 2011 Intended status: Standards Track August 17, 2011
Expires: February 13, 2012 Expires: February 18, 2012
The RPKI Ghostbusters Record The RPKI Ghostbusters Record
draft-ietf-sidr-ghostbusters-07 draft-ietf-sidr-ghostbusters-08
Abstract Abstract
In the Resource Public Key Infrastructure (RPKI), resource In the Resource Public Key Infrastructure (RPKI), resource
certificates completely obscure names or any other information which certificates completely obscure names or any other information which
might be useful for contacting responsible parties to deal with might be useful for contacting responsible parties to deal with
issues of certificate expiration, maintenance, roll-overs, issues of certificate expiration, maintenance, roll-overs,
compromises, etc. This draft describes the RPKI Ghostbusters Record compromises, etc. This draft describes the RPKI Ghostbusters Record
containing human contact information to be signed (indirectly) by a containing human contact information which may be verified
resource-owning certificate. The data in the record are those of a (indirectly) by a CA certificate. The data in the record are those
severely profiled vCARD. of a severely profiled vCARD.
Requirements Language Requirements Language
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].
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
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 February 13, 2012. This Internet-Draft will expire on February 18, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . 3 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . 4
3. RPKI Ghostbusters Record Payload Example . . . . . . . . . . . 4 3. RPKI Ghostbusters Record Payload Example . . . . . . . . . . . 4
4. vCARD Profile . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. vCARD Profile . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. CMS Packaging . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. CMS Packaging . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.2. File Extension . . . . . . . . . . . . . . . . . . . . . . 7 8.2. File Extension . . . . . . . . . . . . . . . . . . . . . . 7
8.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . . 7 8.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
In the operational use of the RPKI it can become necessary to In the operational use of the RPKI it can become necessary to
contact, human to human, the party responsible for a resource-owning contact, human to human, the party responsible for a resource-holding
certificate. An important example is when the owner of a Route CA certificate, AKA the certificate's maintainer, be it the holder of
Origin Authorization (ROA) sees a problem, or an impending problem, the certificate's private key or an administrative person in the
with a certificate or CRL in the path between the ROA and a trust organization, a NOC, .... An important example is when the operator
anchor. E.g., a certificate along that path has expired, is soon to of a prefix described by a Route Origin Authorization (ROA) sees a
expire, or a CRL associated with a CA along the path is stale, thus problem, or an impending problem, with a certificate or CRL in the
placing the quality of the routing of the address space described by path between the ROA and a trust anchor. E.g., a certificate along
the ROA in jeopardy. that path has expired, is soon to expire, or a CRL associated with a
CA along the path is stale, thus placing the quality of the routing
of the address space described by the ROA in jeopardy.
As the names in RPKI certificates are intentionally hashes which are As the names in RPKI certificates are not meaningful to humans, see
not meaningful to humans, see [I-D.ietf-sidr-cp], there is no way to [I-D.ietf-sidr-cp], there is no way to use a certificate itself to
use a certificate itself to lead to the worrisome certificate's or lead to the worrisome certificate's or CRL's maintainer. So, "Who do
CRL's maintainer. So, "Who do you call?" you call?"
This document specifies the RPKI Ghostbusters Record, an object This document specifies the RPKI Ghostbusters Record, an object
signed, indirectly via an End Entity (EE) certificate, by the verified via an End Entity (EE) certificate, issued under a CA
certificate whose maintainer may be contacted using the human usable certificate, the maintainer of which may be contacted using the
payload information in the Ghostbusters Record. payload information in the Ghostbusters Record.
The Ghostbusters Record conforms to the syntax defined in The Ghostbusters Record conforms to the syntax defined in
[I-D.ietf-sidr-signed-object]. [I-D.ietf-sidr-signed-object].
Note that the Ghostbusters Record is not an identity certificate, but Note that the Ghostbusters Record is not an identity certificate, but
rather an attestation to the contact data made by the issuer of the rather an attestation to the contact data made by the maintainer of
certificate signing the Ghostbusters Record. the CA certificate issuing the EE certificate whose corresponding
private key signs the Ghostbusters Record.
This record is not meant to supplant or be used as resource registry This record is not meant to supplant or be used as resource registry
whois data. It gives information about an RPKI certificate whois data. It gives information about an RPKI CA certificate
maintainer not a resource holder. maintainer not a resource holder.
The Ghostbusters Record is optional, certificates in the RPKI may or The Ghostbusters Record is optional, CA certificates in the RPKI MAY
may not have associated Ghostbuster Records. have zero or more associated Ghostbuster Records.
This specification has three main sections. The first, Section 4, is This specification has three main sections. The first, Section 4, is
the format of the contact payload information, a severely profiled the format of the contact payload information, a severely profiled
vCARD. The second, Section 5, profiles the packaging of the payload vCARD. The second, Section 5, profiles the packaging of the payload
as a profile of the RPKI Signed Object Template specification as a profile of the RPKI Signed Object Template specification
[I-D.ietf-sidr-signed-object]. The third, Section 6, describes the [I-D.ietf-sidr-signed-object]. The third, Section 6, describes the
proper validation of the signed Ghostbusters Record. proper validation of the signed Ghostbusters Record.
2. Suggested Reading 2. Suggested Reading
skipping to change at page 4, line 45 skipping to change at page 4, line 49
BEGIN - pro forma packaging which MUST be the first line in the BEGIN - pro forma packaging which MUST be the first line in the
vCARD and MUST have the value "BEGIN:vCARD" as described in vCARD and MUST have the value "BEGIN:vCARD" as described in
[I-D.ietf-vcarddav-vcardrev]. [I-D.ietf-vcarddav-vcardrev].
VERSION - pro forma packaging which MUST be the second line in the VERSION - pro forma packaging which MUST be the second line in the
vCARD and MUST have the value "VERSION:4.0" as described in 3.6.9 vCARD and MUST have the value "VERSION:4.0" as described in 3.6.9
of [I-D.ietf-vcarddav-vcardrev]. of [I-D.ietf-vcarddav-vcardrev].
FN - the name, as described in 6.2.1 of FN - the name, as described in 6.2.1 of
[I-D.ietf-vcarddav-vcardrev], of a contactable person who [I-D.ietf-vcarddav-vcardrev], of a contactable person who
responsible for the certificate. responsible a the CA certificate.
N - the components of the name of the object the vCard represents, N - the components of the name of the object the vCard represents,
as described in 6.2.2 of [I-D.ietf-vcarddav-vcardrev]. as described in 6.2.2 of [I-D.ietf-vcarddav-vcardrev].
ORG - an organization as described in 6.6.4 of ORG - an organization as described in 6.6.4 of
[I-D.ietf-vcarddav-vcardrev]. [I-D.ietf-vcarddav-vcardrev].
ADR - a postal address as described in 6.3 of ADR - a postal address as described in 6.3 of
[I-D.ietf-vcarddav-vcardrev]. [I-D.ietf-vcarddav-vcardrev].
skipping to change at page 5, line 42 skipping to change at page 5, line 45
The ContentType of a Ghostbusters Record is defined as id-ct- The ContentType of a Ghostbusters Record is defined as id-ct-
rpkiGhostbusters, and has the numerical value of rpkiGhostbusters, and has the numerical value of
1.2.840.113549.1.9.16.1.35. This OID MUST appear both within the 1.2.840.113549.1.9.16.1.35. This OID MUST appear both within the
eContentType in the encapContentInfo object as well as the eContentType in the encapContentInfo object as well as the
ContentType signed attribute in the signerInfo object. See ContentType signed attribute in the signerInfo object. See
[I-D.ietf-sidr-signed-object]. [I-D.ietf-sidr-signed-object].
eContent: The content of a Ghostbusters Record is described above in eContent: The content of a Ghostbusters Record is described above in
Section 4 above. Section 4 above.
Similarly to a ROA, the Ghostbusters Record is verified using an EE Similarly to a ROA, a Ghostbusters Record is verified using an EE
certificate issued under the CA certificate associated with the certificate issued by the resource-holding CA certificate whose
resource-holding certificate whose maintainer is described in the maintainer is described in the vCARD.
vCARD.
The EE certificate used to verify the Ghostbusters Record is the one The EE certificate used to verify the Ghostbusters Record is the one
that appears in the CMS data structure that contains the payload that appears in the CMS data structure which contains the payload
defined above. defined above.
This EE certificate MUST describe its internet number resources using This EE certificate MUST describe its internet number resources using
the "inherit" attribute, rather than explicit description of a the "inherit" attribute, rather than explicit description of a
resource set, see [RFC3779]. resource set, see [RFC3779].
6. Validation 6. Validation
The validation procedure defined in Section 3 of The validation procedure defined in Section 3 of
[I-D.ietf-sidr-signed-object] is applied to a Ghostbusters Record. [I-D.ietf-sidr-signed-object] is applied to a Ghostbusters Record.
skipping to change at page 6, line 30 skipping to change at page 6, line 32
Though there is no on the wire protocol in this specification, there Though there is no on the wire protocol in this specification, there
are attacks which could abuse the data described. As the data, to be are attacks which could abuse the data described. As the data, to be
useful, need to be public, little can be done to avoid this exposure. useful, need to be public, little can be done to avoid this exposure.
Phone Numbers: The vCARDs may contain real world telephone numbers Phone Numbers: The vCARDs may contain real world telephone numbers
which could be abused for telemarketing, abusive calls, etc. which could be abused for telemarketing, abusive calls, etc.
Email Addresses: The vCARDs may contain Email addresses which could Email Addresses: The vCARDs may contain Email addresses which could
be abused for purposes of spam. be abused for purposes of spam.
Relying parties are warned that the data in a Ghostbusters Record are Relying parties are hereby warned that the data in a Ghostbusters
self-asserted. These data have not been verified by the CA that Record are self-asserted. These data have not been verified by the
issued a (CA) certificate to the entity that issued the EE CA that issued the CA certificate to the entity that issued the EE
certificate used to validate the Ghostbusters Record. certificate used to validate the Ghostbusters Record.
8. IANA Considerations 8. IANA Considerations
8.1. OID 8.1. OID
The IANA is requested to register the OID for the Ghostbusters Record The IANA is requested to register the OID for the Ghostbusters Record
in the registry created by [I-D.ietf-sidr-signed-object] as follows: in the registry created by [I-D.ietf-sidr-signed-object] as follows:
Name OID Specification Name OID Specification
 End of changes. 15 change blocks. 
36 lines changed or deleted 38 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/