dexter has uploaded this change for review.

View Change

esipa_asn1_handler: Add TODOs to address missing checks

The ASN.1 handler code lacks several checks that are required
by SGP.32. Profile downloads will work fine, but we won't catch
errors early.

Related: SYS#8100
Change-Id: I6174fba0760a0192d59db68a430b10ab7726bcb3
---
M src/esipa_asn1_handler.erl
1 file changed, 28 insertions(+), 4 deletions(-)

git pull ssh://gerrit.osmocom.org:29418/onomondo-eim refs/changes/06/43506/1

diff --git a/src/esipa_asn1_handler.erl b/src/esipa_asn1_handler.erl
index f1be50a..0fc72e7 100644
--- a/src/esipa_asn1_handler.erl
+++ b/src/esipa_asn1_handler.erl
@@ -21,6 +21,10 @@
     % initiateAuthenticationRequest. However the field is only missing in case the IPA capability minimizeEsipaBytes is
     % used. This is an optional feature that this eIM does not support, so we can expect euiccInfo1 to be always present.
 
+    % TODO: Popluate smdpAddress from Activation Code if missing: smdpAddress is declared as anan optional field in
+    % InitiateAuthenticationRequestEsipa. If the field is missing, we can retrieve it from the Activation Code that is
+    % stored in the download Order (see also SGP.32, section 3.2.3.2, step 8).
+
     % setup ES9+ request message
     Es9Req = {initiateAuthenticationRequest, EsipaReq},
 
@@ -31,16 +35,20 @@
     EsipaResp =
         case Es9Resp of
             {initiateAuthenticationOk, InitAuthOk} ->
+                % TODO: Verify serverAddress in serverSigned1: In case we ad to extract the smdpAddress from the
+                % Activation Code we should make sure that smdpAddress and serverAddress are equal.
+                % TODO: Verify SM-DP+ OID. An Activation Code may contain an SM-DP+ OID. Make sure that this OID
+                % matches the OID from the serverCertificate (see also SGP.32, section 3.2.3.2, step 10).
                 TransactionId = maps:get(transactionId, InitAuthOk),
                 mnesia_db_work:bind(Pid, TransactionId),
                 % TODO: matchingId and ctxParams1 are not defined in the ES9+ InitiateAuthenticationResponse message.
                 % However in ESipa those fields are optional fields and either one of it should be populated in case an
                 % AC is used (which we do). This means we should populate those fields. The matchingId can be extracted
                 % from the AC, which we have in the Order. If the IPAd supports eimCtxParams1Generation then it should
-                % be find if we would just add the matchingId field like so: maps:merge(InitAuthOk, #{matchingId =>
-                % FIXME). Otherwise we would have to add a ctxParams1 field and populate it with the matchingId and the
-                % deviceInfo. The deviceInfo can be retrieved via an eUICC data request.
-                % (see GSMA SGP.32, section 3.1.2.3).
+                % be fine if we would just add the matchingId field like so: maps:merge(InitAuthOk, #{matchingId =>
+                % MatchingId}). Otherwise we would have to add a ctxParams1 field and populate it with the matchingId
+                % and the deviceInfo. The deviceInfo can be retrieved via an eUICC data request. (see also GSMA SGP.32,
+                % section 3.2.3.2, step 11).
                 InitAuthOkEsipa = #{
                     transactionId => maps:get(transactionId, InitAuthOk),
                     serverSigned1 => maps:get(serverSigned1, InitAuthOk),
@@ -102,6 +110,17 @@
                         fallbackAllowed => FallbackAllowed
                     }
                 ),
+                % TODO: Verify profileMetaData in case the IPAd is not able to verify the profileMetaData: At the
+                % moment we assume that the IPAd is able to verify the profileMetaData, but there may be IPAd
+                % implementations which cannot verify the profileMetaData (eimProfileMetadataVerification). In those
+                % cases the eIM is responsible to verify the profileMetaData, which is not implemnted yet (see also
+                % SGP.32, section 3.2.3.2, step 15 and 19).
+                % TODO: Implement compatibility Check: At the moment it is the responsibility of the REST API user to
+                % ensure that eIM and IPAd are compatible. Currently the REST API user must request the IpaCapabilities
+                % via an eUICC Data Request and know for himself what capability combinations will work with this eIM.
+                % To simplify this we should automate this process by requesting and caching the IpaCapabilities once,
+                % so that we the info withing reach when we need it (similar to how we cache signPubKey, see also
+                % mnesia_db_euicc.hrl).
                 AuthenticateClientOkDPEsipa = AuthClntRespEs9#{
                     profileMetaData => StoreMetadataRequest
                 },
@@ -296,6 +315,11 @@
                 % an activationCode (option a) It still lacks download triggers via SM-DS (option b) and downloads from
                 % the default SM-DP+ (option c). See also GSMA SGP.32, section 3.2.3.2
                 ActivationCode = proplists:get_value(<<"activationCode">>, Download),
+                % TODO: Check the contents of ActivationCode. The eIM should check the provided Activation Code and stop
+                % the procedure in case the Activation Code is invalid. However, it should also be mentioned that The
+                % missing check only has a minor impact since an invalid Activation Code will be detected on the IPAd
+                % side, which will cause the procedure to stop as well. (see also SGP.32, section 3.2.3.2, step 1 and
+                % step 4).
                 {profileDownloadTriggerRequest, #{
                     profileDownloadData => {activationCode, ActivationCode},
                     eimTransactionId => EimTransactionId

To view, visit change 43506. To unsubscribe, or for help writing mail filters, visit settings.