[DBWG] Nonconformant X.509 issuer+subject names in almost all Afrinic RPKI CA/EE certs?
Job Snijders
job at fastly.com
Tue Feb 27 18:50:39 UTC 2024
Dear Afrinic,
Perhaps adding "string_mask = nombstr" to the "[req]" section of the
openssl.cnf file pointed to by the '-config' CLI option is sufficient
to - going forward - only emit PrintableString instead of UTF8String.
https://www.openssl.org/docs/man3.0/man1/openssl-req.html#string_mask
Kind regards,
Job
On Tue, Feb 27, 2024 at 11:03:51AM +0100, Job Snijders wrote:
> 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
More information about the DBWG
mailing list