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,
>
