draft-ietf-sidr-ghostbusters-00.txt   draft-ietf-sidr-ghostbusters-01.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft IIJ Internet-Draft Internet Initiative Japan
Intended status: Standards Track January 1, 2011 Intended status: Standards Track March 10, 2011
Expires: July 5, 2011 Expires: September 11, 2011
The RPKI Ghostbusters Record The RPKI Ghostbusters Record
draft-ietf-sidr-ghostbusters-00 draft-ietf-sidr-ghostbusters-01
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 to be signed (indirectly) by a
resource-owning certificate. The data in the record are those of a resource-owning certificate. The data in the record are those of a
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 July 5, 2011. This Internet-Draft will expire on September 11, 2011.
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 . . . . . . . . . . . . . . . . . . . . . . . 3
3. RPKI Ghostbuster Record Payload Example . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
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-owning
certificate. The primary example of this need is when the owner of a certificate. An important example is when the owner of a Route
Route Origin Authorizations (ROA) sees that a upstream certificate in Origin Authorization (ROA) sees a problem, or an impending problem,
the chain needed to validate the ROA is soon to expire or a CRL with a certificate or CRL in the path between the ROA and a trust
associated with the certificate is stale, thus placing the quality of anchor. E.g., a certificate along that path has expired, is soon to
the routing of the address space described by the ROA in jeopardy. 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 obscured hashes, As the names in RPKI certificates are intentionally hashes which are
see [I-D.ietf-sidr-cp], there is no way to use the certificate itself not meaningful to humans, see [I-D.ietf-sidr-cp], there is no way to
to lead to the certificate's maintainer. So, "Who do you call?" use a certificate itself to lead to the worrisome certificate's or
CRL's maintainer. So, "Who do you call?"
This document specifies the RPKI Ghostbusters Record, signed This document specifies the RPKI Ghostbusters Record, an object
indirectly by the certificate whose maintainer needs to be contacted, signed, indirectly via an End Entity (EE) certificate, by the
which contains human usable contact information for that maintainer. certificate whose maintainer may be contacted using the human usable
payload information in the Ghostbusters Record.
This document and the Ghostbusters Record conform to the syntax The Ghostbusters Record conforms to the syntax defined in
defined in [I-D.ietf-sidr-signed-object]. [I-D.ietf-sidr-signed-object].
Note that this record is not an identity certificate, but an Note that the Ghostbusters Record is not an identity certificate, but
attestation to the contact data made by the holder of the signing rather an attestation to the contact data made by the issuer of the
certificate, and its parent if that is an EE certificate. certificate signing 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 a certificate maintainer not whois data. It gives information about an RPKI certificate
a resource holder. maintainer not a resource holder.
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
It is assumed that the reader understands the RPKI, It is assumed that the reader understands the RPKI,
[I-D.ietf-sidr-arch], the RPKI Repository Structure, [I-D.ietf-sidr-arch], the RPKI Repository Structure,
[I-D.ietf-sidr-repos-struct], Signed RPKI Objects, [I-D.ietf-sidr-repos-struct], Signed RPKI Objects,
[I-D.ietf-sidr-signed-object], and vCARDS [RFC2426]. [I-D.ietf-sidr-signed-object], and vCARDs [RFC2426].
3. RPKI Ghostbuster Record Payload Example 3. RPKI Ghostbusters Record Payload Example
An example of an RPKI Ghostbusters Record payload with all fields An example of an RPKI Ghostbusters Record payload with all fields
used is as follows: populated is as follows:
BEGIN:vCard BEGIN:vCard
VERSION:3.0 VERSION:3.0
FN:Human's Name FN:Human's Name
ORG:Organizational Entity ORG:Organizational Entity
ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern; WA; 98666;U.S.A. ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern; WA; 98666;U.S.A.
TEL;TYPE=VOICE,MSG,WORK:+1-666-555-1212 TEL;TYPE=VOICE,MSG,WORK:+1-666-555-1212
TEL;TYPE=FAX,WORK:+1-666-555-1213 TEL;TYPE=FAX,WORK:+1-666-555-1213
EMAIL;TYPE=INTERNET:human@example.com EMAIL;TYPE=INTERNET:human@example.com
END:vCard END:vCard
skipping to change at page 5, line 11 skipping to change at page 5, line 17
The BEGIN, VERSION, and END lines MUST be included in a record. To The BEGIN, VERSION, and END lines MUST be included in a record. To
be useful, FN and one or more of ADR, TEL, and EMAIL SHOULD be be useful, FN and one or more of ADR, TEL, and EMAIL SHOULD be
included. included.
5. CMS Packaging 5. CMS Packaging
The Ghostbusters Record is a CMS signed-data object conforming to the The Ghostbusters Record is a CMS signed-data object conforming to the
RPKI Signed Data Object Template, [I-D.ietf-sidr-signed-object]. RPKI Signed Data Object Template, [I-D.ietf-sidr-signed-object].
The ContentType of a Ghostbusters Record is defined as The ContentType of a Ghostbusters Record is defined as
rpkiGhostbusters, and has the numerical value of TO BE ASSIGNED. rpkiGhostbusters, and has the numerical value of [TO BE ASSIGNED].
This OID MUST appear both within the eContentType in the This OID MUST appear both within the eContentType in the
encapContentInfo object as well as the ContentType signed attribute encapContentInfo object as well as the ContentType signed attribute
in the signerInfo object. See [I-D.ietf-sidr-signed-object]. in the signerInfo object. See [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 usually signed by an Similarly to a ROA, the Ghostbusters Record is verified using an EE
end-entity certificate which is, in turn, signed by the resource- certificate issued under the CA certificate associated with the
holding certificate whose maintainer is described in the vCARD. resource-holding certificate whose maintainer is described in the
vCARD.
The EE certificate used to verify the Ghostbusters Record is the one
that appears in the CMS data structure that contains the payload
defined above.
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.
After this procedure has been performed, the Version number field After this procedure has been performed, the Version number field
within the payload is checked, and the OCTET STRING containing the within the payload is checked, and the OCTET STRING containing the
vCARD data is extracted. These data are checked against the profile vCARD data is extracted. These data are checked against the profile
defined in Section 4 of this document. Only if all of these checks defined in Section 4 of this document. Only if all of these checks
pass is the Ghostbusters payload deemed valid and made available to pass is the Ghostbusters payload deemed valid and made available to
skipping to change at page 5, line 44 skipping to change at page 6, line 10
7. Security Considerations 7. Security Considerations
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 purpases of spam. be abused for purposes of spam.
Relying parties are warned that the data in a Ghostbusters Record are Relying parties are warned that the data in a Ghostbusters Record are
self-asserted. These data have not been verified by the CA that self-asserted. These data have not been verified by the CA that
issued a (CA) certificate to the entity that issued the EE issued a (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
This document has no IANA Considerations. This document has no IANA Considerations.
9. Acknowledgments 9. Acknowledgments
The author wishes to thank Russ Housley for suggesting profiling the The author wishes to thank Russ Housley for suggesting profiling the
vCARD specification, the authors of [I-D.ietf-sidr-signed-object], vCARD specification, the authors of [I-D.ietf-sidr-signed-object],
and particularly Steven Kent. and particularly Stephen Kent.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-sidr-signed-object] [I-D.ietf-sidr-signed-object]
Lepinski, M., Chi, A., and S. Kent, "Signed Object Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure", Template for the Resource Public Key Infrastructure",
draft-ietf-sidr-signed-object-01 (work in progress), draft-ietf-sidr-signed-object-03 (work in progress),
October 2010. February 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
RFC 2426, September 1998. RFC 2426, September 1998.
10.2. Informative References 10.2. Informative References
[I-D.ietf-sidr-arch] [I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-11 (work in Secure Internet Routing", draft-ietf-sidr-arch-12 (work in
progress), September 2010. progress), February 2011.
[I-D.ietf-sidr-cp] [I-D.ietf-sidr-cp]
Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
Policy (CP) for the Resource PKI (RPKI", Policy (CP) for the Resource PKI (RPKI",
draft-ietf-sidr-cp-16 (work in progress), December 2010. draft-ietf-sidr-cp-16 (work in progress), December 2010.
[I-D.ietf-sidr-repos-struct] [I-D.ietf-sidr-repos-struct]
Huston, G., Loomans, R., and G. Michaelson, "A Profile for Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", Resource Certificate Repository Structure",
draft-ietf-sidr-repos-struct-06 (work in progress), draft-ietf-sidr-repos-struct-07 (work in progress),
November 2010. February 2011.
Author's Address Author's Address
Randy Bush Randy Bush
Internet Initiative Japan, Inc. Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
US US
Phone: +1 206 780 0431 x1 Phone: +1 206 780 0431 x1
Email: randy@psg.com Email: randy@psg.com
 End of changes. 21 change blocks. 
40 lines changed or deleted 49 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/