Skip to main content

[jsr361-experts] JSR-361 Meeting Minutes

  • From: < >
  • To:
  • Subject: [jsr361-experts] JSR-361 Meeting Minutes
  • Date: Thu, 11 Jul 2013 15:00:43 +0000 (UTC)

Dear experts,

here are the minutes of today's ED meeting:

- During EDR period,  there have been some discussions with internal
reviewers. As a consequence, some minor changes have been done in order
to improve implementability and testability - no major changes in the
APIs ( an added paprameter or a removed method here and there,
something like that; no changes in the architecture).

- The main difference between EDR version and post-EDR version are some
updates in the security model. During the phone call, I have explained
this changes again more detailed:

  * The intention behind those changes is to generalize the security
model as we know it from IMP and MIDP with respect to provisioning,
authentification and security policies.
 
  * For that, three new terms have been introduced: Client, Security
Authentication Provider (SAP), and Security Policy Provider (SPP).

  * The SAP is the generalization of what is known from IMP/MIDP as the
PKI based authentication of applications (and signers). This mechanism
is one possible implementation of the SAP and the default one for MEEP.
But the SAP concept allows a MEEP implementer to introduce another
mechanism instead, that may not be certificate and signature based.

  * The introduction of the "Client" is a logical implication of the
SAP: in IMP/MIDP we has the signer, but as authentification is not
necessarily certificate/signature based anymore, we do not have
necessarily a "signer", but a client in the sense of  the originator of
an application (for the default, PKI based implementation of the SAP,
the client is of course the signer).

  * The SSP is the generalization of what is known from IMP/MIDP as the
certificate-based security policy mechanism. This well-known mechanism
is again a possible implementation of the SSP and the default one. A
MEEP implementer is free though to implement another mechanism instead.

As a conseuqnce, the structure of (the security part of) the spec has
slightly changed: we have a general chapter about provisioning
(describing general requirements that have to be fulfilled by whatever
provisoning mechainsm is implemented), and one about OTA based
provisioning (describing how the well known OTA provisioning realizes
this). We have a general chapter about SAP, and a specialized one about
the the well known X.509 based authentification. We have a general
chapter about the SPP, and a specialized one about the well known
certioficate based security policy handling.

The following proposals have been raised by Thomas (Gemalto) during the
Telco:

- The links in the overview chapter pointing to the single chapter
should have the headline of the respective chapter as the text by the
word in order toavoid confusion.
  AI Volker: Update Spec accordingly.

-  It should be checked whether the implementation should become the
possibility to generally forbid the installation of untrusted apps.
   AI Volker: Clarify with ME architects if this would raise any
issues.

- The permissions granted to untrusted apps (in case an implementation
allows them to be installed) should be checked (it looks like they have
to many rights that could be misused as it is now).
   AI Volker: Check and change accordingly.

As for the further schedule of the JSR:
Unless major issues occur, I'm going to prepare PR for the second half
of August. I will contact you again, sending the draft version I forsee
for that once it is ready
and ask for green light to to do so.

Best regards -
Volker


[jsr361-experts] JSR-361 Meeting Minutes

volker.bauche 07/11/2013
 
 
Close
loading
Please Confirm
Close