[DBWG] Nonconformant X.509 issuer+subject names in some Afrinic RPKI CA/EE certs

[Frank Habicht]

Thank you James.
Frank

On 12/16/2025 5:04 PM, James Chirwa wrote:
> Dear Frank,
> 
> We take note of the points you have raised and consider them to be valid.
> 
> A summary of the feedback is provided below:
> 
> The action plan will include communication to the affected members, 
> primarily to avoid causing force alarms, while also allowing those who 
> wish to undertake the required steps independently to do so. This will, 
> however, be timebound.
> 
> To achieve the objective of revoking all non-comforming certificates, 
> the majority of the revocation and re-keying will eventually be carried 
> out by staff.
> 
> We are currently working on the action plan and defining appropriate 
> timelines for execution, which we expect to share in January.
> 
> Regards,
> 
> James
> 
> On 16/12/2025 09:59, Frank Habicht wrote:
>> Dear Yogesh, whole WG,
>>
>> <nohat>
>>
>> please see inline...
>>
>> On 12/15/2025 5:45 AM, Yogesh Chadee via DBWG wrote:
>>> Dear Mr Snijders,
>>>
>>> I hope this email finds you well.
>>>
>>> While we understand that a quick resolution is favourable for 
>>> everyone, we believe it would be wise to ensure Certificate holders 
>>> are aware of the issue first.
>>
>> agreed.
>>
>>> Re-issuing a Certificate of a person who is unaware of the situation, 
>>> without prior consent, could have undesired consequences.
>>
>> At this place I would like to ask to be more specific. What consequences?
>>
>> I believe resource holders can end up with a certificate that they 
>> didn't have before. that they didn't create *themselves*. but it 
>> should reflect the intention of the resource holder when they created 
>> the initial certificate. And it should have the same properties.
>>
>>
>>> If this method does not yield the desired results, 
>>
>> Here I would like to get clarification about what time-line we look at 
>> for finding out whether the desired results materialised.
>> I believe when we rely on resource holder action, we have to expect a 
>> "long tail" and a small percentage of ROAs will not be deleted and re- 
>> issued, because of various reasons.
>> How long should software developers keep work-arounds?
>> Why should they keep them even now?
>> Exposing the incorrect data might give much more incentive for 
>> resource holders to take action...
>>
>>> AFRINIC will then consider a quicker resolution, having completed the 
>>> necessary information campaign.
>>
>> If AfriNIC relies on an information campaign....
>> ... has it started or when will it start?
>>
>> I personally still think that there is less risk, faster resolution, 
>> more certainty if AfriNIC could re-issue the certificates in question.
>>
>> If useful, AfriNIC could probably get (informal) support from external 
>> sources when considering the best methodology.
>>
>> It will be good to inform resource holders as objects are changed.
>> But this will be (i believe) much less effort than the above mentioned 
>> "information campaign". Which will not be needed if AfriNIC decides to 
>> *correct* the RPKI data on its own initiative.
>>
>> I understand that we got to this situation *not* because of any fault 
>> of AfriNIC part, nor on resource holders. But AfriNIC has the 
>> opportunity to "go the extra mile" and support resource holders more 
>> than absolutely necessary.
>>
>> Others are doing unilateral changes to improve database consistency as 
>> well - e.g. "RIPE-NONAUTH" cleanup.
>>
>> It's a way of proactively doing something "for the good of the internet".
>> And to be honest, in my personal opinion, if this is not done, it will 
>> be harder for AfriNIC to credibly claim to do all that's needed to 
>> support RPKI adoption.
>>
>> All of this just my personal opinion without any hat.
>>
>> Regards,
>> Frank Habicht
>>
>>
>> _______________________________________________
>> DBWG mailing list
>> DBWG at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/dbwg
>