> On 3 Dec 2015, at 5:24 PM, Declan Ma <m...@zdns.cn> wrote: > > > > > >> 在 2015年12月2日,18:23,Geoff Huston <gih...@gmail.com> 写道: >> >> >> >> Example 2: >> >> A CA Cert: 1.0.0.0/24, 2.0.0.0/24 >> >> issues: >> >> B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24 >> >> issues: >> >> C EE Cert: 1.0.0.0/24, 2.0.0.0/24 >> >> and signs >> >> ROA: 1.0.0.0/24 AS1 >> >> still all good (assuming that A is a trust anchor) >> >> Example 3: >> >> A CA Cert: 1.0.0.0/24, 2.0.0.0/24 >> >> issues: >> >> B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24 >> >> issues: >> >> C EE Cert: 1.0.0.0/24, 3.0.0.0/24 >> >> and signs >> >> ROA: 1.0.0.0/24 AS1 >> >> still all good (assuming that A is a trust anchor) > > Geoff, > > > In section 2.3 of RFC 6480, the very text says: > > For ROAs and manifests, there will be a one-to-one correspondence > between end-entity certificates and signed objects, i.e., the private > key corresponding to each end-entity certificate is used to sign > exactly one object, and each object is signed with only one key. > > > Due to the so-called one-to-one, why bother to create an EE cert that has > more INR than its corresponding ROA? > > Sorta confused. >
I have no idea why either - but - the specs don’t say that the resources listed in the EE cert must exactly match the resources in the ROA, so its possible for the EE cert to have a larger number resource set than the ROA. regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr