Attention is currently required from: dexter.
10 comments:
File docs/smpp-ota-tool.rst:
Patch Set #1, Line 5: cards
an eUICC must not be a card, in fact most often it is not. I would just write "of SIM/USIM/UICC/eUICC." or something like that.
SMPP
server
"... SMPP server (such as a production SMSC of a live cellular network) as well."
I think it makes sense to clarify that one can use this in a production setup if one is an operator and has SMPP access to ones own SMSC.
it's not "a set" but "sets of keys".. Somehow the paragraph doesn't really make it clear that the SCP80 keys must be used. You just say that the SCP80 protocol is used, and not that therem ight be different sets of keys for different SCPs and one of the SCP80 keysets must be used.
we have many more instances of "card" in the document, it seems. Maybe add an initial paragraph at the top that whenever "SIM" is used, any of UICC/USIM/ISIM/eUICC/eSIM is actually meant? Or one could also do the same with the word "card": Define the word "card" in the context of this document as "any SIM/USIM/ISIM/UICC/eUICC/eSIM whether or not it is in a physical card or solder form-factor"?
Patch Set #1, Line 26: The KIK is not used in the scope of SCP80.
oh, are you sure? That means you cannot deploy new SCP80 (or other) keys via SCP80? I would have assumed that using RAM one could also issue PUT KEY and then the KIK would be used? Do you have a spec reference for your statement that it's not used?
Patch Set #1, Line 28: programmed into the issuer security domain (ISD)
the keyset doesn't have to be in the ISD. I think any security domain (whether issuer or supplementary) could in theory specify its own material? Might be best to just say "security domain" without being too specific.
Patch Set #1, Line 84: A0A40000027F20
might be worth using formatting instructions to use monospaced font for all APDUs or other hex-strings
Patch Set #1, Line 86: is received by the SIM RFM application and then executed. This method poses some limitations that have to be taken into
might be worth stating that he SIM RFM application is "on the card"
To prevent this, we may include a replay protection counter within the message. In this case, the MSL indicates that a
replay protection counter is not required. However, to extended the security of our messages, we may chose to use a
counter anyway. In the following example, we will encode a counter value of 100. We will instruct the card to make sure
that the value we send is higher than the counter value that is currently stored in the card.
it might be worth mentioning at some earlier point that the MSL of the card may be different for different card types/profiles, and that cards beyond lab/experimentation use should ideally have a MSL that makes the use of the counter mandatory. It's just the sysmoISIM-SJS1/SJA2/SJA5 that do not have a MSL requiring a counter as that makes it easier for lab/research type use.
Patch Set #1, Line 162: overlap
"... it will not wrap on overflow ...
To view, visit change 42237. To unsubscribe, or for help writing mail filters, visit settings.