< draft-ietf-sidr-rpsl-sig-05.txt   draft-ietf-sidr-rpsl-sig-06.txt >
SIDR R. Kisteleki SIDR R. Kisteleki
Internet-Draft RIPE NCC Internet-Draft RIPE NCC
Intended status: Standards Track B. Haberman Intended status: Standards Track B. Haberman
Expires: November 11, 2012 JHU APL Expires: May 30, 2015 JHU APL
May 10, 2012 November 26, 2014
Securing RPSL Objects with RPKI Signatures Securing RPSL Objects with RPKI Signatures
draft-ietf-sidr-rpsl-sig-05.txt draft-ietf-sidr-rpsl-sig-06.txt
Abstract Abstract
This document describes a method to allow parties to electronically This document describes a method to allow parties to electronically
sign RPSL-like objects and validate such electronic signatures. This sign RPSL-like objects and validate such electronic signatures. This
allows relying parties to detect accidental or malicious allows relying parties to detect accidental or malicious
modifications on such objects. It also allows parties who run modifications on such objects. It also allows parties who run
Internet Routing Registries or similar databases, but do not yet have Internet Routing Registries or similar databases, but do not yet have
RPSS-like authentication of the maintainers of certain objects, to RPSS-like authentication of the maintainers of certain objects, to
verify that the additions or modifications of such database objects verify that the additions or modifications of such database objects
are done by the legitimate holder(s) of the Internet resources are done by the legitimate holder(s) of the Internet resources
mentioned in those objects. mentioned in those objects.
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 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 November 11, 2012. This Internet-Draft will expire on May 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Signature Syntax and Semantics . . . . . . . . . . . . . . . . 3 2. Signature Syntax and Semantics . . . . . . . . . . . . . . . 3
2.1. General Attributes, Meta Information . . . . . . . . . . . 4 2.1. General Attributes, Meta Information . . . . . . . . . . 3
2.2. Signed Attributes . . . . . . . . . . . . . . . . . . . . 5 2.2. Signed Attributes . . . . . . . . . . . . . . . . . . . . 5
2.3. Storage of the Signature Data . . . . . . . . . . . . . . 6 2.3. Storage of the Signature Data . . . . . . . . . . . . . . 5
2.4. Number Resource Coverage . . . . . . . . . . . . . . . . . 6 2.4. Number Resource Coverage . . . . . . . . . . . . . . . . 6
2.5. Validity Time of the Signature . . . . . . . . . . . . . . 6 2.5. Validity Time of the Signature . . . . . . . . . . . . . 6
3. Signature Creation and Validation Steps . . . . . . . . . . . 7 3. Signature Creation and Validation Steps . . . . . . . . . . . 6
3.1. Canonicalization . . . . . . . . . . . . . . . . . . . . . 7 3.1. Canonicalization . . . . . . . . . . . . . . . . . . . . 6
3.2. Signature Creation . . . . . . . . . . . . . . . . . . . . 8 3.2. Signature Creation . . . . . . . . . . . . . . . . . . . 8
3.3. Signature Validation . . . . . . . . . . . . . . . . . . . 9 3.3. Signature Validation . . . . . . . . . . . . . . . . . . 9
4. Signed Object Types, Set of Signed Attributes . . . . . . . . 10 4. Signed Object Types, Set of Signed Attributes . . . . . . . . 10
5. Keys and Certificates used for Signature and Verification . . 11 5. Keys and Certificates used for Signature and Verification . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Objects stored in resource databases, like the RIPE DB, are generally Objects stored in resource databases, like the RIPE DB, are generally
protected by an authentication mechanism: anyone creating or protected by an authentication mechanism: anyone creating or
modifying an object in the database has to have proper authorization modifying an object in the database has to have proper authorization
to do so, and therefore has to go through an authentication procedure to do so, and therefore has to go through an authentication procedure
(provide a password, certificate, e-mail signature, etc.) However, (provide a password, certificate, e-mail signature, etc.) However,
for objects transferred between resource databases, the for objects transferred between resource databases, the
authentication is not guaranteed. This means when downloading an authentication is not guaranteed. This means when downloading an
skipping to change at page 4, line 27 skipping to change at page 4, line 9
Mandatory fields of the "signature" attribute: Mandatory fields of the "signature" attribute:
1. Version number of the signature (field "v"). This field MUST be 1. Version number of the signature (field "v"). This field MUST be
set to "1". set to "1".
2. Reference to the certificate corresponding to the private key 2. Reference to the certificate corresponding to the private key
used to sign this object (field "c"). This is a URL of type used to sign this object (field "c"). This is a URL of type
"rsync" or "http(s)" that points to a specific resource "rsync" or "http(s)" that points to a specific resource
certificate in an RPKI repository. The value of this field MUST certificate in an RPKI repository. The value of this field MUST
be an "rsync://..." or an "http[s]://..." URL. Any non URL-safe be an "rsync://..." or an "http[s]://..." URL. Any non URL-safe
characters (including semicolon ";" and plus "+") must be URL characters (including semicolon ";" and plus "+") must be URL
encoded. encoded.
3. Signature method (field "m"): what hash and signature algorithms 3. Signature method (field "m"): what hash and signature algorithms
were used to create the signature. The allowed algorithms which were used to create the signature. The allowed algorithms which
can be used for the signature are specified in [RFC6485]. can be used for the signature are specified in [RFC6485].
4. Time of signing (field "t"). The format of the value of this 4. Time of signing (field "t"). The format of the value of this
field is the number of seconds since Unix EPOCH (00:00:00 on field is the number of seconds since Unix EPOCH (00:00:00 on
January 1, 1970 in the UTC time zone). The value is expressed as January 1, 1970 in the UTC time zone). The value is expressed as
skipping to change at page 7, line 18 skipping to change at page 7, line 5
The notion of canonicalization is essential to digital signature The notion of canonicalization is essential to digital signature
generation and validation whenever data representations may change generation and validation whenever data representations may change
between a signer and one or more signature verifiers. between a signer and one or more signature verifiers.
Canonicalization defines how one transforms an a representation of Canonicalization defines how one transforms an a representation of
data into a series of bits for signature generation and verification. data into a series of bits for signature generation and verification.
The task of canonicalization is to make irrelevant differences in The task of canonicalization is to make irrelevant differences in
representations of the same object, which would otherwise cause representations of the same object, which would otherwise cause
signature verification to fail. Examples of this could be: signature verification to fail. Examples of this could be:
o data transformations applied by the databases that host these 1. data transformations applied by the databases that host these
objects (such as notational changes for IPv4/IPv6 prefixes, objects (such as notational changes for IPv4/IPv6 prefixes,
automatic addition/modification of "changed" attributes, etc.) automatic addition/modification of "changed" attributes, etc.)
o the difference of line terminators across different systems. 2. the difference of line terminators across different systems.
This means that the destination database might change parts of the This means that the destination database might change parts of the
submitted data after it was signed, which would cause signature submitted data after it was signed, which would cause signature
verification to fail. This document specifies strict verification to fail. This document specifies strict
canonicalization rules to overcome this problem. canonicalization rules to overcome this problem.
The following steps MUST be applied in order to achieve canonicalized The following steps MUST be applied in order to achieve canonicalized
representation of an object, before the actual signature representation of an object, before the actual signature
(verification) process can begin: (verification) process can begin:
skipping to change at page 12, line 46 skipping to change at page 13, line 46
Autonomous System (AS) Numbers", RFC 5396, December 2008. Autonomous System (AS) Numbers", RFC 5396, December 2008.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010. Address Text Representation", RFC 5952, August 2010.
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
Use in the Resource Public Key Infrastructure (RPKI)", Use in the Resource Public Key Infrastructure (RPKI)", RFC
RFC 6485, February 2012. 6485, February 2012.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, X.509 PKIX Resource Certificates", RFC 6487, February
February 2012. 2012.
Authors' Addresses Authors' Addresses
Robert Kisteleki Robert Kisteleki
Email: robert@ripe.net Email: robert@ripe.net
URI: http://www.ripe.net URI: http://www.ripe.net
Brian Haberman Brian Haberman
Johns Hopkins University Applied Physics Lab Johns Hopkins University Applied Physics Lab
Phone: +1 443 778 1319
Email: brian@innovationslab.net Email: brian@innovationslab.net
 End of changes. 12 change blocks. 
34 lines changed or deleted 33 lines changed or added

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