[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

spki syntax



Reading the various drafts of the sdsi & spki efforts I noticed that  a
large part of the documents is devoted  to the definition of ad-hoc spki
syntax.
  The proposals are sometimes non omogeneus and  introduce special
notations for some specific subjects. As a consequence notations are not so
easy to read and understand. 

In the following lines I examine   the adoption of well known syntaxes in
order easy the focus on spki semantics which is, at the end,  the real
problem.

can you tellme if it is simply a matter of taste or  if importing well
defined but foreing notations can bring to positive enhancements to the
spki approach

regards, Francesco Zambon

------------------------------------------------------------------------ 

The motivations for the use of s-expressions (opposed to asn.1) can the
summarised as follows:
1) Human readable notation 
2) Flexible syntax to support complex semantics like tag and keynote
expressions
3) Minimize the amount of data

One can first delay the third target. I mean one can choose the syntax
thinking to targets 1) and 2) and than compress data or even
compile/decompile data in some (unreadable but succint ) intermediate
notation and than zip  it.

The first two targets are better reached if one refers to existing
syntactic frameworks. i.e most of the notation can be easly transalated
into a dialect of XML (1) (Extensible Markup Language from W3C)
 
example:

<cert version=...  delegation=yes>
<issuer algorithm=as-pkcs1-md5 key='....' uri=" http:// xxx  , ldap://yyy
,, ">
<subject hash=...> 
<valid not-after=" 1/1/99" one-time>
<tag>
...................
</tag>
</cert>

This kind of syntax is very common on the Internet, it is well defined,
people is getting used to it and building editors, readers and browsers is
very simple and well supported.

This works for most of spki but it is not very good  for things like tag
and keynotes expressions.
Both fragments deal with  "assertions" and operations on them. 
From "assortions" to " predicates"  the leap is short..

Natural notations for tags could be some  "logic" notation like the one of
Prolog.(2) 
It is well specified, readable, the semantic  is sound and one needs only
the kernel of the language.  (tags correspond to the goal in prolog).

The set of expressible conditions is opendended without developping a new
notation.   
Notice also that prolog-like statements are  used in systems like Tivoli
(it reflects OMG standards) to define network & system management rules 

(from examples01.txt)

<tag>
tracking-fee(150, usd).
</tag>


<tag>
rating(sex,1), rating(violence,1),rating(crypto,9).
</tag>

but also one can  say someting like:

<tag>
rating(sex,_x), rating(violence,_y), _z is _x+_y , _z<3. -
!  read: sex+violence<3
</tag>


(2) Prolog: http://www.cs.cmu.edu/Groups/AI/html/faqs/lang/prolog/prg/top.html
(1) XML: http://www.w3c.org/XML/
---------------------------------------------------------
Francesco Zambon      mailto:zambon@enidata.it
                      mailto:zambonf@acm.org
EniData spa - Via Medici del Vascello 26
20138 Milano (Italy)
Tel: +39 2 520 25369    Fax: +39 2 520 25323


Follow-Ups: