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

Thu Jan 29 13:40:28 UTC 2026

Dear All,

As indicated in the previous communication, an action plan has been 
established to address and eliminate the identified non-conformant 
certificates.

The plan is designed to ensure that no unnecessary alarms are raised and 
that potential conflicts are avoided. It will be implemented in phases, 
with clearly defined activities and timelines, as outlined below.

*Phase 1: Awareness & Self-Remediation (DIY) (2 months)*

  * Activity: Direct communication to affected members, including a
    clear problem statement and a step-by-step “How-To” guide.

  * Support: Weekly helpdesk calls will be available to assist members.

  * Goal: Enable the majority of active members to independently correct
    their own ROAs

*Phase 2: Assisted Correction (2 Months)*

  * Activity: Targeted follow-ups with members who have not responded or
    taken action.

  * Mechanism: i. Members can authorise AFRINIC to perform the "Create
    New / Revoke Old" action for them.

                             ii. Revoke non-conformant ROAs that do not 
have matching routes in the Default Free Zone

  * Support: Continued helpdesk availability.

*Phase 3: Final Deadline & Clean-up (2 Months )*

  * Activity: Issuance of final notices to members who have not taken
    any corrective action.

  * Action: Revocation of all remaining non-conformant ROAs, followed by
    the creation of new, compliant ROAs where applicable.

The overall activity is planned for a maximum duration of six (6) 
months. However, we anticipate that execution may be completed sooner, 
as phases may be fast-tracked wherever possible.

We plan to commence this activity shortly, with final completion no 
later than 31 July.

Regards,

James

We will be kickstart this activity shortly will a closing date of 31st 
July, latest.

Regards,

On 16/12/2025 20:52, Frank Habicht wrote:
> 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
>>
>
-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/dbwg/attachments/20260129/b975e818/attachment.html>