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

[Alberto Leiva <[e-mail]>]

Ok. Thank you both, very much.

On Tue, Feb 8, 2022 at 12:20 PM Stephen Kent
<stephen.kent=[e-mail]> wrote:
>
> Let me provide some context and further explanation.
>
> The requirement that a Subject name be unique on a per-CA basis is intrinsic to X.509, modulo re-keying of the Subject, i.e., a Subject can acquire a new key pair and keep the same Subject name under the same CA. If this requirement were not met there would be obvious, adverse security issues. This is what is mandated by X.509 and by IETF PKI standards.
>
> In general purpose PKis this requirement cannot be verified by RPs, since an RP is not expected to retrieve and verify all certs issued by a CA. In the RPKI every RP is expected to retrieve all certs issued by a CA, but I don't recall an explicit requirement that an RP check for Subject name uniqueness, per se.
>
> RFC 6487, Section 4.5 says that during re-keying a CA SHOULD change the Subject name (to preserve uniqueness). I agree that this SHOULD (vs. a MUST)  creates confusion. I would prefer a MUST here, but I guess Geoff had some reason to allow a CA to not always follow the guidance.  It could cause confusion for an RP that encountered two CA certs with the same Subject name but different keys, hence the admonition to change Subject names during re-key. Because 6487 allows for an exception to this general rule, the text you cited later in Section 4.5 qualifies uniqueness to include both Subject name and public key. I agree that this discussion, all within one paragraph, is confusing.
>
> Steve
>
>
>
> Good catch of inconsistence of requiements on subject name of RPKI certificate.
>
> As far as I am concerned, subject name of RPKI certificate is not used for identification, which is different from those in web PKI.
>
> With this understanding, FYI, RPSTIR2 currently does not check the uniqueness of subject name neither.
>
> Di
>
>
> From: Alberto Leiva
> Date: 2022-02-08 06:49
> To: sidrops
> Subject: [Sidrops] What should an RP do on different public key, same subject name?
> 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
>
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops
>
>
>
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops
>
>
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops