A profile for Resource Public Key Infrastructure (RPKI) Signed Checklists (RSC)
Fastly
4101
Australia
QLD
tomh@apnic.net
Workonline Communications
Cape Town
-
MUST contain only characters specified in the Portable Filename Character Set as defined in .
-
MUST be unique with respect to the other FileNameAndHash elements of checkList for which the fileName field is also present.
Conversely, if the fileName field is omitted, then the value of the hash field MUST be unique with respect to the other FileNameAndHash elements of checkList for which the fileName field is also omitted.
RSC Validation
Before a Relying Party can use an RSC to validate a set of digital objects, the Relying Party MUST first validate the RSC.
To validate an RSC, the Relying Party MUST perform all the validation checks specified in (except checking for the presence of a SIA extension, which MUST NOT be present in the EE X.509 certificate ), and perform the following additional RSC-specific validation steps:
-
The contents of the CMS eContent field MUST conform to the constraints described in . In particular, for each FileNameAndHash element in the checkList field, its contents MUST conform to the constraints described in .
-
If the asID field is present within the contents of the resources field, then the AS Resources extension MUST be present in the EE certificate contained in the CMS certificates field. The AS identifiers present in the resources field MUST be a subset of those present in the certificate extension.
-
If the ipAddrBlocks field is present within the contents of the resources field, then the IP Resources extension MUST be present in the EE certificate contained in the CMS certificates field. The IP address resources present in the resources field MUST be a subset of those present in the certificate extension.
Verifying files or data using RSC
To verify a set of digital objects with an RSC:
-
The RSC MUST be validated acording to the procedure described in . If the RSC cannot be validated, verification MUST fail and the error SHOULD be reported to the user.
-
For every digital object to be verified:
-
If the verification procedure is provided with a file name for the object being verified (e.g. because the user has provided a file system path from which to read the object) then verification SHOULD proceed in "filename-aware" mode. Otherwise, verification SHOULD proceed in "filename-unaware" mode.
Implementations MAY provide an option to override the verification mode, for example to ignore the fact that the object is to be read from a file.
-
The message digest MUST be computed from the file contents or data using the digest algorithm specified in the digestAlgorithm field of the RSC.
-
The digest computed in step MUST be compared to the value appearing in the hash field of all FileNameAndHash elements of the checkList field of the RSC.
One or more FileNameAndHash elements MUST be found with a matching hash value, otherwise verification MUST fail and the error SHOULD be reported to the user.
-
If the mode selected in step is "filename-aware" then exactly one of the FileNameAndHash elements matched in step MUST contain a fileName field value exactly matching the file name of the object being verified.
Alternatively, if the mode selected in step is "filename-unaware" then exactly one of the FileNameAndHash elements matched in step MUST have the fileName field omitted.
Otherwise, verification MUST fail, and the error SHOULD be reported to the user.
Note that in the above procedure, not all elements of checkList necessarily need be used. That is, it is not an error if the length of checkList is greater than the size of the set of digital objects to be verified. However, in this situation, implementations SHOULD issue a warning to the user, allowing for corrective action to be taken if necessary.
Operational Considerations
When creating digital objects of a plain-text nature (such as ASCII, UTF-8, HTML, Javascript, XML, etc) it is RECOMMENDED to convert such objects into a lossless compressed form.
Distributing plain-text objects within a compression envelope (such as GZIP) might help avoid unexpected canonicalization at intermediate systems (which in turn would lead to checksum verification errors).
Validator implementations are expected to treat a checksummed digital object as string of arbitrary single octets.
If a fileName field is present, but no referenced digital object has a filename that matches the content of that field, a validator implementation SHOULD compare the message digest of each digital object to the value from the hash field of the associated FileNameAndHash, and report matches to the client for further consideration.
Security Considerations
Relying parties are hereby warned that the data in a RPKI Signed Checklist is self-asserted.
When determining the meaning of any data contained in an RPKI Signed Checklist, Relying Parties MUST NOT make any assumptions about the signer beyond the fact that it had sufficient control of the issuing CA to create the object.
These data have not been verified by the Certificate Authority (CA) that issued the CA certificate to the entity that issued the EE Certificate used to validate the Signed Checklist.
RPKI Certificates are not bound to real world identities, see for an elaboration.
Relying Parties can only associate real world entities to Internet Number Resources by additionally consulting an exogenous authority.
Signed Checklists are a tool to communicate assertions 'signed with Internet Number Resources', not about any other aspect of the resource holder's business operations such as the identity of the resource holder itself.
RSC objects are not distributed through the RPKI Repository system.
From this, it follows that third parties who do not have a copy of a given RSC, may not be aware of the existence of that RSC.
Since RSC objects use EE Certificates, but all other currently defined types of RPKI object profiles are published in public CA repositories, an observer may infer from discrepancies in the Repository that RSC object(s) may exist.
For example, if a CA does not use random serial numbers for Certificates, an observer could detect gaps between the serial numbers of the published EE Certificates.
Similarly, if the CA includes a serial number on a CRL that does not match any published object, an observer could postulate an RSC EE Certificate was revoked.
Conversely, a gap in serial numbers does not imply that an RSC exists.
Nor does an arbitrary (to the RP unknown) serial in a CRL imply an RSC object exists: the implicitly referenced object might not be a RSC, it might never have been published, or was revoked before it was visible to RPs.
In general, it is not possible to confidently infer the existence or non-existence of RSCs from the Repository state without access to a given RSC.
While an one-time-use EE Certificate must only be used to generate and sign a single RSC object, CAs technically are not restricted from generating and signing multiple different RSC objects with a single keypair.
Any RSC objects sharing the same EE Certificate can not be revoked individually.
Implementation status
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942.
The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.
Please note that the listing of any individual implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a catalog of available implementations or their features.
Readers are advised to note that other implementations may exist.
According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as they see fit".
-
A signer and validator implementation written in Perl based on OpenSSL was provided by Tom Harrison from APNIC.
-
A signer implementation written in Python was developed by Ben Maddison.
-
Example .sig files were created by Job Snijders with the use of OpenSSL.
-
A validator implementation based on OpenBSD rpki-client and LibreSSL was developed by Job Snijders.
-
A validator implementation based on the FORT validator was developed by Alberto Leiva for a previous version of this specification.
IANA Considerations
SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)
The IANA has permanently allocated for this document in the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) registry:
Upon publication of this document, IANA is requested to reference the RFC publication instead of this draft.
RPKI Signed Objects sub-registry
The IANA is requested to register the OID for the RPKI Signed Checklist in the registry created by as following:
File Extension
The IANA is requested to add an item for the Signed Checklist file extension to the "RPKI Repository Name Scheme" registry created by as follows:
SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)
The IANA is requested to add an item to the "SMI Security for S/MIME Module Identifier" registry as follows:
Media Type
The IANA is requested to register the media type application/rpki-checklist in the Provisional Standard Media Type registry as follows:
Intended usage: COMMON
Restrictions on usage: None
Author: Job Snijders
Change controller: Job Snijders
]]>
References
Normative References
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
X.509 Extensions for IP Addresses and AS Identifiers
This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK]
Cryptographic Message Syntax (CMS)
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]
A Profile for Resource Certificate Repository Structure
This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK]
Manifests for the Resource Public Key Infrastructure (RPKI)
This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. [STANDARDS-TRACK]
A Profile for X.509 PKIX Resource Certificates
This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK]
Signed Object Template for the Resource Public Key Infrastructure (RPKI)
This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK]
The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure
This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Address Family Numbers
Internet Assigned Numbers Authority
Informative References
A profile for Resource Tagged Attestations (RTAs)
This document defines a Cryptographic Message Syntax (CMS) profile for a general purpose Resource Tagged Attestation (RTA), for use with the Resource Public Key Infrastructure (RPKI). The objective is to allow an attestation, in the form of an arbitrary digital object, to be signed "with resources", and for validation to provide an outcome of "valid with resources". The profile is intended to provide for the signing of an attestation with an arbitrary set of resources.
The I in RPKI does not stand for Identity
Vigil Security
There is a false notion that Internet Number Resources (INRs) in the
RPKI can be associated with the real world identity of the 'owner' of
an INR. This document attempts to put that notion to rest.
GZIP file format specification version 4.3
This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
An Infrastructure to Support Secure Internet Routing
This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes.
signify - cryptographically sign and verify files
A proof-of-concept for constructing and validating RPKI Signed Checklists (RSCs).
APNIC
rpkimancer
Workonline
FORT
LACNIC and NIC.MX
The Open Group's Base Specifications, Issue 7
IEEE and The Open Group
Acknowledgements
The authors wish to thank
George Michaelson,
Geoff Huston,
Randy Bush,
Stephen Kent,
Matt Lepinski,
Rob Austein,
Ted Unangst,
and Marc Espie
for prior art.
The authors thank Russ Housley for reviewing the ASN.1 notation and providing suggestions.
The authors would like to thank
Nimrod Levy,
Tim Bruijnzeels,
Alberto Leiva,
Ties de Kock,
Peter Peele,
Claudio Jeker,
and Theo Buehler
for document review and suggestions.
Document changelog
changes from -07 -> -08
- Theo requested explanation as to why fileName is OPTIONAL
- Russ & Randy requested implementor guidance when RFC3779-generated data fails to decode
- Added uniqueness constraints for fileName and hash contents
- Improved validation and verification procedure description
- Incorporated character-set constraints for fileName in ASN.1 module
changes from -06 -> -07
- Change wire format to allow use of commonly deployed libcrypto APIs.
changes from -05 -> -06
- Non-content-related updates.
changes from -04 -> -05
- Ties contributed clarifications.
changes from -03 -> -04
- Alberto pointed out the asID validation also needs to be documented.
changes from -02 -> -03
- Reference the IANA assigned OID
- Clarify validation rules
changes from -01 -> -02
- Clarify RSC is part of a puzzle, not panacea. Thanks Randy & Russ.
changes from -00 -> -01
- Readability improvements
- Update document category to match the registry allocation policy requirement.
individual submission phase
-
On-the-wire change: the 'Filename' switched from 'required' to 'optional'.
Some SIDROPS Working Group participants proposed a checksum itself is the most minimal information required to address digital objects.