hi tim,
thanks for reading and commenting.
> 1. Is this sort of bad-practice use of RPKI keypairs actually
> occurring?
a few years back, two of the co-authors of a lot of sidr rfcs, working
at apnic (supposedly a prudent steward of the net infra), put up a "sign
arbitrary blob" service, with no warnings of the semantics. one of them
just wrote to say he thought 6480 was sufficient; which pretty much says
it all.
and early drafts and discussions of the first two informative references
[I-D.ietf-sidrops-rpki-rsc]
Snijders, J., Harrison, T., and B. Maddison, "Resource
Public Key Infrastructure (RPKI) object profile for Signed
Checklist (RSC)", Work in Progress, Internet-Draft, draft-
ietf-sidrops-rpki-rsc-06, 12 February 2022,
<https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-
rsc-06.txt>.
[I-D.ietf-sidrops-rpki-rta]
Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels,
T., and M. Hoffmann, "A profile for Resource Tagged
Attestations (RTAs)", Work in Progress, Internet-Draft,
draft-ietf-sidrops-rpki-rta-00, 21 January 2021,
<https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-
rta-00.txt>.
brought to light massive misunderstanding and misrepresentation, despite
6480
> this mis-use of RPKIs and the purpose of
> draft-ietf-sidrops-rpki-has-no-identity is to give reviewers an extra
> leg to stand on when saying "Don't do that".
more operators and implementors than ietf reviewers. this is from an
ops area wg.
> Which seems reasonable but shouldn't be necessary?
sad to say, it seems to be.
> I grant that it might be effective in suppressing this bad practice in
> I-Ds but 6480 seems pretty clear to me.
tl;dr: ibid
long: tragic to say, but a long line of trucks have been driven through
6480. this aspect is merely one. the code and operations providing
rpki infrastructure and its use is not what you want to tell your mom
about.
> 3. The single MUST assertion being repeated twice is unnecessary.
>
> 4. The MUST assertion feels unnecessarily complicated and
> long-winded. I think what they're trying to say is "You MUST NOT
> perform PKI operations with these certs except exactly as described,
> and for the purposes described, in 6480.”
will take those on.
> 5. The discussion in section 3 about how the holders of RPKI keys
> probably don't issue their own certs but get CAs to do that left me a
> bit puzzled. Is the conclusion that we should admonish CAs not to do
> this? Or is it the case that some key-holders do issue their own
> certs but are Being Bad?
both. operationally, there are two paths of issuance. the RIRs provide
"hosted" service, where their customers have no mechanics and merely use
the RIR's web or api interfaces. in the "delegated" version of the
service, the RIR issues the base cert for the registrant's resources,
with the SIA pointing to the registrant's repository, and the registrant
CA issues whatever from there.
> 6. Section 3 is kind of long and discursive and could likely be
> shortened without loss of value. The document might be more useful if
> there were subsection 3.1 Issuers of RPKI certificates, 3.2
> Organizational issues, etc
>
> It should be obvious that I don't understand whether there's a
> bad-practice problem out there
has been tiny, but was threatening to be large. the discussion of this
draft in the wg has helped ameliorate the fantasies considerably.
> [It is also possibly the case that those better acquainted with RPKI
> will instantly understand what the problem is and why the language
> herein will help deal with it, in which case feel free to ignore most
> of my comments. ]
others will be more eloquent. steve for example
https://mailarchive.ietf.org/arch/msg/sidrops/V5OHy_p0po6VmAYFxjK3Wz_2lLI/
or our esteemed AD, to qute him,
> I must admit that I *wanted* to / felt I should be able to use the
> RPKI to do things like sign LOAs and similar "the RIR says I'm the
> 'owner', seem mah cert!" type things, and so, even though the document
> makes me sad, it's useful and needed.
and, as usual, ben is articulate, see
https://mailarchive.ietf.org/arch/msg/sidrops/93mFbfcBFfngb90MGeR7VaAD28g/
randy
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
