Monday, May 23, 2011

RPKI certificates

Resource certificates are defined in the SIDR resource certificate profile specification. In this second part of the series, we'll start analysing a set of certificates from the AfriNIC repository (rsync:// from the top. We'll visit the trust anchor locator, trust anchor certificate, RIR certificate and an LIR certificate. An important point to note is that each certificate is a CA certificate with the exception of embedded end entity certificates.

Trust Anchor Locator

A trust anchor as a trusted entry point of any PKI is expected to be stable over time. However, the current practice has RIRs running their own roots with their resources specified in the root cert.

If an RIR receives an allocation, they have to issue a new certificate that contains the new resources which will have to be propagated to validators. Taking the case of IPV4, 17 blocks were allocated in a span of a year (2009). This corresponds to 1 trust anchor change every 21 days on average. On top of this, certificates have time constraints which will induce certificate re-issues due to expiry.

The TAL format is specified in the SIDR TA draft to work around these issues. Essentially, the TAL contains the rsync URI of the root certificate with rfc3779 extensions and the public key component of that certificate. These two are separated using a [CR]LF According to the specification, the public key is ``a base 64-encoded, DER-encoded X.509 subjectPublicKeyInfo [RFC5280]''.

It can easily be generated by using shell utilities and OpenSSL.
Since the TAL doesn't have resources and time constraints, It can be long lived requiring change when the key is rolled.

Here is the AfriNIC TAL.

Root certificate

The root certificate sits at the root of the Resource PKI. It contains all the resources suballocated in the tree below it. In an ideal world, there would be the one root certificate and it's number resources would be:
  • 0/0 for IPV4
  • 0/0 for IPV6
  • 1-4294967296 for AS numbers
Unfortunately, in the current structure, each RIR is running it's own root and encoding it's resources only. So for example, the AfriNIC certificate will only contain IANA's allocation to AfriNIC.

In the figure on the first post, the first dashed rectangle represents the root repository. It contains all the certificates issued by the root, a CRL and a manifest for this repository. This structure is replicated across the entire PKI tree that is, each certificate has a repository that is accessible over rsync and contains: 
  • A CRL.
  • A manifest.
  • Zero or more products (ROAs, AAAs...) in it's repository.
  • Certificates for sub CAs.
An example certificate can be seen below. It's highlights are:
  • Self signed which implies that it's a root certificate.
  • The location of the repository and manifest are encoded in the certificate.
  • The certificate has x509 CA extensions (Green sections).
  • Has rfc3779 extensions (sbgp-* sections). 
AfriNIC root certificate

Resource certificate

The root certificate is a special case of the resource certificate. A non root resource certificate has:
  • A parent - Authority Information Access in a certificate.
  • Zero or more children - Subject Information Access is a pointer to a store with this certificate's children.
  • Zero or more - Subject Information Access also points to a store with this certificate's products. products. 

 An example tree is shown below. In this case, the root certificate shown above issues the RIR certificate in figure below which in turn issues the LIR certificate in the last figure. Please note that relationship between the certificates as indicated by the colour coding.

RIR Certificate

LIR Certificate

No comments:

Post a Comment