Re: [ekmi] SKML 1.0 Specification - Edited with questions

[Arshad Noor <arshad.noor@strongauth.com>]

Allen,

You raised a couple of interesting questions in your edited version of
the spec.  I decided to answer it separately in an e-mail rather than
put the answer in the document.  I'll quote the sections with your
questions for those who haven't had the time to review the document.

Question 1:

"When the <Permissions> element is empty, that there are no restrictions 
on the use of the symmetric key other than that the application calling 
on the SKCL be authorized to access the key in question. However, when 
there are elements defined within the <Permissions> element, conforming 
SKCL implementations must comply with all the permission elements, 
evaluating the most restrictive permissions first and in decreasing 
order of restriction, before allowing the use of the key.

[Allen's question] (This approach has a potential flaw if there is any 
misconfiguration. It implicitly allows that which is not denied rather 
than denying everything that is not explicitly allowed. Granted, it is a 
bit more cumbersome to require that all permissions be explicit, but it 
is more secure when such events as typographical errors occur in that it 
will fail when attempts to utilize a key are made, rather than silently 
allowing the error and it only showing up in logs or other events)."

   I thought about the implications of this design for quite some time
   before settling on this, Allen.  Let me explain my rationale: an SKS
   Server, by default, will NOT return an existing key to any client
   unless there is an explicit authorization to that key (or KeyGroup)	
   for the specific client (or the Group to which the client belongs).
   Since the key is denied by default, it is my belief that the risk of
   returning an existing key to a client, by mistake or omission, is
   very little.

   WRT the <Permissions> element, it is my belief that the vast majority
   of applications will not have the severe restrictions imposed by this
   element & sub-elements, in the early stage of encryption.  Some high-
   risk data will need to be protected significantly, and the keys that
   protect that data will have the detailed <Permission> elements around
   their use-policy.  As such, I believe that SO's will want to define
   those highly-restrictive policies only for the few use-cases where it
   is necessary.  For all other keys, the default-deny rule is more than
   sufficient protection.  Wouldn't you agree?

Question 2:

"NOTE:  It is noteworthy to mention that the absence of a 
<PermittedDuration> element within a <KeyUsePolicy> element specifies 
that applications are permitted the use of the symmetric key forever, 
subject to complying with all other permission clauses in the 
<KeyUsePolicy> element, if any.

[Allen's comment] (This is bad design as all processes should have a end 
by date by default, requiring re-authorization so that nothing operates 
out of sight, out of mind)"

   It is my belief that most keys will have restrictions on their use
   in one form or another.  Either they will be restricted by dates,
   time, duration, transactions or something that will limit its use
   forever.  It is unlikely that any SO will want a symmetric key to be
   used for encryption, forever.  A good SKMS/EKMI architect will ensure
   that SO's are aware of this when defining their KeyUsePolicies.

   Like anything really dangerous - guns, dynamite, matchsticks, etc. -
   one needs to train people on their proper use.  You can't protect
   them from harming themselves if they don't heed your advice.

   It would be helpful in understanding this model, if you see that the
   <Permission> element and its sub-elements are *further* restrictions
   on the default-deny policy of an SKS server (at least in StrongKey,
   it is so; I'm not sure how other KM systems implement their policies).
   The risk is already mitigated at the very first gate; once you get
   past that, there may be other restrictions that conforming SKCL
   implementations must address.

Hope these address your questions, Allen.  Thanks for the really fast
turnaround on the DRAFT 5.0 normative document.  Do you - or others
from the TC - have any suggestions for improving the DRAFT 5.0
informative document?  Should these explanations be in there?  Should
we include a FAQ section in the informative document that highlights
these questions/comments?

Thanks.

Arshad

Allen wrote:
> Hi Gang,
> 
> There are a couple of questions of substance that might need looking at 
> before the final draft is submitted for a vote.
> 
> Best to all,
>