nrfcloud-utils CSR parse fails at Csr::signature_alg — nRF9160 mfw 1.3.7, cryptography ASN.1 ParseError

Question

I'm onboarding an nRF9160-DK to nRF Cloud for CoAP A-GNSS using nrfcloud-utils, and every CSR-parsing step fails with the same ASN.1 error at the CSR's signatureAlgorithm field. I'd appreciate confirmation of whether this is a known modem-firmware/library incompatibility and the recommended fix.

Setup

Board: nRF9160-DK (nRF9160 SICA REV2 / B1A), on-board J-Link
Modem firmware: mfw_nrf9160_1.3.7 (confirmed via AT+CGMR)
Device firmware: Cellular: AT Client sample, NCS v3.3.0, board target nrf9160dk/nrf9160/ns
Host: Windows, nrfcloud-utils 3.1.0, nrfcredstore 2.0.9, cryptography 49.0.0, installed via uv (Python 3.13)
Device ID target: internal UUID format, CoAP transport

What fails

device_credentials_installer -d --port COM8 --ca <ca> --ca-key <key> --verify --coap reads IMEI and modem version correctly, then fails while parsing AT%KEYGEN output:

ValueError: error parsing asn1 value: ParseError { kind: ExtraData, location: ["Csr::signature_alg"] }

followed by a secondary load_der_public_key failure (unexpected tag).

As a workaround I generated the key/CSR directly with nrfcredstore, which succeeded:

nrfcredstore --cmd-type at COM8 generate 16842753 device_csr.der
→ New private key generated in secure tag 16842753
→ Wrote CSR in DER format to device_csr.der

But signing that CSR locally with create_device_credentials --csr device_csr.der ... fails, and loading the DER directly with cryptography reproduces the exact same error:

x509.load_der_x509_csr(d)
→ ParseError { kind: ExtraData, location: ["Csr::signature_alg"] }

The CSR framing looks valid

The DER is not truncated or padded — the outer SEQUENCE length matches the file exactly:

File length: 271 bytes
Header: 3082 010b → declared content length 0x010B (267) + 4 header bytes = 271 (exact match)

So the "ExtraData" is being reported inside the structure at signatureAlgorithm, not as trailing bytes on the file. This suggests the modem's KEYGEN signatureAlgorithm AlgorithmIdentifier encoding is being rejected by cryptography's strict ASN.1 parser (49.0.0).

Questions

Is this a known incompatibility between nRF9160 1.3.7 KEYGEN CSR output and recent cryptography versions used by nrfcloud-utils 3.1.0?
What is the recommended fix — a specific pinned cryptography version, a patched nrfcloud-utils release, or a modem firmware note? (nrfcloud-utils 3.1.0 requires cryptography >=46.0.5, so downgrading below 44 isn't possible without dependency conflicts.)
Is local CSR signing still the correct onboarding path for nRF9160 (vs. the Provisioning Service, which appears to be nRF91x1-only), and if so, how should the signatureAlgorithm encoding be handled?

Thanks.