I find this document to be very puzzling.
The introduction includes some allusions to the local TA management
talks that I have made to the SIDR WG (without attribution), but the
text contained in this section is inconsistent with the local TA
management model I have described.
The introduction also talks about attacks on trust anchors, but the
arguments are incorrect, e.g., they fail to acknowledge that TAs are
to be distributed out-of-band via secure channels.
The fundamental notion put forth here appears to be a form of
internal consistency check that can be performed on a self-signed TA
cert, based on generation of the TA's (issuer) name from an IP
address (v4 or v6) or an rfc1822 name. The stated goal (see section
6) is to somehow protect the issuer name of a TA: "Since the issuer
name is generated from the key pair, and the certificate is signed
[sic] using the key pair, the attacker can not be able to declaim
that the issuer name belongs to it." This suggests a fundamental
misunderstanding of TA concepts.
This makes no sense to me, in several ways:
- a TA represented by a self-signed cert has the same name
for the subject and issuer, so references to the issuer name only are
odd, at best.
- resource certs are specified to NOT make use of alternative
names, so there is no place for an rfc1822 name in such a cert
- resource certs for TAs would contain prefixes, not
individual addresses, so there would be no individual v4 or v6
address to use in the algorithm described in section 2.1.
A self-signed cert already has a consistency check, based on the fact
that the public key contained in the cert must be able to be used to
verify the signature on the cert. Because issuer and subject names
in the RPKI are not intended to be human meaningful, it is not clear
why there is a need to "secure" in some fashion that issuer name in a
TA cert.
Section 2.1 presents an algorithm that appears to be derived from the
CGA algorithm described in RFC 3971. This makes no sense. For
example, step 6 talks about duplicate address detection, yet this
document is describing how to generate an issuer name for a cert, not
an IPv6 address to be used in a network!
Section 3.1 references the SIDR-TA I-D, but fails to indicate which
form of TA (ETA or RPKI TA) the authors believe would benefit from
use of this technique.
Section 3.2 has a cryptic description of an extension (not using
ASN.1), used to contain a 256-bit random number that is employed in
the name generation algorithm (section 2.1).
None of this makes any sense to me in the SIDR context. Maye the lack
of references to the resource cert profile
(draft-ietf-sidr-res-certs-17) is indicative of the serious
disconnect I see here.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
