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

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

Thanks for the feedback, Allen.

I agree that the earlier construct I provided in an e-mail last
week was easier to understand, Allen.

Unfortunately, it turns out that XML Schema does not allow you
to define an element (with the same name) to contain either
sub-elements or text content.  The only way to do this was with
an attribute.  Since "any" is used to frequently in XML Schema,
you have to qualify it with the "ekmi" namespace.

The xsi:nil became another XML Schema requirement, because if
you have an element that is defined to have some value in it
(such as a number range or enumerated list, etc.), having a
null element causes schema-validation failures, *unless* you
have the "xsi:nil" attribute set to "true".

That said, Auditors will not likely be searching protocol
messages between SKMS clients and servers when auditing an
EKMI.  They will query the Administration Console for all Key-
UsePolicies that have NULL values for Permissions.  The console
will then perform an SQL database search for NULL values and
show them the policies that meet the search criteria.

If an Auditor is diligent enough and wants to see the actual
protocol message between a server and a client for one of the
KeyUsePolicies, then they will more than likely use an XML
Schema tool such as NetBeans, Eclipse, etc. to view the XML
elements in graphics mode and then view the content they're
interested in, in text.

Additionally, we have another goal for this TC - which we will
get around to in 2009: creating a conformance test-suite so
that protocol implementations can be tested.  That conformance
certificate from OASIS will also tell the Auditors something
about a a company's EKMI implementation.

Hope that addresses your concern, Allen.

Arshad

Allen wrote:
> 
> 
> Arshad Noor wrote:
>> You've convinced me, Allen.  We are building an architecture and
>> protocol for a new archtiecture 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>
> 
> In looking at the 6.0 version, (Taken from the non-normative to make
> it easier to find. I've also removed the line level formating to
> make it easier to read in e-mail) the <Permissions> are:
> 
> [b15]<ekmi:Permissions>
> [b16]<ekmi:PermittedApplications ekmi:any=”false”>
> [b17]<ekmi:PermittedApplication>
> [b18]<ekmi:ApplicationID>10514-23</ekmi:ApplicationID>
> [b19]<ekmi:ApplicationName>
> [b20]      Payroll Application
> [b21]</ekmi:ApplicationName>
> [b22]<ekmi:ApplicationVersion>1.0</ekmi:ApplicationVersion>
> [b23]<ekmi:ApplicationDigestAlgorithm>
> [b24]http://www.w3.org/2000/09/xmldsig#sha1
> [b25]</ekmi:ApplicationDigestAlgorithm>
> [b26] <ekmi:ApplicationDigestValue>
> [b27]NIG4bKkt4cziEqFFuOoBTM81efU=
> [b28]</ekmi:ApplicationDigestValue>
> [b29]</ekmi:PermittedApplication>
> [b30]</ekmi:PermittedApplications>
> [b31]<ekmi:PermittedDates ekmi:any=”false”>
> [b32]<ekmi:PermittedDate>
> [b33]<ekmi:StartDate>2008-01-01</ekmi:StartDate>
> [b34]<ekmi:EndDate>2008-12-31</ekmi:EndDate>
> [b35]</ekmi:PermittedDate>
> [b36]</ekmi:PermittedDates>
> [b37]<ekmi:PermittedDays ekmi:any=”true” xsi:nil=”true”/>
> [b38]<ekmi:PermittedDuration ekmi:any=”true” xsi:nil=”true”/>
> [b39]<ekmi:PermittedLevels ekmi:any=”true” xsi:nil=”true”/>
> [b40]<ekmi:PermittedLocations ekmi:any=”true” xsi:nil=”true”/>
> [b41]<ekmi:PermittedNumberOfTransactions ekmi:any=”true”
> xsi:nil=”true”/>
> [b42]<ekmi:PermittedTimes ekmi:any=”false”>
> [b43]<ekmi:PermittedTime>
> [b44]<ekmi:StartTime>07:00:00</ekmi:StartTime>
> [b45]<ekmi:EndTime>19:00:00</ekmi:EndTime>
> [b46]</ekmi:PermittedTime>
> [b47]</ekmi:PermittedTimes>
> [b48]<ekmi:PermittedUses ekmi:any=”true” xsi:nil=”true”/>
> [b49]</ekmi:Permissions>
> 
> Comparing the two - your previous e-mail, and the construct you have
> created in 6.0 - The first is *much* easier to follow and audit.
> 
> Just to use one example:
> 
> <PermittedDays>Any</PermittedDays>
> 
> versus:
> 
> <ekmi:PermittedDays ekmi:any=”true” xsi:nil=”true”/>
> 
> In the first it is very clear that "any" days are permitted and a
> search for "any" will find this non-restrictive element. In the
> second, proposed structure, a search for "any" will find both
> non-restrictive and restrictive elements. This results in having to
> understand the meaning of the whole clause rather than the
> simplicity of the first.
> 
> If one is to search on "true", then one is in a world of hurt during
> an audit as there will be many clauses with "true," which means that
> each of them has to be parsed to see if it might not be a valid and
> appropriate statement. This will result in many more human errors
> that are avoidable with the simpler construct.
> 
> The element is also over-complicated by using three sub-elements -
> 1) "ekmi:PermittedDays", 2) "ekmi:any" and 3) "xsi:nil"
> 
> The prefixing with "ekmi" and "xsi" add a level of unneeded
> obscurity. Better to use a wrapper tag format on separate opening
> and closing lines like:
> 
> <ekmi>
>   <Permissions>
>     <PermittedDates>Any</PermittedDates>
> ....
>   </Permissions>
> </ekmi>
> 
> As to the best way to handle the "xsi" elements, I suggest that it
> be by a equivalents or translation table such as:
> 
> <ekmi:any> == <xsi:nil>
> 
> (Here the pre-pending of the sub element makes sense and gives
> clarity in that it says in the ekmi construct "any" is the same as
> "nil" in the xsi construct.) The use of a translation table means
> that migrating from one construct to another for any reason can
> become an simple task that can be done automatically and would be
> very easy to ensure accuracy.
> 
> If it is absolutely required that both be in the same document, then
> I would suggest that it be done like other SGML documents, one after
> another like this:
> 
> <ekmi>
>   <Permissions>
>     <PermittedDates>Any</PermittedDates>
> ....
>   </Permissions>
> </ekmi>
> ....
> <xsi>
>   <(xyz element)>
>     <(xyz element)>nil= (whatever)</(xyz element)>
> ....
>   </(xyz element)>
> </xsi>
> 
> 
> If an application requires the ekmi information it can read it and
> ignore the elements of xsi that it is not prepared to understand,
> and vis versa. This is the default behavior in HTML and XHTML - if
> the application does not understand the tag it ignores it.
> 
> Additionally it is not as easy to read and understand if you use
> self-closing tags for non-trivial objects. In HTML or XHTML it is
> clear that <br /> is a simple tag with only one possible meaning but
> in general self-closing tags are not used in more complex tags where
> there are multiple declared parameters and specific switches.
> 
> As an example (from HTML):
> 
> <td width="100%" cellpadding="12" align="left" valign="baseline" 
> bgcolor="#ffffff"> Written documentation is almost as old as human 
> civilization. </td>
> 
> If you were to structure this like you propose it might look like this:
> 
> <td width="100%" cellpadding="12" align="left" valign="baseline" 
> bgcolor="#ffffff" WrittenDocumentation="almost as old as human 
> civilization" />
> 
> Frankly I find that much harder to parse and understand what is 
> happening and what is the key information being communicated.
> 
> Best,
> 
> Allen
> 
> 
> 
> 
> 
> 
>