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

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

Allen (and all),

You've probably seen the e-mails on the DRAFT 6 update to the
spec documents (normative, informative and XSD).  Please review
the <Permissions> section for the changes.

If you have any more feedback, I'd appreciate what I can get by
Friday, so if there are any more changes, I can get to them this
weekend.

I'd like to put this to a TC vote on Monday June 30, so we can
publish it to the internet for comments for the 60-day review
period.  We will have the 60-days ourselves to continue reviewing
and evolving the spec as necessary, but it puts us on a path and
timeline that will get us closer to a standard.

Thanks.

Arshad

Allen wrote:
> 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