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