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
