Tim,
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,
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.
I think I missed this one.
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 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.
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 manifest..
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.
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.
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.
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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
