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

From: Alberto Leiva <[email-masked]>
Date: Mon, 7 Feb 2022 16:49:45 -0600

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

---

From: "Di Ma" <[email-masked]>
Date: Tue, 8 Feb 2022 18:09:00 +0800

Albeto,

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?

 

 

 

 

 

 

 

 

 

Thanks in advance,
Alberto
 
_______________________________________________
Sidrops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidrops

---

From: Stephen Kent <[email-masked]>
Date: Tue, 8 Feb 2022 13:19:26 -0500

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

> As far as I am concerned, subject name of RPKI certificate is not used 
> for identification, which is different from those in web PKI.
>
>     *From:* Alberto Leiva <mailto:[email-masked]>
>     *Date:* 2022-02-08 06:49
>     *To:* sidrops <mailto:[email-masked]>
>     *Subject:* [Sidrops] What should an RP do on different public key,
>     same subject name?

---

From: Alberto Leiva <[email-masked]>
Date: Wed, 9 Feb 2022 13:44:57 -0600

Ok. Thank you both, very much.

On Tue, Feb 8, 2022 at 12:20 PM Stephen Kent
<stephen.kent=[email-masked]> wrote:
> 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
>
>
>