Subject: Re: [sidr] I-D Action: draft-ietf-sidr-origin-ops-18.txt

From: Stephen Kent <[email-masked]>
Date: Thu, 02 Aug 2012 19:51:03 -0400

Randy,

I would like to add some more text, based on discussions with RP 
software developers,
e.g., Rob and Andrew, and an analysis of a couple of SIDR RFCs

RFC 6486 (TAL) states that no manifest will enumerate the self-signed 
certificate
representing a trust anchor. RFC 6487 (Repository Structure) says that 
every signed
object at a publication point is enumerated in the manifest published for a
publication point. Thus the self-signed certificate representing a trust 
anchor MUST NOT
be stored in a repository publication point. It is stored in a file 
independent of
repository publication points, and pointed to by the URI in the TAL. 
This file may be
stored on the same server(s) that are used to store repository 
publication points.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 3 Aug 2012 09:20:22 -0700

Hi Steve,

On 2 Aug 2012, at 16:51, Stephen Kent wrote:

> Randy,
> 
> I would like to add some more text, based on discussions with RP software developers,
> RFC 6486 (TAL) states that no manifest will enumerate the self-signed certificate
> representing a trust anchor.

I think I missed this one.

Can you explain why this is?

I understand that we have the subjectPublicKeyInfo to verify that the self-signed cert has possession of the self signed key pertaining to this public key that we trust.

However the setup where we re-fetch this actual certificate was intended to allow that the contents of this certificate could be updated in particular wrt the resource extensions. If we have it on a manifest as well that will actually give RPs the opportunity to verify that they see a 'current' version of this cert and not an old one that is being replayed to them.

So in short: I don't understand why it 'MUST' *not* be on the manifest. There is no normative MUST in the text of TAL (6490). And I think there is a actually a better case for including it on the manifest..

> RFC 6487 (Repository Structure) says that every signed
> publication point. Thus the self-signed certificate representing a trust anchor MUST NOT
> be stored in a repository publication point. It is stored in a file independent of
> repository publication points, and pointed to by the URI in the TAL. This file may be
> stored on the same server(s) that are used to store repository publication points.
> 

I take it that this is in your view(s) a logical consequence of the first part of your mail?

In other words if there is no MUST not be on manifest, and it actually *is* on the manifest it can be in this publication point.

Tim

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Aug 2012 16:47:32 -0400

Tim,
> Can you explain why this is?
It never occurred to me that one would want to store the ss-cert at a 
repository pub point, vs. storing it in a file independent of the 
repository structure. BBN SW developers talked with ARIN developers and 
learned that ARIN was planing to do this, which caused me to do homework 
to see if I could find references in SIDR RFCs to support my intuition. 
That's when I found several specific statements that indicate that such 
storage is not compliant with SIDR RFCs.
> However the setup where we re-fetch this actual certificate was intended to allow that the contents of this certificate could be updated in particular wrt the resource extensions. If we have it on…
The TAL RFC calls for "re-fetching" the ss-cert, but that is done via 
the URI in the TAL, not via the RPKI repository walk, which starts from 
the SKI in this ss-cert. I agree that, if the ss-cert were stored in a 
pub point one could check the manifest too, but that runs counter to the 
TAL RFC, and to other RFCs, as I note below.
> So in short: I don't understand why it 'MUST' *not* be on the manifest. There is no normative MUST in the text of TAL (6490). And I think there is a actually a better case for including it on the m…
Section 2.2 of RFC 6490 (TA:) says:

Because the trust anchor is a self-signed certificate, there is no
corresponding CRL that can be used to revoke it, *nor is there a
manifest [RFC6486] that lists this certificate.*

I think this is a pretty clear MUST NOT, even though the 2119 terms are 
not present. Sam Weiler was the principal author of the TAL RFC, so it 
my make sense to ask him about the intent of this statement.
> In other words if there is no MUST not be on manifest, and it actually *is* on the manifest it can be in this publication point.

First, there is the equivalent of a MUST NOT in RFC 6490, as noted above.

Second, if we look at RFC 6481 (repository structure), Section 2 says:

Additionally, a certificate's Authority Information Access (AIA) 
extension contains a URI that references the authoritative location for 
the CA certificate under which the given certificate was issued.

Every CA certificate in a pub point contains a back pointer to a 
location where the issuer of that CA certificate is located, except if 
one stores a self-signed certificate at a pub point. A self-signed 
certificate MUST NOT contain an AIA extension or a CRLDP (RFC 6487, 
4.8.7, 4.8.6). Thus storing a ss-cert at normal pub points seems odd, 
since that cert cannot contain the AIA back pointer.

A "normal" repository pub point contains a CRL, a manifest, subordinate 
CA certs and other signed products, e.g., ROAs.
If one were to place the ss-cert at a "normal" pub point, there would be 
no CRL, because that cert has no parent and it never appears on a CRL 
(see Section 2.2 from RFC 6490, as cited above). So storing this ss-cert 
in a normal pub point seems inconsistent with both RFC 6481 and 6490.

All certificates contain an SIA extension, even self-signed 
certificates. As noted in 6487:

This URI points to the directory containing all published material 
issued by this CA, i.e., all valid CA certificates, published EE 
certificates, the current CRL, manifest, and signed objects validated 
via EE certificates that have beenissued by this CA [RFC6481].

Thus the SIA in the self-signed certificate should point to the pub 
point for the CRL it issued, the associated manifest, and objects 
verifiable under that certificate.But if the ss-certificate is in the 
same pub point as these signed products, this implies a circular 
reference, which seems odd.

Also note that every file at a pub point has a three-character extension 
identifying the content of the file. Certificates are stored in files 
marked as ".cer" So, one cannot tell a self-signed certificate from a 
regular certificate by looking at the file extension. Thus, when 
processinga set of .cer files from a pub point, a self-signed 
certificate will be initially appear like all of the others. Thus, only 
when processing the certificates will its special nature be detected. 
This seems to impose undue complexity for RPs.

The manifest and repository RFCs describe what a "normal" pub point 
contains, and that does not seem to be compatible with having an ss-cert 
in such a pub point.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 07 Aug 2012 10:36:15 -0400

Tim,

Another thought re where (not) to place the ss-cert to which a TAL points.

An RPKI repository pub point contains a CRL. That CRL contains serial 
numbers for certs
that were published at this pub point, or that were embedded in objects 
at this pub point
The ss-cert will never be on a CRL (this is true for TAs in general, and 
is explicitly
mentioned in the TAL RFC). So, publishing this cert at a pub point is 
inconsistent with
the general RPKI model as it is outside the scope of the CRL at that pub 
point.

Steve