Re: [pkcs11] Proposal: Supporting multiple callers in process

[Stef Walter <stefw@redhat.com>]

Thanks for the insight. I'm working on on the document edits for this
change.

Stef

On 16.05.2013 15:36, Gil Abel wrote:
> This is indeed an annoying part in the specs, which probably all of
> us have suffered from... I would suggest to go for your first
> approach with one additional constrain - not allowing to explicitly
> longing on from a SO RO session, which is meaningless. i.e. the specs
> will allow creating a RO session even if another RW session is logged
> in as SO, but not allow to login form that RO session. 
> Then, return
> as you said CKS_RO_PUBLIC_SESSION for the RO session. This will solve
> the practical problem. Of course, a clarification note would have to
> be added to the specs ;)
> 
> Cheers, Gil.
> 
> -----Original Message----- From: Stef Walter
> [mailto:stefw@redhat.com] Sent: Tuesday, May 14, 2013 11:24 AM To:
> Gil Abel Cc: Darren J Moffat; pkcs11@lists.oasis-open.org Subject:
> Re: [pkcs11] Proposal: Supporting multiple callers in process
> 
> On 21.04.2013 15:52, Gil Abel wrote:
>> 
>>> Anyone else have insight as the reasoning here why CKU_SO + 
>>> read-only
>> sessions were originally disallowed?
>> 
>> 
>> Yes, the reason is that if 'RO SO Functions' sessions would be 
>> allowed, they would have been identical in behavior to 'RO Public 
>> Session' sessions. Here is way. Let's assume we define those 2
>> types of sessions, the behavior would have been as follows:
>> 
>> - Session objects: RW access to session objects is always granted, 
>> regardless if the session is RO or RW (so we can forget about them 
>> for this discussions).
>> 
>> - Public Objects: both session types (assuming defined), would
>> have allowed RO access to public objects.
>> 
>> - Private Objects: both session would NOT have allowed any type of 
>> access to private objects (which require the User's PIN).
>> 
>> So having a RO public session, and then logging on as SO to that 
>> session would have changed nothing, the same access would have 
>> remain, which makes this type of session meaningless....
> 
> Indeed, in theory it does.
> 
> But in practice this creates another whole set of awkward return
> values, cases to check for and logic that must be maintained. As
> noted earlier it prevents using standard logic (eg: find a
> certificate across all tokens) with read-only sessions, without
> additional complexity.
> 
> Then there's the current inherent inability to use C_Login with
> CKU_SO just because some other unrelated caller of the PKCS#11 is
> holding open a read-only session on the token.
> 
> So in my opinion this should be simplified by either:
> 
> * Having sessions opened read-only while SO logged in simply be 
> CKS_RO_PUBLIC_SESSION. * C_Login CKU_SO would work regardless of the
> presence of other read-only sessions. * GetSessionInfo would return
> the CKS_RO_PUBLIC_SESSION state for read-only sessions regardless of
> whether logged in as SO or not-logged in (ie: public). * If the
> caller wishes to actually exercise the SO login to do SO things, then
> obviously they continue to need a read-write session.
> 
> or we could:
> 
> * Defining CKS_RO_SO_FUNCTIONS in spite of it being meaningless. *
> C_Login CKU_SO would work regardless of the presence of other 
> read-only sessions. * GetSessionInfo would return the
> CKS_RO_SO_FUNCTIONS state for read-only sessions when SO is logged
> in. * If the caller wishes to actually exercise the SO login to do SO
> things, then obviously they continue to need a read-write session.
> 
> I think the former is the more compatible approach.
> 
> In both cases, I believe that the practical benefit of complexity 
> reduction here outweighs the theoretical clarity of the model.
> 
> The following would be deprecated, along with their various
> explanations and state info.
> 
> CKR_SESSION_READ_ONLY_EXISTS CKR_SESSION_READ_WRITE_SO_EXISTS
> 
> Cheers,
> 
> Stef
>