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

[James Chirwa]

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

-- 
James Chirwa
Head of Member Services
African Network Information Centre (AFRINIC) Limited
t: +230 403 51 00 | dir: +230 403 51 42
f: +230 466 6758
w: www.afrinic.net | tt: @afrinic
SM: facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia