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

[Job Snijders]

Dear AFRINIC,

Almost a year has passed and the AFRINIC RPKI Certification Authority
implementation still does not conform to the RFC standards. :-(

I'm sympathetic to backlogs and it being busy times, but I suspect
changing 'UTF8String' to 'PrintableString' should merely be a matter
changing a handful of lines of code.

I must insist on this matter, because in validator code granting an
exception to AFRINIC's CA, means granting an exception to all RPKI
CAs. This specific nonconformance issue is holding back the entirety of
the ecosystem.

Kind regards,

Job

On Fri, Mar 17, 2023 at 10:37:03AM +0400, Yogesh Chadee wrote:
> Good morning.
> 
> Thank you very much for the detailed explanation, references, and the test
> case.
> 
> We would like to advise that we are working to resolve this bug as soon as
> possible and we will advise this list once it is resolved.
> 
> Best regards,
> 
> Yogesh Chadee
> 
> AFRINIC
> 
> 
> On 16/03/2023 22:53, Job Snijders via DBWG wrote:
> > Dear all,
> > 
> > While reading RFC 6487 section 4.5, I noticed that all CA certificates
> > representing Afrinic members under the Afrinic trust anchor appear
> > nonconformant with regard to the constraints imposed on the X.509 Subject
> > field.
> > 
> > The issue at hand is that the Subject name contains a distinguished name
> > which contains an instance of the CommonName attribute, which MUST be
> > encoded using the ASN.1 type 'PrintableString'. However, in the case of
> > Afrinic's Hosted RPKI solution, all such instances are encoded as
> > UTF8String. No need for emoji's in this particular data field! :-)
> > 
> > I think the solution would be to change the issurance code that produces
> > value of the Subject - to use PrintableString instead of UTF8String, and
> > then re-issue all CA certificates and Signed Objects.
> > 
> > As far as I can see, the Afrinic RPKI platform is the only system in the
> > global ecosystem which produces nonconformant issuer & subject names in
> > this particular way; therefor a resolution to this issue would allow all
> > Relying Party implementations to impose more strigent conformity checks
> > after this has been resolved.
> > 
> > Kind regards,
> > 
> > Job
> > 
> > References:
> > Specification: https://www.rfc-editor.org/rfc/rfc6487.html#section-4.5
> > Another observation point: http://validator.afrinic.net/rpki/rcynic/rpki.afrinic.net.html
> >                 ("Nonconformant X.509 issuer name" and "Nonconformant X.509 subject name")
> > 
> > ps, one example:
> > 
> > $ openssl asn1parse -in rpki.afrinic.net/repository/afrinic/muu9NJ1kyzF42IIOBBzyKn9pnok.cer -inform der -i -strparse 135
> >      0:d=0  hl=2 l=  72 cons: SEQUENCE
> >      2:d=1  hl=2 l=  19 cons:  SET
> >      4:d=2  hl=2 l=  17 cons:   SEQUENCE
> >      6:d=3  hl=2 l=   3 prim:    OBJECT            :commonName
> >     11:d=3  hl=2 l=  10 prim:    UTF8STRING        :F366EFDFAF       <#### ERROR, should be PRINTABLESTRING
> >     23:d=1  hl=2 l=  49 cons:  SET
> >     25:d=2  hl=2 l=  47 cons:   SEQUENCE
> >     27:d=3  hl=2 l=   3 prim:    OBJECT            :serialNumber
> >     32:d=3  hl=2 l=  40 prim:    PRINTABLESTRING   :9AEBBD349D64CB3178D8820E041CF22A7F699E89
> > 
> > _______________________________________________
> > DBWG mailing list
> > DBWG at afrinic.net
> > https://lists.afrinic.net/mailman/listinfo/dbwg
> 
> _______________________________________________
> DBWG mailing list
> DBWG at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/dbwg