dexter has uploaded this change for review.
es9p_client: fix decoding of euiccCiPKIdToBeUsed (JSON)
At the moment, the es9p_client decodes the euiccCiPKIdToBeUsed as
BASE64 encoded octetstring, with no further decoding on top.
The specification (SGP.22) is a bit vague whether or not an
additional decoding should be applied. However, observations in
the wild have shown that the JSON encoded euiccCiPKIdToBeUsed is
indeed prepended with a BER-TLV header (e.g. 0414). This means
that it is likely correct to decode it as SubjectKeyIdentifier
before passing it on to higher layers.
This assumption is also further confirmed by the fact that the
ASN.1 and JSON API should be symmetric. In the ASN.1 specification
we find euiccCiPKIdToBeUsed specified as SubjectKeyIdentifier, so
the same should also be true for the JSON API like it is with any
other encoded JSON object that is not a basic type.
Related: SYS#8203
Change-Id: I490f984055faddb02b68e0717077ef7ddcd63b67
---
M src/es9p_client.erl
1 file changed, 3 insertions(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/onomondo-eim refs/changes/81/43781/1
diff --git a/src/es9p_client.erl b/src/es9p_client.erl
index 4f79110..13ca93b 100644
--- a/src/es9p_client.erl
+++ b/src/es9p_client.erl
@@ -202,7 +202,9 @@
maps:get(<<"serverSigned1">>, JsonResp)
),
serverSignature1 => base64:decode(maps:get(<<"serverSignature1">>, JsonResp)),
- euiccCiPKIdToBeUsed => base64:decode(
+ euiccCiPKIdToBeUsed => dec_asn1_b64(
+ 'PKIX1Implicit88',
+ 'SubjectKeyIdentifier',
maps:get(<<"euiccCiPKIdToBeUsed">>, JsonResp)
),
serverCertificate => dec_asn1_b64(
To view, visit change 43781. To unsubscribe, or for help writing mail filters, visit settings.