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

[Allen <netsecurity@sound-by-design.com>]

Arshad Noor wrote:
> You've convinced me, Allen.  We are building an architecture and
> protocol for a new architecture for securing data, so it makes
> sense that we try not to repeat the mistakes made by earlier
> design decisions in protocols/software.
> 
> What if I modify the <Permissions> element as follows?
> 
> 1) Instead of making all <Permitted...> sub-elements optional,
>    we make them all required, and
> 
> 2) In addition to allowing the child elements for each of the
>    <Permitted....> sub-elements, we add the value "Any" as a
>    choice and require that SO's either explicitly create some
>    Permission restriction, or use the keyword "Any" so they
>    recognize what they are doing.
> 
> If we do that, the <Permissions> element might now look like the
> following (one example which has no Permission restrictions - the
> same as an empty <Permissions> element based on DRAFT 5.1):
> 
> <Permissions>
>   <PermittedApplications>Any</PermittedApplications>
>   <PermittedDates>Any</PermittedDates>
>   <PermittedDays>Any</PermittedDays>
>   <PermittedLevels>Any</PermittedLevels>
>   <PermittedLocations>Any</PermittedLocations>
>   <PermittedNumberOfTransactions>Any</PermittedNumberOfTransactions>
>   <PermittedTimes>Any</PermittedTimes>
>   <PermittedUses>Any</PermittedUses>
> </Permissions>
> 
> Another might look like the following that restricts keys to only a
> 1,000 encryption transactions and only on weekdays for one specific
> application:
> 
> <Permissions>
>   <PermittedApplications>
>      <PermittedApplication>
>        <ekmi:ApplicationID>10514-23</ekmi:ApplicationID>
>        <ekmi:ApplicationName>eCommerce Application</ekmi:ApplicationName>
>        <ekmi:DigestAlgorithm>http://www.w3.org/2000/09/xmldsig#sha1</ekmi:DigestAlgorithm>
>        <ekmi:DigestValue>NIG4bKkt4cziEqFFuOoBTM81efU=</ekmi:DigestValue>
>      </ekmi:PermittedApplication>
>   </PermittedApplications>
>   <PermittedDates>Any</PermittedDates>
>   <PermittedDays>Weekdays</PermittedDays>
>   <PermittedLevels>Any</PermittedLevels>
>   <PermittedLocations>Any</PermittedLocations>
>   <PermittedNumberOfTransactions>1000</PermittedNumberOfTransactions>
>   <PermittedTimes>Any</PermittedTimes>
>   <PermittedUses>Any</PermittedUses>
> </Permissions>
> 
> While this makes the protocol just a tiny bit heavier, it does make
> the policy explicit so that no one can complain that they did not 
> know the SKMS would allow keys to be used by any application, at any
> time, etc.
> 
> Additionally, IT Auditors would have a way of zeroing in on key-use
> policies that had an "Any" value for all <Permitted....> sub-elements
> as it might indicate a weakness in policy implementation.
> 
> What does everyone think?

Being in the camp of "deny all unless explicitly allowed," it's not 
my first choice. Being a bit loser like this to start with will make 
for easier testing and trial deployments. However, there might be a 
disconnect when it comes to moving to enterprise deployment from 
proof of concept.

In the FAQ there needs a section about this potential disconnect 
(probably titled something like "Security Risks") so that the 
implications can not be avoided by even lower level people who are 
charged with implementing the service in an enterprise.

That said, what it does do is provide for easy auditing, a key 
requisite for any standard, and that is a *big* step in the right 
direction.

Thanks for listening, Arshad.

Best to all,

Allen