> 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

Reply via email to