[Sidrops] What should an RP do on different public key, same subject name?

[Alberto Leiva <[e-mail]>]

Hi. I'm maintaining FORT, an RP implementation. I found a validation
FORT seems to be implementing incorrectly, and the RFCs are giving me
trouble. Can I have some advice?

RFC 6487:

> Each distinct subordinate CA and
> EE certified by the issuer MUST be identified using a subject name
> that is unique per issuer. In this context, 'distinct' is defined as
> an entity and a given public key.

Bit awkward for my taste. Removing some redundancy:

> Each distinct subordinate CA and EE certified by the issuer MUST have
> a unique subject name. In this context, 'distinct' is defined as an
> entity and a given public key.

Trimming fat:

> Each distinct child certified by the issuer MUST have a unique
> subject name. In this context, 'distinct' is defined as an entity and
> a given public key.

Translation:

> Sibling certificates MUST have different subject names. Among a
> parent's children, siblings are identified by their [entity, public
> key] tuple.

("Entity" is seemingly not defined by any relevant glossaries [if
you're going to update these documents at some point, might I suggest
this gets fixed], but from RFC 6484, we can surmise it means "INR
Holder.")

The requirement is kind of circular because an entity would normally
be identified by its parent certificate and subject name... right? How
else would an RPKI consumer identify the entity?

Educated guess:

> Sibling certificates MUST have different subject names. Among a
> parent's children, siblings are identified by their [parent, subject
> name, public key] tuple.

Given that we've established that we're talking about siblings, the
parent is always the same, so it becomes

> Sibling certificates MUST have different subject names. Among a
> parent's children, siblings are identified by their [subject name,
> public key] tuple.

Circular because of the double "subject name":

> Given two siblings, if their [subject name, public key] is different,
> then their subject names MUST also be different.

In other words, given sibling certificates A and B, subject names a
and b, public keys m and n, a != b and m != n, then

- If A = [a, m] and B = [a, m], then no constraints must be imposed. (A = B)
- If A = [a, m] and B = [a, n], then a != a. This makes no sense, and
is thus illegal.
- If A = [a, m] and B = [b, m], then a != b. Self-evident.
- If A = [a, m] and B = [b, n], then a != b. Self-evident.

So... assuming my several flights of fancy have so far been correct,
the requirement can be reduced to

> If two sibling certificates have different public keys, then they
> MUST have different subject names as well.

ie. this whole mess is just a reword of the (infinitely more
comfortably articulated) immediately following RFC 6487 sentence:

> An issuer SHOULD use a different subject name if the subject's key
> pair has changed (i.e., when the CA issues a certificate as part of
> re-keying the subject.)

Except... the two requirements are actually contradicting each other:
The former is defined as a MUST and the latter is a SHOULD.

------------------------------

Ok. That established, here's the point:

Would it be reasonable for an RP implementation to trim branches off
the tree if they violate the above rule?
The point of this rule is to prevent broken key rollovers... right? I
think? So, is a bad key rollover grounds to chop pieces off the
Internet?
Does this requirement exist to somehow simplify the work of RPs, or to
be enforced by RPs? Are RPs supposed to care?

I'm thinking about dumping a warning on syslog and keep going, but I'm
not sure there'd be a point to it.

(And which is it? MUST or SHOULD?)

Thanks in advance,
Alberto