jsdsi-devel — JSDSI Developers

[Jsdsi-devel] spki/sdsi xml format

[Sameer A. <aj...@cs...>]

Hi Carl,

I hope you're doing well.

Some recent discussion has come up on the jsdsi-devel list regarding the
XML format for SPKi/SDSI objects.  Lots of schemas have been proposed,
including at least one RFC, but you and I once discussed a simple
"sexp-to-xml" translation (and in fact you demonstrated this with an s2x
program).  I've recently implemented my own version of s2x in JSDSI, usign
this mapping:

Given sexp s = (type item1 item2 ... itemN),
s2x(s) =
<type>
s2x(item1)
s2x(item2)
...
s2x(itemN)
</type>

If s is a sexp-string, then it is converted to readable (advanced) form
and stored as character data inside the surrounding element.

For example:
s = (name (hash md5 |abc123def456|) "Carol Jones" friends)
s2x(s) =
<name>
<hash>md5 |abc123def456|</hash>
"Carol Jones" friends
</name>

What's good about this is that reading or writing XML required no semantic
knowledge of SPKI/SDSI.  What's bad is that storing sexp-strings as
character data means that they're not logically separated.  For example, a
human looking at "<hash>md5 |abc123def456|</hash>" does not necessarily
know what the string sin the middle mean.  Notice that this is no problem
to parse: the parser simply reads such character data into as many sexp
strings as are encoded (in this case two).

There are a couple of solutions.  One is to wrap each strign in an element:
<hash><string>md5</string><string>|abc123def456|</string></hash>
Or even:
<hash><string val="md5"/><string val="|abc123def456|"/></hash>
But this is ugly.

I believe the better solution is to address the semantic deficiency at its
source by annotating each string:
<hash><algo>md5</algo><value>|abc123def456|</value></hash>
Since we want to keep the XML-Sexp mapping semantic-free, this requires
the corresponding Sexp to become:
(hash (algo md5) (value |abc123def456|))

I think this is good.  In general, this means SPKI/SDSI S-expressions are
restricted as follows:
<sexp-list> = "(" <sexp-string> <list-body> ")" ;
<list-body> = <sexp-list>* | <sexp-string> ;

That is, a SPKI/SDSI Sexp-list always starts with a Sexp-string (its type)
that is followed by zero or more Sexp-lists OR exactly one Sexp-string.

This would require some adjustments to the SPKI/SDSI grammar, but I
believe it will make objects easier to understand and it will make the
conversion to XML even simpler.

What to you think?
Sameer


http://ajmani.net

[Jsdsi-devel] Installing Maven, Eclipse and JSDSI on Windows 2000

[Sean R. <sra...@ae...>]

Here's a step by step guide that I just did to get Maven working on
Windows 2000 (a box that has a correctly installed JDK).

1. Download maven-1.0-rc1.zip
(http://maven.apache.org/start/download.html)

2. Extract the downloaded zip to your target directory, e.g. C:\java\ -
resulting in c:\java\maven-1.0-rc1

3. set MAVEN_HOME to 'C:\java\maven-1.0-rc1' via the 'Control
Panel\System\Advanced\Environment Variables\User Variables'

4. Add %MAVEN_HOME%\bin to 'Path' environment variable similar to above

5. Open a console and run 'set' to check that the environment variables
are set correctly. (An easy way to open a command prompt is
'Start\Run...', enter 'command' and press 'ok')

6. From the command prompt run 'install_repo.bat
%HOMEPATH%\.maven\repository' - On some boxes the environment variable
is HOME, you can check this by running the 'set' command and looking for
which entry points to 'C:\Documents and Settings\YOURUSERNAME'

7. At the command prompt run 'maven -g' to check that Maven is running -
all the maven goals are listed...

8. Download and install Eclipse (Latest stable version 3 build is
currently 3.0-M7)

9. Run Eclipse

10. Set-up jsdsi cvs repository in Eclipse for browsing (make sure to
use extssh or ext if you will want to write to the repository later)

11. In the CVS repository browser select the HEAD branch of
cvsroot/jsdsi

12. Under the above, select the jsdsi directory and right-click

13. Select 'Check Out As...'

14. Make sure 'Check out as a project configured using the New Project
Wizard' is selected 

15. Press Finish

16. Select 'Java' and 'Java Project' and press 'Next'

17. Enter project name 'jsdsi' in the text box and press 'Next'
(optionally enter an alternate project location in the 'Project
Contents' information area)

18. When asked to switch Perspective select yes

19. Using a text editor, e.g. Notepad create a text file called
'build.properties' in your home directory ('C:\Documents and
Settings\YOURUSERNAME'). The contents of the file is a single entry:

maven.eclipse.workspace=ECLIPSE_WORKSPACE_PATH

Where ECLIPSE_WORKSPACE_PATH should be replaced by the path to your
Eclipse Workspace (the default being 'ECLIPSE_HOME\workspace') As an
example:

maven.eclipse.workspace=C:\programs\eclipse-3.0-M7\workspace

19. Save your 'build.properties' file.

20. Go back to the command prompt

21. 'cd' to the location where you checked-out jsdsi to during step 17 -
The default location is 'ECLIPSE_HOME\workspace\jsdsi', where
ECLIPSE_HOME is the location of your Eclipse installation

22. Within the jsdsi directory run 'maven eclipse:add-maven-repo' - This
adds a variable to Eclipse so it knows where your Local Maven Repository
is.

23. Next run 'maven eclipse' - This creates the correct eclipse
'.project' and '.classpath' files.

24. In eclipse, 'refresh' your jsdsi project.

25. All should now be correctly set-up... 


Hope this help,


Sean

(This is something to move to the site I should guess - ideally with
some screenshots)

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] New Mavenised JSDSI

[Sean R. <sra...@ae...>]

Well I don't know why you are having so much problems with Maven. I've
installed it on about half a dozen times on Windows 2000 in the past
with no difficulties - and never had to go near the batch files.

Anyway.

I've tried checking out the current CVS version of JSDSI, and nothing
> works (at least, via Eclipse).  Eclipse can't seem to build or find the
> right classes to run (eg., the JUnit tests or S2X).  
(Out of interest, are you checking out using the Eclipse CVS tool?)

Are your source directory settings correct in your project properties?
(I've attached screenshots of a brand new project just created from a
new CVS upload and 'maven eclipse' - these show the settinsg you should
have for the source trees and libraries). The MAVEN_REPO is an Eclipse
Variable set to (~/.maven/repository') - produced by the Maven Eclipse
Plugin, 'maven eclipse:add-maven-repo'.

>Unfortunately, I
> don't know how to run "maven" from that directory in a Windows
> environment.
can you not get the command prompt up and 'cd' to it? Start/Run... enter
'command' and press 'ok' to get a command prompt.

Hope this helps

Sean

On Sat, 2004-02-28 at 18:20, Sameer Ajmani wrote:
> > Is maven working at all (does 'maven -g' display the list of goals)?
> 
> maven -g works, but only because I've hacked up the following:
> Set the MAVEN_BATCH_PAUSE environment variable to "on".
> Edited the Shortcut to maven.bat to pass -g.
> 
> Hardly a reasonable way to do this.  Perhaps Maven just isn't designed for
> Windows use?
> 
> > You can in the mean-time (until you have a working maven) manually
> > create an Eclipse project:
> 
> In other words, go back to what I was doing before. :)
> 
> I've tried checking out the current CVS version of JSDSI, and nothing
> works (at least, via Eclipse).  Eclipse can't seem to build or find the
> right classes to run (eg., the JUnit tests or S2X).  Unfortunately, I
> don't know how to run "maven" from that directory in a Windows
> environment.
> 
> Sameer
> 
> >
> >
> > Sean
> >
> >  On Sat, 2004-02-28 at 17:59, Sameer Ajmani wrote:
> >> Sean,
> >>
> >> The problem I'm having is that "shell" is a very ill-defined term
> >> under Windows.  I've tried Start->Run->[command.com], whch gives a
> >> poor approximation, and doesn't work quite as I recall from the old
> >> DOS days.  I've had soem limited success installing Maven by hacking
> >> its .bat files, but this hardly seems like the right thing to do.  The
> >> installation instructions online provide little help, because they say
> >> nothing about how to set environment variables (which I figured out)
> >> or how to actually *see* the output of the .bat files (the window
> >> closes too quickly to see what's going wrong).
> >>
> >> I know this would be all so much easier under Linux (which is what I
> >> use for work), but I prefer to use Eclipse under Windows at home.  If
> >> we're going to use Maven for this project, this installation process
> >> has got to be simplified.
> >>
> >> Here's what I have:
> >> 1) Installed Eclipse
> >> 2) Installed maven (required setting JAVA_HOME via the Control Panel)
> >>
> >> Here's what I want:
> >> A JSDSI Eclipse project that works.
> >>
> >> I've been able to do a few mroe of the intermediate steps, but they
> >> required inappropriate levels of hackery.
> >>
> >> Can you fill in the missing steps?  The Apache online documentation
> >> doesn't.
> >>
> >> Thanks,
> >> Sameer
> >>
> >> > Have you got a .maven directory under your 'home' directory?
> >> >
> >> > It should contain a plugins and repository directory - if not, run
> >> %MAVEN_HOME%\bin\install_repo.bat %HOME%\.maven\repository as per
> >> http://maven.apache.org/start/install.html
> >> >
> >> > from the command promt does 'maven -g' do anything? (it should
> >> display a list of all plugins and their goals) if not, check that
> >> %MAVEN_HOME%\bin is on your path
> >> >
> >> > Let me know...
> >> >
> >> >
> >> > On Sat, 2004-02-28 at 17:00, Sameer Ajmani wrote:
> >> >> Hmm, any clues on how to do all this under Windows?  (I develop on
> >> Linux at work, but Windows/Eclipse at home)
> >> >>
> >> >> Here's what I've done so far:
> >> >> 1) Download the maven exe from the download site.
> >> >> 2) Set JAVA_HOME to my JDK via Settings->Control
> >> >> Panel->System->Advanced->Enviornment Variables.
> >> >> 3) Run the maven executable (installed maven).
> >> >> 4) Downloaded the Maven Eclipse Plugin
> >> >> 5) Attempt in vain to run the plugin or tell Eclipse to import it.
> >> >>
> >> >> I'm on Windows 2000, so there's not much in terms of a "shell" that
> >> I can use...
> >> >>
> >> >> Sameer
> >> >>
> >> >> > All,
> >> >> >
> >> >> > I have uploaded to CVS the new Mavenised version of JSDSI. To use
> >> >> it:
> >> >> >
> >> >> > 1. Install Maven on your machine:
> >> >> > 	a. download Maven from
> >> http://maven.apache.org/start/download.html
> >> >> b.
> >> >> > install it as per http://maven.apache.org/start/install.html
> >> >> >
> >> >> > 2. Checkout the latest CVS from the jsdsi tree
> >> >> >
> >> >> > 3. From the shell in your jsdsi directory try a 'maven jar'. This
> >> >> should compile all of the classes and run all the tests, resulting
> >> in a 'jsdsi-0.5.jar' in the 'target' directory.
> >> >> >
> >> >> > You may get a compilation problem with finding the cryptix
> >> classes.
> >> >> If so copy the cryptix32.jar into your local maven repository
> >> (should be ~/.maven/repository/cryptix/jars/)
> >> >> >
> >> >> > If you want an eclipse project to develop jsdsi in just run the
> >> >> maven eclipse plugin:
> >> >> http://maven.apache.org/reference/plugins/eclipse/ (basically means
> >> run 'maven eclipse' from the shell.
> >> >> >
> >> >> >
> >> >> > Any problems, just shout.
> >> >> >
> >> >> > Sean
> >> >> >
> >> >> > (I'll update the web-site with the new Maven produced site
> >> shortly)
> >> >> >
> >> >> >
> >> >> > On Thu, 2004-02-26 at 14:59, Sameer Ajmani wrote:
> >> >> >> Well, my hope was to avoid requiring any semantic information in
> >> >> the JSDSI-to-XML translation.  The output I showed you earlier
> >> simply converts jsdsi.Objs to Sexps, then converts these Sexps to
> >> XML.  Thus, all the semantics is captures in the JSDSI-to-Sexp
> >> translation.
> >> >> >>
> >> >> >> Using "local-name" as you have below requires the XML tranlation
> >> to
> >> >> know the meaning of a particular string.  I would instead suggest
> >> that the Sexp format be changed to:
> >> >> >> (name (public-key ...) (local-name alice) (local-name bob))
> >> >> >>
> >> >> >> Then, everything will work perfectly :)
> >> >> >> Sameer
> >> >> >>
> >> >> >> > akin to 'the spec' I would vote for something like the later:
> >> >> (name (public-key ...) alice bob)
> >> >> >> > becomes
> >> >> >> > <name>
> >> >> >> >   <public-key>...</public-key>
> >> >> >> >   <local-name>alice</local-name>
> >> >> >> >   <local-name>bob</local-name>
> >> >> >> > </name>
> >> >> >> >
> >> >> >> > with maybe an (optional) index attribute on the local-name:
> >> >> <name>
> >> >> >> >   <public-key>...</public-key>
> >> >> >> >   <local-name index="0">alice</local-name>
> >> >> >> >   <local-name index="1">bob</local-name>
> >> >> >> > </name>
> >> >> >> >
> >> >> >> >
> >> >> >> > Sean
> >> >> >> >
> >> >> >> > On Thu, 2004-02-26 at 13:05, Sameer Ajmani wrote:
> >> >> >> >> > Hmm... Those possible changes to the SExp just seem to make
> >> >> them
> >> >> >> >> more verbose just for XML...
> >> >> >> >> Right.  The alternative is to wrap each base SexpString in
> >> its
> >> >> own
> >> >> >> element: CarolJones
> >> >> >> >> becomes
> >> >> >> >> <string val="CarolJones"/>
> >> >> >> >> or <string>CarolJones</string>
> >> >> >> >>
> >> >> >> >> > Have you seen this:
> >> >> >> >> I glanced at these specs some time age.  We should aim to
> >> >> support
> >> >> >> this spec whatever the SPKI working group (or Carl Ellison)
> >> uses.
> >> >> >> >>
> >> >> >> >> > http://bladesys.demon.co.uk/roller/resources/sradford/draft-orri-spki-xml-cert-struc-00.txt
> >> >> >> >>
> >> >> >> >> Thanks,
> >> >> >> >> Sameer
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > Sean
> >> >> >> >> >
> >> >> >> >> > On Wed, 2004-02-25 at 18:41, Sameer Ajmani wrote:
> >> >> >> >> >> > (at first I wondering if the placing of the 'local name'
> >> of
> >> >> >> >> >> CarolJones was correct, but I think it is the right thing
> >> to
> >> >> do
> >> >> >> -
> >> >> >> >> not many xml documents have a tag and a text value as direct
> >> >> >> >> >> children of another tag).
> >> >> >> >> >>
> >> >> >> >> >> Yes, the string interspersed with elements are ugly (and
> >> >> maybe a
> >> >> >> >> problem).
> >> >> >> >> >>  I'll try to write an XmlReader that inverts this process
> >> >> >> sometime
> >> >> >> >> >> soon,
> >> >> >> >> >> and hopefully that will complain if this is invalid XML :)
> >> >> It
> >> >> >> also
> >> >> >> >> may be problematic if XML concatenates adjacent strings,
> >> e.g.,
> >> >> >> (name (public-key ...) mary friends) will become:
> >> >> >> >> >> <name>
> >> >> >> >> >>   <public-key>...</public-key>
> >> >> >> >> >>   mary friends
> >> >> >> >> >> </name>
> >> >> >> >> >>
> >> >> >> >> >> XML will read "mary friends" as a single block of
> >> character
> >> >> >> data,
> >> >> >> >> while SPKI treasts it as two SexpStrings.  My XmlReader will
> >> >> handle
> >> >> >> this just fine, but the XML form lacks some structural
> >> information.
> >> >> >> >> >>
> >> >> >> >> >> An alternative is to make SPKI's syntax more
> >> XML-compatible
> >> >> by
> >> >> >> >> restricting its S-expressions to SexpLists thatcontain one
> >> >> SexpString or an arbitrary number of SexpLists.  So the above name
> >> >> >> object would be:
> >> >> >> >> >> (name (public-key ...) (id mary) (id friends))
> >> >> >> >> >>
> >> >> >> >> >> While this is ugly in the "name" case, it actually makes
> >> some
> >> >> >> other
> >> >> >> >> structures clearer:
> >> >> >> >> >>
> >> >> >> >> >> (hash md5 |hfslk782yf2|)
> >> >> >> >> >> becomes:
> >> >> >> >> >> (hash (algo md5) (value |hfslk782yf2|))
> >> >> >> >> >>
> >> >> >> >> >> (k-of-n "2" "3"
> >> >> >> >> >>  (public-key ...) (public-key ...) (public-key ...))
> >> >> >> >> >> becomes:
> >> >> >> >> >> (k-of-n (k "2") (n "3")
> >> >> >> >> >>  (public-key ...) (public-key ...) (public-key ...))
> >> >> >> >> >>
> >> >> >> >> >> This change would require consulting with the SPKI
> >> designers
> >> >> (I
> >> >> >> >> could contact Carl Ellison about this).
> >> >> >> >> >>
> >> >> >> >> >> Sameer
> >> >> >> >> >>
> >> >> >> >> >> > On Wed, 2004-02-25 at 02:54, Sameer Ajmani wrote:
> >> >> >> >> >> >> I have just committed a simple Sexp-to-XML converter to
> >> >> >> JSDSI.
> >> >> >> >> >> This makes it possible to express JSDSI objects as XML (by
> >> >> first
> >> >> >> >> converting them to S-expressions).  I added the package
> >> >> jsdsi.xml
> >> >> >> and the class jsdsi.xml.XmlWriter, and extended the jsdsi.S2X
> >> >> utility to support xml output.  Here's an example:
> >> >> >> >> >> >>
> >> >> >> >> >> >> Input S-expression:
> >> >> >> >> >> >>
> >> >> >> >> >> >> (cert
> >> >> >> >> >> >>   (issuer
> >> >> >> >> >> >>     (name
> >> >> >> >> >> >>       (public-key
> >> >> >> >> >> >>         (rsa-pkcs1-md5
> >> >> >> >> >> >>           (e #010001#)
> >> >> >> >> >> >>           (n
> >> >> >> >> >> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn
> >> >> >> >> >> >> 5mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk
> >> >> >> >> 2ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|)))
> >> >> >> >> >> >>       CarolJones))
> >> >> >> >> >> >>   (subject
> >> >> >> >> >> >>     (public-key
> >> >> >> >> >> >>       (rsa-pkcs1-md5
> >> >> >> >> >> >>         (e #010001#)
> >> >> >> >> >> >>         (n
> >> >> >> >> >> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R
> >> >> >> >> >> >> 2Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk
> >> >> >> >> >> 2SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|)))))
> >> >> >> >> >> >>
> >> >> >> >> >> >> Output XML:
> >> >> >> >> >> >>
> >> >> >> >> >> >> <cert>
> >> >> >> >> >> >>   <issuer>
> >> >> >> >> >> >>     <name>
> >> >> >> >> >> >>       <public-key>
> >> >> >> >> >> >>         <rsa-pkcs1-md5>
> >> >> >> >> >> >>           <e>
> >> >> >> >> >> >>             #010001#
> >> >> >> >> >> >>           </e>
> >> >> >> >> >> >>           <n>
> >> >> >> >> >> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn5
> >> >> >> >> >> >> mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk2
> >> >> >> >> ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|
> >> >> >> >> >> >>           </n>
> >> >> >> >> >> >>         </rsa-pkcs1-md5>
> >> >> >> >> >> >>       </public-key>
> >> >> >> >> >> >>       CarolJones
> >> >> >> >> >> >>     </name>
> >> >> >> >> >> >>   </issuer>
> >> >> >> >> >> >>   <subject>
> >> >> >> >> >> >>     <public-key>
> >> >> >> >> >> >>       <rsa-pkcs1-md5>
> >> >> >> >> >> >>         <e>
> >> >> >> >> >> >>           #010001#
> >> >> >> >> >> >>         </e>
> >> >> >> >> >> >>         <n>
> >> >> >> >> >> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R2
> >> >> >> >> >> >> Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk2
> >> >> >> >> >> SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|
> >> >> >> >> >> >>         </n>
> >> >> >> >> >> >>       </rsa-pkcs1-md5>
> >> >> >> >> >> >>     </public-key>
> >> >> >> >> >> >>   </subject>
> >> >> >> >> >> >> </cert>
> >> >> >> >> >> >>
> >> >> >> >> >> >> The problems with this are that it's not terribly
> >> compact
> >> >> >> (e.g.,
> >> >> >> >> >> the "e" elements could be all on one line), I'm not sure
> >> >> whether
> >> >> >> >> all the characters used in the text blocks are allowed,
> >> there's
> >> >> no
> >> >> >> schema or DTD, and there's no XmlReader (yet).  But does this
> >> >> conversion look reasonable?
> >> >> >> >> >> >>
> >> >> >> >> >> >> Sameer
> >> >> >> >> >> >>
> >> >> >> >> >> >> http://ajmani.net
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> -------------------------------------------------------
> >> >> >> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> >> >> >> Build and deploy apps & Web services for Linux with
> >> >> >> >> >> >> a free DVD software kit from IBM. Click Now!
> >> >> >> >> >> >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> >> >> _______________________________________________
> >> >> >> >> >> >> Jsdsi-devel mailing list
> >> >> >> >> >> >> Jsd...@li...
> >> >> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> >> >> >> >> >> > --
> >> >> >> >> >> > Dr. Sean Radford, MBBS, MSc
> >> >> >> >> >> > sra...@ae...
> >> >> >> >> >> > http://www.aegeus-technology.com
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> http://ajmani.net
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> -------------------------------------------------------
> >> >> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> >> >> Build and deploy apps & Web services for Linux with
> >> >> >> >> >> a free DVD software kit from IBM. Click Now!
> >> >> >> >> >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> >> _______________________________________________
> >> >> >> >> >> Jsdsi-devel mailing list
> >> >> >> >> >> Jsd...@li...
> >> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> >> >> >> >> > --
> >> >> >> >> > Dr. Sean Radford, MBBS, MSc
> >> >> >> >> > sra...@ae...
> >> >> >> >> > http://www.aegeus-technology.com
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> http://ajmani.net
> >> >> >> >>
> >> >> >> > --
> >> >> >> > Dr. Sean Radford, MBBS, MSc
> >> >> >> > sra...@ae...
> >> >> >> > http://www.aegeus-technology.com
> >> >> >>
> >> >> >>
> >> >> >> http://ajmani.net
> >> >> >>
> >> >> > --
> >> >> > Dr. Sean Radford, MBBS, MSc
> >> >> > sra...@ae...
> >> >> > http://www.aegeus-technology.com
> >> >> >
> >> >> >
> >> >> >
> >> >> > -------------------------------------------------------
> >> >> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> >> >> > Build and deploy apps & Web services for Linux with
> >> >> > a free DVD software kit from IBM. Click Now!
> >> >> > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> >> >> > _______________________________________________
> >> >> > Jsdsi-devel mailing list
> >> >> > Jsd...@li...
> >> >> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> >> >>
> >> >>
> >> >> http://ajmani.net
> >> >>
> >> > --
> >> > Dr. Sean Radford, MBBS, MSc
> >> > sra...@ae...
> >> > http://www.aegeus-technology.com
> >>
> >>
> >> http://ajmani.net
> >>
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Fwd: Re: [Jsdsi-devel] New Mavenised JSDSI]

[Sean R. <sra...@ae...>]

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] New Mavenised JSDSI

[Sean R. <sra...@ae...>]

I should add that I have left all the exisiting files unchanged until we
are all happy with the new stuff.

Sean

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] New Mavenised JSDSI

[Sean R. <sra...@ae...>]

All,

I have uploaded to CVS the new Mavenised version of JSDSI. To use it:

1. Install Maven on your machine:
	a. download Maven from http://maven.apache.org/start/download.html
	b. install it as per http://maven.apache.org/start/install.html

2. Checkout the latest CVS from the jsdsi tree

3. From the shell in your jsdsi directory try a 'maven jar'. This should
compile all of the classes and run all the tests, resulting in a
'jsdsi-0.5.jar' in the 'target' directory.

You may get a compilation problem with finding the cryptix classes. If
so copy the cryptix32.jar into your local maven repository (should be
~/.maven/repository/cryptix/jars/)

If you want an eclipse project to develop jsdsi in just run the maven
eclipse plugin: http://maven.apache.org/reference/plugins/eclipse/
(basically means run 'maven eclipse' from the shell.


Any problems, just shout.

Sean

(I'll update the web-site with the new Maven produced site shortly)

 
On Thu, 2004-02-26 at 14:59, Sameer Ajmani wrote:
> Well, my hope was to avoid requiring any semantic information in the
> JSDSI-to-XML translation.  The output I showed you earlier simply converts
> jsdsi.Objs to Sexps, then converts these Sexps to XML.  Thus, all the
> semantics is captures in the JSDSI-to-Sexp translation.
> 
> Using "local-name" as you have below requires the XML tranlation to know
> the meaning of a particular string.  I would instead suggest that the Sexp
> format be changed to:
> (name (public-key ...) (local-name alice) (local-name bob))
> 
> Then, everything will work perfectly :)
> Sameer
> 
> > akin to 'the spec' I would vote for something like the later:
> > (name (public-key ...) alice bob)
> > becomes
> > <name>
> >   <public-key>...</public-key>
> >   <local-name>alice</local-name>
> >   <local-name>bob</local-name>
> > </name>
> >
> > with maybe an (optional) index attribute on the local-name:
> > <name>
> >   <public-key>...</public-key>
> >   <local-name index="0">alice</local-name>
> >   <local-name index="1">bob</local-name>
> > </name>
> >
> >
> > Sean
> >
> > On Thu, 2004-02-26 at 13:05, Sameer Ajmani wrote:
> >> > Hmm... Those possible changes to the SExp just seem to make them
> >> more verbose just for XML...
> >> Right.  The alternative is to wrap each base SexpString in its own
> >> element: CarolJones
> >> becomes
> >> <string val="CarolJones"/>
> >> or <string>CarolJones</string>
> >>
> >> > Have you seen this:
> >> I glanced at these specs some time age.  We should aim to support this
> >> spec whatever the SPKI working group (or Carl Ellison) uses.
> >>
> >> > http://bladesys.demon.co.uk/roller/resources/sradford/draft-orri-spki-xml-cert-struc-00.txt
> >>
> >> Thanks,
> >> Sameer
> >>
> >> >
> >> > Sean
> >> >
> >> > On Wed, 2004-02-25 at 18:41, Sameer Ajmani wrote:
> >> >> > (at first I wondering if the placing of the 'local name' of
> >> >> CarolJones was correct, but I think it is the right thing to do -
> >> not many xml documents have a tag and a text value as direct
> >> >> children of another tag).
> >> >>
> >> >> Yes, the string interspersed with elements are ugly (and maybe a
> >> problem).
> >> >>  I'll try to write an XmlReader that inverts this process sometime
> >> >> soon,
> >> >> and hopefully that will complain if this is invalid XML :)  It also
> >> may be problematic if XML concatenates adjacent strings, e.g.,
> >> (name (public-key ...) mary friends) will become:
> >> >> <name>
> >> >>   <public-key>...</public-key>
> >> >>   mary friends
> >> >> </name>
> >> >>
> >> >> XML will read "mary friends" as a single block of character data,
> >> while SPKI treasts it as two SexpStrings.  My XmlReader will handle
> >> this just fine, but the XML form lacks some structural information.
> >> >>
> >> >> An alternative is to make SPKI's syntax more XML-compatible by
> >> restricting its S-expressions to SexpLists thatcontain one
> >> SexpString or an arbitrary number of SexpLists.  So the above name
> >> object would be:
> >> >> (name (public-key ...) (id mary) (id friends))
> >> >>
> >> >> While this is ugly in the "name" case, it actually makes some other
> >> structures clearer:
> >> >>
> >> >> (hash md5 |hfslk782yf2|)
> >> >> becomes:
> >> >> (hash (algo md5) (value |hfslk782yf2|))
> >> >>
> >> >> (k-of-n "2" "3"
> >> >>  (public-key ...) (public-key ...) (public-key ...))
> >> >> becomes:
> >> >> (k-of-n (k "2") (n "3")
> >> >>  (public-key ...) (public-key ...) (public-key ...))
> >> >>
> >> >> This change would require consulting with the SPKI designers (I
> >> could contact Carl Ellison about this).
> >> >>
> >> >> Sameer
> >> >>
> >> >> > On Wed, 2004-02-25 at 02:54, Sameer Ajmani wrote:
> >> >> >> I have just committed a simple Sexp-to-XML converter to JSDSI.
> >> >> This makes it possible to express JSDSI objects as XML (by first
> >> converting them to S-expressions).  I added the package jsdsi.xml
> >> and the class jsdsi.xml.XmlWriter, and extended the jsdsi.S2X
> >> utility to support xml output.  Here's an example:
> >> >> >>
> >> >> >> Input S-expression:
> >> >> >>
> >> >> >> (cert
> >> >> >>   (issuer
> >> >> >>     (name
> >> >> >>       (public-key
> >> >> >>         (rsa-pkcs1-md5
> >> >> >>           (e #010001#)
> >> >> >>           (n
> >> >> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn
> >> >> >> 5mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk
> >> 2ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|)))
> >> >> >>       CarolJones))
> >> >> >>   (subject
> >> >> >>     (public-key
> >> >> >>       (rsa-pkcs1-md5
> >> >> >>         (e #010001#)
> >> >> >>         (n
> >> >> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R
> >> >> >> 2Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk
> >> >> 2SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|)))))
> >> >> >>
> >> >> >> Output XML:
> >> >> >>
> >> >> >> <cert>
> >> >> >>   <issuer>
> >> >> >>     <name>
> >> >> >>       <public-key>
> >> >> >>         <rsa-pkcs1-md5>
> >> >> >>           <e>
> >> >> >>             #010001#
> >> >> >>           </e>
> >> >> >>           <n>
> >> >> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn5
> >> >> >> mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk2
> >> ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|
> >> >> >>           </n>
> >> >> >>         </rsa-pkcs1-md5>
> >> >> >>       </public-key>
> >> >> >>       CarolJones
> >> >> >>     </name>
> >> >> >>   </issuer>
> >> >> >>   <subject>
> >> >> >>     <public-key>
> >> >> >>       <rsa-pkcs1-md5>
> >> >> >>         <e>
> >> >> >>           #010001#
> >> >> >>         </e>
> >> >> >>         <n>
> >> >> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R2
> >> >> >> Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk2
> >> >> SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|
> >> >> >>         </n>
> >> >> >>       </rsa-pkcs1-md5>
> >> >> >>     </public-key>
> >> >> >>   </subject>
> >> >> >> </cert>
> >> >> >>
> >> >> >> The problems with this are that it's not terribly compact (e.g.,
> >> >> the "e" elements could be all on one line), I'm not sure whether
> >> all the characters used in the text blocks are allowed, there's no
> >> schema or DTD, and there's no XmlReader (yet).  But does this
> >> conversion look reasonable?
> >> >> >>
> >> >> >> Sameer
> >> >> >>
> >> >> >> http://ajmani.net
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> -------------------------------------------------------
> >> >> >> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> >> >> >> Build and deploy apps & Web services for Linux with
> >> >> >> a free DVD software kit from IBM. Click Now!
> >> >> >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> >> >> >> _______________________________________________
> >> >> >> Jsdsi-devel mailing list
> >> >> >> Jsd...@li...
> >> >> >> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> >> >> > --
> >> >> > Dr. Sean Radford, MBBS, MSc
> >> >> > sra...@ae...
> >> >> > http://www.aegeus-technology.com
> >> >>
> >> >>
> >> >> http://ajmani.net
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> -------------------------------------------------------
> >> >> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> >> >> Build and deploy apps & Web services for Linux with
> >> >> a free DVD software kit from IBM. Click Now!
> >> >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> >> >> _______________________________________________
> >> >> Jsdsi-devel mailing list
> >> >> Jsd...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> >> > --
> >> > Dr. Sean Radford, MBBS, MSc
> >> > sra...@ae...
> >> > http://www.aegeus-technology.com
> >>
> >>
> >> http://ajmani.net
> >>
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] JSDSI xml

[Sean R. <sra...@ae...>]

Still would seem like expanding and making the Sexp more verbose just to
support converting to XML. I understand your reasons though. Makes the
Sexp more self-defining and certainly would make the 'xml code' cleaner
and easier to maintain.

One to put to Carl et al I guess?

Sean

On Thu, 2004-02-26 at 14:59, Sameer Ajmani wrote:
> Well, my hope was to avoid requiring any semantic information in the
> JSDSI-to-XML translation.  The output I showed you earlier simply converts
> jsdsi.Objs to Sexps, then converts these Sexps to XML.  Thus, all the
> semantics is captures in the JSDSI-to-Sexp translation.
> 
> Using "local-name" as you have below requires the XML tranlation to know
> the meaning of a particular string.  I would instead suggest that the Sexp
> format be changed to:
> (name (public-key ...) (local-name alice) (local-name bob))
> 
> Then, everything will work perfectly :)
> Sameer
> 
> > akin to 'the spec' I would vote for something like the later:
> > (name (public-key ...) alice bob)
> > becomes
> > <name>
> >   <public-key>...</public-key>
> >   <local-name>alice</local-name>
> >   <local-name>bob</local-name>
> > </name>
> >
> > with maybe an (optional) index attribute on the local-name:
> > <name>
> >   <public-key>...</public-key>
> >   <local-name index="0">alice</local-name>
> >   <local-name index="1">bob</local-name>
> > </name>
> >
> >
> > Sean
> >
> > On Thu, 2004-02-26 at 13:05, Sameer Ajmani wrote:
> >> > Hmm... Those possible changes to the SExp just seem to make them
> >> more verbose just for XML...
> >> Right.  The alternative is to wrap each base SexpString in its own
> >> element: CarolJones
> >> becomes
> >> <string val="CarolJones"/>
> >> or <string>CarolJones</string>
> >>
> >> > Have you seen this:
> >> I glanced at these specs some time age.  We should aim to support this
> >> spec whatever the SPKI working group (or Carl Ellison) uses.
> >>
> >> > http://bladesys.demon.co.uk/roller/resources/sradford/draft-orri-spki-xml-cert-struc-00.txt
> >>
> >> Thanks,
> >> Sameer
> >>
> >> >
> >> > Sean
> >> >
> >> > On Wed, 2004-02-25 at 18:41, Sameer Ajmani wrote:
> >> >> > (at first I wondering if the placing of the 'local name' of
> >> >> CarolJones was correct, but I think it is the right thing to do -
> >> not many xml documents have a tag and a text value as direct
> >> >> children of another tag).
> >> >>
> >> >> Yes, the string interspersed with elements are ugly (and maybe a
> >> problem).
> >> >>  I'll try to write an XmlReader that inverts this process sometime
> >> >> soon,
> >> >> and hopefully that will complain if this is invalid XML :)  It also
> >> may be problematic if XML concatenates adjacent strings, e.g.,
> >> (name (public-key ...) mary friends) will become:
> >> >> <name>
> >> >>   <public-key>...</public-key>
> >> >>   mary friends
> >> >> </name>
> >> >>
> >> >> XML will read "mary friends" as a single block of character data,
> >> while SPKI treasts it as two SexpStrings.  My XmlReader will handle
> >> this just fine, but the XML form lacks some structural information.
> >> >>
> >> >> An alternative is to make SPKI's syntax more XML-compatible by
> >> restricting its S-expressions to SexpLists thatcontain one
> >> SexpString or an arbitrary number of SexpLists.  So the above name
> >> object would be:
> >> >> (name (public-key ...) (id mary) (id friends))
> >> >>
> >> >> While this is ugly in the "name" case, it actually makes some other
> >> structures clearer:
> >> >>
> >> >> (hash md5 |hfslk782yf2|)
> >> >> becomes:
> >> >> (hash (algo md5) (value |hfslk782yf2|))
> >> >>
> >> >> (k-of-n "2" "3"
> >> >>  (public-key ...) (public-key ...) (public-key ...))
> >> >> becomes:
> >> >> (k-of-n (k "2") (n "3")
> >> >>  (public-key ...) (public-key ...) (public-key ...))
> >> >>
> >> >> This change would require consulting with the SPKI designers (I
> >> could contact Carl Ellison about this).
> >> >>
> >> >> Sameer
> >> >>
> >> >> > On Wed, 2004-02-25 at 02:54, Sameer Ajmani wrote:
> >> >> >> I have just committed a simple Sexp-to-XML converter to JSDSI.
> >> >> This makes it possible to express JSDSI objects as XML (by first
> >> converting them to S-expressions).  I added the package jsdsi.xml
> >> and the class jsdsi.xml.XmlWriter, and extended the jsdsi.S2X
> >> utility to support xml output.  Here's an example:
> >> >> >>
> >> >> >> Input S-expression:
> >> >> >>
> >> >> >> (cert
> >> >> >>   (issuer
> >> >> >>     (name
> >> >> >>       (public-key
> >> >> >>         (rsa-pkcs1-md5
> >> >> >>           (e #010001#)
> >> >> >>           (n
> >> >> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn
> >> >> >> 5mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk
> >> 2ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|)))
> >> >> >>       CarolJones))
> >> >> >>   (subject
> >> >> >>     (public-key
> >> >> >>       (rsa-pkcs1-md5
> >> >> >>         (e #010001#)
> >> >> >>         (n
> >> >> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R
> >> >> >> 2Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk
> >> >> 2SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|)))))
> >> >> >>
> >> >> >> Output XML:
> >> >> >>
> >> >> >> <cert>
> >> >> >>   <issuer>
> >> >> >>     <name>
> >> >> >>       <public-key>
> >> >> >>         <rsa-pkcs1-md5>
> >> >> >>           <e>
> >> >> >>             #010001#
> >> >> >>           </e>
> >> >> >>           <n>
> >> >> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn5
> >> >> >> mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk2
> >> ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|
> >> >> >>           </n>
> >> >> >>         </rsa-pkcs1-md5>
> >> >> >>       </public-key>
> >> >> >>       CarolJones
> >> >> >>     </name>
> >> >> >>   </issuer>
> >> >> >>   <subject>
> >> >> >>     <public-key>
> >> >> >>       <rsa-pkcs1-md5>
> >> >> >>         <e>
> >> >> >>           #010001#
> >> >> >>         </e>
> >> >> >>         <n>
> >> >> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R2
> >> >> >> Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk2
> >> >> SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|
> >> >> >>         </n>
> >> >> >>       </rsa-pkcs1-md5>
> >> >> >>     </public-key>
> >> >> >>   </subject>
> >> >> >> </cert>
> >> >> >>
> >> >> >> The problems with this are that it's not terribly compact (e.g.,
> >> >> the "e" elements could be all on one line), I'm not sure whether
> >> all the characters used in the text blocks are allowed, there's no
> >> schema or DTD, and there's no XmlReader (yet).  But does this
> >> conversion look reasonable?
> >> >> >>
> >> >> >> Sameer
> >> >> >>
> >> >> >> http://ajmani.net
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> -------------------------------------------------------
> >> >> >> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> >> >> >> Build and deploy apps & Web services for Linux with
> >> >> >> a free DVD software kit from IBM. Click Now!
> >> >> >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> >> >> >> _______________________________________________
> >> >> >> Jsdsi-devel mailing list
> >> >> >> Jsd...@li...
> >> >> >> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> >> >> > --
> >> >> > Dr. Sean Radford, MBBS, MSc
> >> >> > sra...@ae...
> >> >> > http://www.aegeus-technology.com
> >> >>
> >> >>
> >> >> http://ajmani.net
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> -------------------------------------------------------
> >> >> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> >> >> Build and deploy apps & Web services for Linux with
> >> >> a free DVD software kit from IBM. Click Now!
> >> >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> >> >> _______________________________________________
> >> >> Jsdsi-devel mailing list
> >> >> Jsd...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> >> > --
> >> > Dr. Sean Radford, MBBS, MSc
> >> > sra...@ae...
> >> > http://www.aegeus-technology.com
> >>
> >>
> >> http://ajmani.net
> >>
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Changes on LDAP schema

[Sameer A. <aj...@cs...>]

Luis,

I checked the web, and I realized that I was mistaken: I thought "cn" was
"canonical name" (which implies that it's unique and required), but it's
actually "common name" (which can be optional and non-unique).  So what
you suggest is probably fine for the "cn" attribute.

However, then I suggest the hash of the certificate be available in
another attribute.  I think this hash would be the perfect value for the
OID: it's unique to each certificate, and it's deterministic, meaning a
server can detect if someone attempts to insert the same cert twice (it
can't do this if the OID is a random number).

Sameer

>> I would like to change the attribute 'cn'. I think that 'cn' should be
>> a clear string wich identified the cert and used as optional. Storing
>> a cert will never be a problem, but imagine that some how the user
>> wants to get the cert to do something with it, outside jsdsi scope.
>> How can he get the cert, trough an hash could be complicated the easy
>> way is to use a string, for ex: "cert.1". Why optional? Because if the
>> user wants to associate is cert to an ldap user then the 'cn' wan't
>> make sense, because, on ldap, users names have 'cn' attribute and
>> getting the cert will also be easy. My ideia to the 'cn' attribute is
>> when sdsi certs are used with no
>> association with what so ever. Other way is to continue using 'cn' as
>> before and make the users use the selectors to get the certs, wich,
>> btw, is what Sun do with X509CertSelector. But in both ways i think
>> that should be optional.
>>
>> What do u think?
>>
>> I don't know if u're familiar with ldap. On ldap server attributes and
>> object classes are identified by a unique numeric number(OID) this
>> numbers are registered, to prevent colisions of numbers. For now i'm
>> using a random number, but latter jsdsi attributes an object classes
>> could be registered, the registration is free.
>>
>>    -- Luis Pedro
>>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

Re: [Jsdsi-devel] JSDSI xml

[Sameer A. <aj...@cs...>]

Well, my hope was to avoid requiring any semantic information in the
JSDSI-to-XML translation.  The output I showed you earlier simply converts
jsdsi.Objs to Sexps, then converts these Sexps to XML.  Thus, all the
semantics is captures in the JSDSI-to-Sexp translation.

Using "local-name" as you have below requires the XML tranlation to know
the meaning of a particular string.  I would instead suggest that the Sexp
format be changed to:
(name (public-key ...) (local-name alice) (local-name bob))

Then, everything will work perfectly :)
Sameer

> akin to 'the spec' I would vote for something like the later:
> (name (public-key ...) alice bob)
> becomes
> <name>
>   <public-key>...</public-key>
>   <local-name>alice</local-name>
>   <local-name>bob</local-name>
> </name>
>
> with maybe an (optional) index attribute on the local-name:
> <name>
>   <public-key>...</public-key>
>   <local-name index="0">alice</local-name>
>   <local-name index="1">bob</local-name>
> </name>
>
>
> Sean
>
> On Thu, 2004-02-26 at 13:05, Sameer Ajmani wrote:
>> > Hmm... Those possible changes to the SExp just seem to make them
>> more verbose just for XML...
>> Right.  The alternative is to wrap each base SexpString in its own
>> element: CarolJones
>> becomes
>> <string val="CarolJones"/>
>> or <string>CarolJones</string>
>>
>> > Have you seen this:
>> I glanced at these specs some time age.  We should aim to support this
>> spec whatever the SPKI working group (or Carl Ellison) uses.
>>
>> > http://bladesys.demon.co.uk/roller/resources/sradford/draft-orri-spki-xml-cert-struc-00.txt
>>
>> Thanks,
>> Sameer
>>
>> >
>> > Sean
>> >
>> > On Wed, 2004-02-25 at 18:41, Sameer Ajmani wrote:
>> >> > (at first I wondering if the placing of the 'local name' of
>> >> CarolJones was correct, but I think it is the right thing to do -
>> not many xml documents have a tag and a text value as direct
>> >> children of another tag).
>> >>
>> >> Yes, the string interspersed with elements are ugly (and maybe a
>> problem).
>> >>  I'll try to write an XmlReader that inverts this process sometime
>> >> soon,
>> >> and hopefully that will complain if this is invalid XML :)  It also
>> may be problematic if XML concatenates adjacent strings, e.g.,
>> (name (public-key ...) mary friends) will become:
>> >> <name>
>> >>   <public-key>...</public-key>
>> >>   mary friends
>> >> </name>
>> >>
>> >> XML will read "mary friends" as a single block of character data,
>> while SPKI treasts it as two SexpStrings.  My XmlReader will handle
>> this just fine, but the XML form lacks some structural information.
>> >>
>> >> An alternative is to make SPKI's syntax more XML-compatible by
>> restricting its S-expressions to SexpLists thatcontain one
>> SexpString or an arbitrary number of SexpLists.  So the above name
>> object would be:
>> >> (name (public-key ...) (id mary) (id friends))
>> >>
>> >> While this is ugly in the "name" case, it actually makes some other
>> structures clearer:
>> >>
>> >> (hash md5 |hfslk782yf2|)
>> >> becomes:
>> >> (hash (algo md5) (value |hfslk782yf2|))
>> >>
>> >> (k-of-n "2" "3"
>> >>  (public-key ...) (public-key ...) (public-key ...))
>> >> becomes:
>> >> (k-of-n (k "2") (n "3")
>> >>  (public-key ...) (public-key ...) (public-key ...))
>> >>
>> >> This change would require consulting with the SPKI designers (I
>> could contact Carl Ellison about this).
>> >>
>> >> Sameer
>> >>
>> >> > On Wed, 2004-02-25 at 02:54, Sameer Ajmani wrote:
>> >> >> I have just committed a simple Sexp-to-XML converter to JSDSI.
>> >> This makes it possible to express JSDSI objects as XML (by first
>> converting them to S-expressions).  I added the package jsdsi.xml
>> and the class jsdsi.xml.XmlWriter, and extended the jsdsi.S2X
>> utility to support xml output.  Here's an example:
>> >> >>
>> >> >> Input S-expression:
>> >> >>
>> >> >> (cert
>> >> >>   (issuer
>> >> >>     (name
>> >> >>       (public-key
>> >> >>         (rsa-pkcs1-md5
>> >> >>           (e #010001#)
>> >> >>           (n
>> >> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn
>> >> >> 5mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk
>> 2ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|)))
>> >> >>       CarolJones))
>> >> >>   (subject
>> >> >>     (public-key
>> >> >>       (rsa-pkcs1-md5
>> >> >>         (e #010001#)
>> >> >>         (n
>> >> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R
>> >> >> 2Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk
>> >> 2SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|)))))
>> >> >>
>> >> >> Output XML:
>> >> >>
>> >> >> <cert>
>> >> >>   <issuer>
>> >> >>     <name>
>> >> >>       <public-key>
>> >> >>         <rsa-pkcs1-md5>
>> >> >>           <e>
>> >> >>             #010001#
>> >> >>           </e>
>> >> >>           <n>
>> >> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn5
>> >> >> mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk2
>> ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|
>> >> >>           </n>
>> >> >>         </rsa-pkcs1-md5>
>> >> >>       </public-key>
>> >> >>       CarolJones
>> >> >>     </name>
>> >> >>   </issuer>
>> >> >>   <subject>
>> >> >>     <public-key>
>> >> >>       <rsa-pkcs1-md5>
>> >> >>         <e>
>> >> >>           #010001#
>> >> >>         </e>
>> >> >>         <n>
>> >> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R2
>> >> >> Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk2
>> >> SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|
>> >> >>         </n>
>> >> >>       </rsa-pkcs1-md5>
>> >> >>     </public-key>
>> >> >>   </subject>
>> >> >> </cert>
>> >> >>
>> >> >> The problems with this are that it's not terribly compact (e.g.,
>> >> the "e" elements could be all on one line), I'm not sure whether
>> all the characters used in the text blocks are allowed, there's no
>> schema or DTD, and there's no XmlReader (yet).  But does this
>> conversion look reasonable?
>> >> >>
>> >> >> Sameer
>> >> >>
>> >> >> http://ajmani.net
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> -------------------------------------------------------
>> >> >> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>> >> >> Build and deploy apps & Web services for Linux with
>> >> >> a free DVD software kit from IBM. Click Now!
>> >> >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>> >> >> _______________________________________________
>> >> >> Jsdsi-devel mailing list
>> >> >> Jsd...@li...
>> >> >> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
>> >> > --
>> >> > Dr. Sean Radford, MBBS, MSc
>> >> > sra...@ae...
>> >> > http://www.aegeus-technology.com
>> >>
>> >>
>> >> http://ajmani.net
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> -------------------------------------------------------
>> >> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>> >> Build and deploy apps & Web services for Linux with
>> >> a free DVD software kit from IBM. Click Now!
>> >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>> >> _______________________________________________
>> >> Jsdsi-devel mailing list
>> >> Jsd...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
>> > --
>> > Dr. Sean Radford, MBBS, MSc
>> > sra...@ae...
>> > http://www.aegeus-technology.com
>>
>>
>> http://ajmani.net
>>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com


http://ajmani.net

[Jsdsi-devel] Changes on LDAP schema

[Luis P. <lp...@ne...>]

> Sameer,
> 
> I would like to change the attribute 'cn'. I think that 'cn' should be a
> clear string wich identified the cert and used as optional. Storing a cert
> will never be a problem, but imagine that some how the user wants to get
> the cert to do something with it, outside jsdsi scope. How can he get the
> cert, trough an hash could be complicated the easy way is to use a string,
> for ex: "cert.1". Why optional? Because if the user wants to associate is
> cert to an ldap user then the 'cn' wan't make sense, because, on ldap,
> users names have 'cn' attribute and getting the cert will also be easy. My
> ideia to the 'cn' attribute is when sdsi certs are used with no
> association with what so ever. Other way is to continue using 'cn' as
> before and make the users use the selectors to get the certs, wich, btw,
> is what Sun do with X509CertSelector. But in both ways i think that should
> be optional.
> 
> What do u think?
> 
> I don't know if u're familiar with ldap. On ldap server attributes and
> object classes are identified by a unique numeric number(OID) this numbers
> are registered, to prevent colisions of numbers. For now i'm using a
> random number, but latter jsdsi attributes an object classes could be
> registered, the registration is free.
> 
>    -- Luis Pedro
> 

Re: [Jsdsi-devel] JSDSI xml

[Sean R. <sra...@ae...>]

akin to 'the spec' I would vote for something like the later:
(name (public-key ...) alice bob)
becomes
<name>
  <public-key>...</public-key>
  <local-name>alice</local-name>
  <local-name>bob</local-name>
</name>

with maybe an (optional) index attribute on the local-name:
<name>
  <public-key>...</public-key>
  <local-name index="0">alice</local-name>
  <local-name index="1">bob</local-name>
</name>


Sean

On Thu, 2004-02-26 at 13:05, Sameer Ajmani wrote:
> > Hmm... Those possible changes to the SExp just seem to make them more
> > verbose just for XML...
> Right.  The alternative is to wrap each base SexpString in its own element:
> CarolJones
> becomes
> <string val="CarolJones"/>
> or <string>CarolJones</string>
> 
> > Have you seen this:
> I glanced at these specs some time age.  We should aim to support this
> spec whatever the SPKI working group (or Carl Ellison) uses.
> 
> > http://bladesys.demon.co.uk/roller/resources/sradford/draft-orri-spki-xml-cert-struc-00.txt
> 
> Thanks,
> Sameer
> 
> >
> > Sean
> >
> > On Wed, 2004-02-25 at 18:41, Sameer Ajmani wrote:
> >> > (at first I wondering if the placing of the 'local name' of
> >> CarolJones was correct, but I think it is the right thing to do -
> >> not many xml documents have a tag and a text value as direct
> >> children of another tag).
> >>
> >> Yes, the string interspersed with elements are ugly (and maybe a
> >> problem).
> >>  I'll try to write an XmlReader that inverts this process sometime
> >> soon,
> >> and hopefully that will complain if this is invalid XML :)  It also
> >> may be problematic if XML concatenates adjacent strings, e.g., (name
> >> (public-key ...) mary friends) will become:
> >> <name>
> >>   <public-key>...</public-key>
> >>   mary friends
> >> </name>
> >>
> >> XML will read "mary friends" as a single block of character data,
> >> while SPKI treasts it as two SexpStrings.  My XmlReader will handle
> >> this just fine, but the XML form lacks some structural information.
> >>
> >> An alternative is to make SPKI's syntax more XML-compatible by
> >> restricting its S-expressions to SexpLists thatcontain one SexpString
> >> or an arbitrary number of SexpLists.  So the above name object would
> >> be:
> >> (name (public-key ...) (id mary) (id friends))
> >>
> >> While this is ugly in the "name" case, it actually makes some other
> >> structures clearer:
> >>
> >> (hash md5 |hfslk782yf2|)
> >> becomes:
> >> (hash (algo md5) (value |hfslk782yf2|))
> >>
> >> (k-of-n "2" "3"
> >>  (public-key ...) (public-key ...) (public-key ...))
> >> becomes:
> >> (k-of-n (k "2") (n "3")
> >>  (public-key ...) (public-key ...) (public-key ...))
> >>
> >> This change would require consulting with the SPKI designers (I could
> >> contact Carl Ellison about this).
> >>
> >> Sameer
> >>
> >> > On Wed, 2004-02-25 at 02:54, Sameer Ajmani wrote:
> >> >> I have just committed a simple Sexp-to-XML converter to JSDSI.
> >> This makes it possible to express JSDSI objects as XML (by first
> >> converting them to S-expressions).  I added the package jsdsi.xml
> >> and the class jsdsi.xml.XmlWriter, and extended the jsdsi.S2X
> >> utility to support xml output.  Here's an example:
> >> >>
> >> >> Input S-expression:
> >> >>
> >> >> (cert
> >> >>   (issuer
> >> >>     (name
> >> >>       (public-key
> >> >>         (rsa-pkcs1-md5
> >> >>           (e #010001#)
> >> >>           (n
> >> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn
> >> >> 5mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk
> >> >> 2ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|)))
> >> >>       CarolJones))
> >> >>   (subject
> >> >>     (public-key
> >> >>       (rsa-pkcs1-md5
> >> >>         (e #010001#)
> >> >>         (n
> >> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R
> >> >> 2Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk
> >> 2SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|)))))
> >> >>
> >> >> Output XML:
> >> >>
> >> >> <cert>
> >> >>   <issuer>
> >> >>     <name>
> >> >>       <public-key>
> >> >>         <rsa-pkcs1-md5>
> >> >>           <e>
> >> >>             #010001#
> >> >>           </e>
> >> >>           <n>
> >> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn5
> >> >> mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk2
> >> >> ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|
> >> >>           </n>
> >> >>         </rsa-pkcs1-md5>
> >> >>       </public-key>
> >> >>       CarolJones
> >> >>     </name>
> >> >>   </issuer>
> >> >>   <subject>
> >> >>     <public-key>
> >> >>       <rsa-pkcs1-md5>
> >> >>         <e>
> >> >>           #010001#
> >> >>         </e>
> >> >>         <n>
> >> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R2
> >> >> Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk2
> >> SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|
> >> >>         </n>
> >> >>       </rsa-pkcs1-md5>
> >> >>     </public-key>
> >> >>   </subject>
> >> >> </cert>
> >> >>
> >> >> The problems with this are that it's not terribly compact (e.g.,
> >> the "e" elements could be all on one line), I'm not sure whether
> >> all the characters used in the text blocks are allowed, there's no
> >> schema or DTD, and there's no XmlReader (yet).  But does this
> >> conversion look reasonable?
> >> >>
> >> >> Sameer
> >> >>
> >> >> http://ajmani.net
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> -------------------------------------------------------
> >> >> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> >> >> Build and deploy apps & Web services for Linux with
> >> >> a free DVD software kit from IBM. Click Now!
> >> >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> >> >> _______________________________________________
> >> >> Jsdsi-devel mailing list
> >> >> Jsd...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> >> > --
> >> > Dr. Sean Radford, MBBS, MSc
> >> > sra...@ae...
> >> > http://www.aegeus-technology.com
> >>
> >>
> >> http://ajmani.net
> >>
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> >> Build and deploy apps & Web services for Linux with
> >> a free DVD software kit from IBM. Click Now!
> >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> >> _______________________________________________
> >> Jsdsi-devel mailing list
> >> Jsd...@li...
> >> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] JSDSI xml

[Sameer A. <aj...@cs...>]

> Hmm... Those possible changes to the SExp just seem to make them more
> verbose just for XML...
Right.  The alternative is to wrap each base SexpString in its own element:
CarolJones
becomes
<string val="CarolJones"/>
or <string>CarolJones</string>

> Have you seen this:
I glanced at these specs some time age.  We should aim to support this
spec whatever the SPKI working group (or Carl Ellison) uses.

> http://bladesys.demon.co.uk/roller/resources/sradford/draft-orri-spki-xml-cert-struc-00.txt

Thanks,
Sameer

>
> Sean
>
> On Wed, 2004-02-25 at 18:41, Sameer Ajmani wrote:
>> > (at first I wondering if the placing of the 'local name' of
>> CarolJones was correct, but I think it is the right thing to do -
>> not many xml documents have a tag and a text value as direct
>> children of another tag).
>>
>> Yes, the string interspersed with elements are ugly (and maybe a
>> problem).
>>  I'll try to write an XmlReader that inverts this process sometime
>> soon,
>> and hopefully that will complain if this is invalid XML :)  It also
>> may be problematic if XML concatenates adjacent strings, e.g., (name
>> (public-key ...) mary friends) will become:
>> <name>
>>   <public-key>...</public-key>
>>   mary friends
>> </name>
>>
>> XML will read "mary friends" as a single block of character data,
>> while SPKI treasts it as two SexpStrings.  My XmlReader will handle
>> this just fine, but the XML form lacks some structural information.
>>
>> An alternative is to make SPKI's syntax more XML-compatible by
>> restricting its S-expressions to SexpLists thatcontain one SexpString
>> or an arbitrary number of SexpLists.  So the above name object would
>> be:
>> (name (public-key ...) (id mary) (id friends))
>>
>> While this is ugly in the "name" case, it actually makes some other
>> structures clearer:
>>
>> (hash md5 |hfslk782yf2|)
>> becomes:
>> (hash (algo md5) (value |hfslk782yf2|))
>>
>> (k-of-n "2" "3"
>>  (public-key ...) (public-key ...) (public-key ...))
>> becomes:
>> (k-of-n (k "2") (n "3")
>>  (public-key ...) (public-key ...) (public-key ...))
>>
>> This change would require consulting with the SPKI designers (I could
>> contact Carl Ellison about this).
>>
>> Sameer
>>
>> > On Wed, 2004-02-25 at 02:54, Sameer Ajmani wrote:
>> >> I have just committed a simple Sexp-to-XML converter to JSDSI.
>> This makes it possible to express JSDSI objects as XML (by first
>> converting them to S-expressions).  I added the package jsdsi.xml
>> and the class jsdsi.xml.XmlWriter, and extended the jsdsi.S2X
>> utility to support xml output.  Here's an example:
>> >>
>> >> Input S-expression:
>> >>
>> >> (cert
>> >>   (issuer
>> >>     (name
>> >>       (public-key
>> >>         (rsa-pkcs1-md5
>> >>           (e #010001#)
>> >>           (n
>> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn
>> >> 5mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk
>> >> 2ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|)))
>> >>       CarolJones))
>> >>   (subject
>> >>     (public-key
>> >>       (rsa-pkcs1-md5
>> >>         (e #010001#)
>> >>         (n
>> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R
>> >> 2Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk
>> 2SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|)))))
>> >>
>> >> Output XML:
>> >>
>> >> <cert>
>> >>   <issuer>
>> >>     <name>
>> >>       <public-key>
>> >>         <rsa-pkcs1-md5>
>> >>           <e>
>> >>             #010001#
>> >>           </e>
>> >>           <n>
>> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn5
>> >> mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk2
>> >> ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|
>> >>           </n>
>> >>         </rsa-pkcs1-md5>
>> >>       </public-key>
>> >>       CarolJones
>> >>     </name>
>> >>   </issuer>
>> >>   <subject>
>> >>     <public-key>
>> >>       <rsa-pkcs1-md5>
>> >>         <e>
>> >>           #010001#
>> >>         </e>
>> >>         <n>
>> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R2
>> >> Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk2
>> SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|
>> >>         </n>
>> >>       </rsa-pkcs1-md5>
>> >>     </public-key>
>> >>   </subject>
>> >> </cert>
>> >>
>> >> The problems with this are that it's not terribly compact (e.g.,
>> the "e" elements could be all on one line), I'm not sure whether
>> all the characters used in the text blocks are allowed, there's no
>> schema or DTD, and there's no XmlReader (yet).  But does this
>> conversion look reasonable?
>> >>
>> >> Sameer
>> >>
>> >> http://ajmani.net
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> -------------------------------------------------------
>> >> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>> >> Build and deploy apps & Web services for Linux with
>> >> a free DVD software kit from IBM. Click Now!
>> >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>> >> _______________________________________________
>> >> Jsdsi-devel mailing list
>> >> Jsd...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
>> > --
>> > Dr. Sean Radford, MBBS, MSc
>> > sra...@ae...
>> > http://www.aegeus-technology.com
>>
>>
>> http://ajmani.net
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>> Build and deploy apps & Web services for Linux with
>> a free DVD software kit from IBM. Click Now!
>> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>> _______________________________________________
>> Jsdsi-devel mailing list
>> Jsd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com


http://ajmani.net

Re: [Jsdsi-devel] JSDSI xml

[Sean R. <sra...@ae...>]

Hmm... Those possible changes to the SExp just seem to make them more
verbose just for XML...

Have you seen this:

http://bladesys.demon.co.uk/roller/resources/sradford/draft-orri-spki-xml-cert-struc-00.pdf

or 

http://bladesys.demon.co.uk/roller/resources/sradford/draft-orri-spki-xml-cert-struc-00.txt

Sean

On Wed, 2004-02-25 at 18:41, Sameer Ajmani wrote:
> > (at first I wondering if the placing of the 'local name' of CarolJones
> > was correct, but I think it is the right thing to do - not many xml
> > documents have a tag and a text value as direct children of another
> > tag).
> 
> Yes, the string interspersed with elements are ugly (and maybe a problem).
>  I'll try to write an XmlReader that inverts this process sometime soon,
> and hopefully that will complain if this is invalid XML :)  It also may be
> problematic if XML concatenates adjacent strings, e.g., (name (public-key
> ...) mary friends) will become:
> <name>
>   <public-key>...</public-key>
>   mary friends
> </name>
> 
> XML will read "mary friends" as a single block of character data, while
> SPKI treasts it as two SexpStrings.  My XmlReader will handle this just
> fine, but the XML form lacks some structural information.
> 
> An alternative is to make SPKI's syntax more XML-compatible by restricting
> its S-expressions to SexpLists thatcontain one SexpString or an arbitrary
> number of SexpLists.  So the above name object would be:
> (name (public-key ...) (id mary) (id friends))
> 
> While this is ugly in the "name" case, it actually makes some other
> structures clearer:
> 
> (hash md5 |hfslk782yf2|)
> becomes:
> (hash (algo md5) (value |hfslk782yf2|))
> 
> (k-of-n "2" "3"
>  (public-key ...) (public-key ...) (public-key ...))
> becomes:
> (k-of-n (k "2") (n "3")
>  (public-key ...) (public-key ...) (public-key ...))
> 
> This change would require consulting with the SPKI designers (I could
> contact Carl Ellison about this).
> 
> Sameer
> 
> > On Wed, 2004-02-25 at 02:54, Sameer Ajmani wrote:
> >> I have just committed a simple Sexp-to-XML converter to JSDSI.  This
> >> makes it possible to express JSDSI objects as XML (by first converting
> >> them to S-expressions).  I added the package jsdsi.xml and the class
> >> jsdsi.xml.XmlWriter, and extended the jsdsi.S2X utility to support xml
> >> output.  Here's an example:
> >>
> >> Input S-expression:
> >>
> >> (cert
> >>   (issuer
> >>     (name
> >>       (public-key
> >>         (rsa-pkcs1-md5
> >>           (e #010001#)
> >>           (n
> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn
> >> 5mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk
> >> 2ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|)))
> >>       CarolJones))
> >>   (subject
> >>     (public-key
> >>       (rsa-pkcs1-md5
> >>         (e #010001#)
> >>         (n
> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R
> >> 2Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk
> >> 2SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|)))))
> >>
> >> Output XML:
> >>
> >> <cert>
> >>   <issuer>
> >>     <name>
> >>       <public-key>
> >>         <rsa-pkcs1-md5>
> >>           <e>
> >>             #010001#
> >>           </e>
> >>           <n>
> >>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn5
> >> mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk2
> >> ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|
> >>           </n>
> >>         </rsa-pkcs1-md5>
> >>       </public-key>
> >>       CarolJones
> >>     </name>
> >>   </issuer>
> >>   <subject>
> >>     <public-key>
> >>       <rsa-pkcs1-md5>
> >>         <e>
> >>           #010001#
> >>         </e>
> >>         <n>
> >>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R2
> >> Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk2
> >> SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|
> >>         </n>
> >>       </rsa-pkcs1-md5>
> >>     </public-key>
> >>   </subject>
> >> </cert>
> >>
> >> The problems with this are that it's not terribly compact (e.g., the
> >> "e" elements could be all on one line), I'm not sure whether all the
> >> characters used in the text blocks are allowed, there's no schema or
> >> DTD, and there's no XmlReader (yet).  But does this conversion look
> >> reasonable?
> >>
> >> Sameer
> >>
> >> http://ajmani.net
> >>
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> >> Build and deploy apps & Web services for Linux with
> >> a free DVD software kit from IBM. Click Now!
> >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> >> _______________________________________________
> >> Jsdsi-devel mailing list
> >> Jsd...@li...
> >> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> 
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] LDAP package

[Sean R. <sra...@ae...>]

The Novel stuff is JLDAP which is part of openLDAP. So one would assume
that it would be fine - I'll hunt downt the actual licence tomorrow to
make sure.

Luis (hello), if you have a copy of the licence to hand, if you could
email it to me then that would be great.

Sean

On Wed, 2004-02-25 at 22:36, Sameer Ajmani wrote:
> Luis,
> 
> The package is probably fine, as long as its license is compatible with
> JSDSI's (currently MIT, but maybe soon LGPL).
> 
> Sean -- do you know of any reason why the package Luis mentions below
> might be a problem?
> 
> Sameer
> 
> > Sameer,
> >
> > I'm using Novell's ldap package wich is a free package. In my opinion is
> > the best package and it works with the most popular ldap servers. Why
> > would to know if u have any issue on using this package?
> >
> >    -- Luis Pedro
> >
> >
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] LDAP package

[Sameer A. <aj...@cs...>]

Luis,

The package is probably fine, as long as its license is compatible with
JSDSI's (currently MIT, but maybe soon LGPL).

Sean -- do you know of any reason why the package Luis mentions below
might be a problem?

Sameer

> Sameer,
>
> I'm using Novell's ldap package wich is a free package. In my opinion is
> the best package and it works with the most popular ldap servers. Why
> would to know if u have any issue on using this package?
>
>    -- Luis Pedro
>
>

http://ajmani.net

Re: [Jsdsi-devel] JSDSI plan

[Sameer A. <aj...@cs...>]

> I will do the Mavenisation tomorrow or Friday. We don't need to agree on
> classpaths to external jars as we just reference them in the (your)
> Maven Repository - by the way I run my own 'remote maven repository' so
> makeing new project jar dependencies available for others is easy.

Cool!

> What version number shall will give this? I would suggest something like
> 0.5

Sure.

Sameer

Re: [Jsdsi-devel] JSDSI xml

[Sameer A. <aj...@cs...>]

> (at first I wondering if the placing of the 'local name' of CarolJones
> was correct, but I think it is the right thing to do - not many xml
> documents have a tag and a text value as direct children of another
> tag).

Yes, the string interspersed with elements are ugly (and maybe a problem).
 I'll try to write an XmlReader that inverts this process sometime soon,
and hopefully that will complain if this is invalid XML :)  It also may be
problematic if XML concatenates adjacent strings, e.g., (name (public-key
...) mary friends) will become:
<name>
  <public-key>...</public-key>
  mary friends
</name>

XML will read "mary friends" as a single block of character data, while
SPKI treasts it as two SexpStrings.  My XmlReader will handle this just
fine, but the XML form lacks some structural information.

An alternative is to make SPKI's syntax more XML-compatible by restricting
its S-expressions to SexpLists thatcontain one SexpString or an arbitrary
number of SexpLists.  So the above name object would be:
(name (public-key ...) (id mary) (id friends))

While this is ugly in the "name" case, it actually makes some other
structures clearer:

(hash md5 |hfslk782yf2|)
becomes:
(hash (algo md5) (value |hfslk782yf2|))

(k-of-n "2" "3"
 (public-key ...) (public-key ...) (public-key ...))
becomes:
(k-of-n (k "2") (n "3")
 (public-key ...) (public-key ...) (public-key ...))

This change would require consulting with the SPKI designers (I could
contact Carl Ellison about this).

Sameer

> On Wed, 2004-02-25 at 02:54, Sameer Ajmani wrote:
>> I have just committed a simple Sexp-to-XML converter to JSDSI.  This
>> makes it possible to express JSDSI objects as XML (by first converting
>> them to S-expressions).  I added the package jsdsi.xml and the class
>> jsdsi.xml.XmlWriter, and extended the jsdsi.S2X utility to support xml
>> output.  Here's an example:
>>
>> Input S-expression:
>>
>> (cert
>>   (issuer
>>     (name
>>       (public-key
>>         (rsa-pkcs1-md5
>>           (e #010001#)
>>           (n
>>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn
>> 5mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk
>> 2ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|)))
>>       CarolJones))
>>   (subject
>>     (public-key
>>       (rsa-pkcs1-md5
>>         (e #010001#)
>>         (n
>>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R
>> 2Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk
>> 2SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|)))))
>>
>> Output XML:
>>
>> <cert>
>>   <issuer>
>>     <name>
>>       <public-key>
>>         <rsa-pkcs1-md5>
>>           <e>
>>             #010001#
>>           </e>
>>           <n>
>>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn5
>> mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk2
>> ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|
>>           </n>
>>         </rsa-pkcs1-md5>
>>       </public-key>
>>       CarolJones
>>     </name>
>>   </issuer>
>>   <subject>
>>     <public-key>
>>       <rsa-pkcs1-md5>
>>         <e>
>>           #010001#
>>         </e>
>>         <n>
>>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R2
>> Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk2
>> SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|
>>         </n>
>>       </rsa-pkcs1-md5>
>>     </public-key>
>>   </subject>
>> </cert>
>>
>> The problems with this are that it's not terribly compact (e.g., the
>> "e" elements could be all on one line), I'm not sure whether all the
>> characters used in the text blocks are allowed, there's no schema or
>> DTD, and there's no XmlReader (yet).  But does this conversion look
>> reasonable?
>>
>> Sameer
>>
>> http://ajmani.net
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>> Build and deploy apps & Web services for Linux with
>> a free DVD software kit from IBM. Click Now!
>> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>> _______________________________________________
>> Jsdsi-devel mailing list
>> Jsd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com


http://ajmani.net

RE: [Jsdsi-devel] JSDSI plan

[Sean R. <sra...@ae...>]

I'm not clued up on LDAP really, but here is my 2-pence (sorry cents
worth)..


On Wed, 2004-02-25 at 12:39, Sameer Ajmani wrote:
> Comments inline:
> 
> > Here is the schema that i'm using:
> >
> >  cn (common name for the cert), u can see this as a unique name;
> 
> This should be the cryptographic hash (MD5 or SHA1) of the cert.  This is
> guaranteed to be unique (with high probability), and it makes it easy to
> find the cert if you already have its hash.

I agree


> >  javaSerializedObject (sdsi cert), i think that is the best way to
> > represent the certs,
> 
> I disagree...
> 
> > The 'javaSerializedObject' could also be an attribute with other name
> > where is content would be an encoded sdsi cert.
> 
> The standard way to represent any SDSI/SPKI object is as a canonical
> S-expression.  Keep in mind people may want to use this LDAP schema with
> non-Java libraries: javaSerializedObject is language-specific;
> S-expressions are language-independent (and are already part of the SPKI
> standard).  I suggest you rename this field to "canonicalSexp".  (Note
> that we can define jsdsi.Obj's serialized form to be its canonical Sexp
> form.)
Agree. And making jsdi.Obj implement java.io.Serializable in canonical Sexp form
is on my list of 'things to do'...


> >  issuerPubKey (issuer public key)
> Is this the hash of the key or its canonical S-expression?  I suggest
> hash, as this is probably how people will search for the key.
Agree. 
Though shouldn't you store the MD5/SHA1 of (issuer public-key-hash) 
- If you have the public-key-hash you can search using it. If you have
the publci-key you can still do so (create the public-key-hash and then
MD5/SHA1 it).
If you store the MD5/SHA1 of public-key and only have the
public-key-hash, you wouldn't be able to.

> >  subjectPubKey (subject public key)
> Is this the hash of the key or its canonical S-expression?  I suggest
> hash, as this is probably how people will search for the key.
Agree, as above
> What if the subject is a name?
yes, what if?

> >  name (name)
> Is this the issuer name or the subject name?
> 
> > The attribute 'name' can be used as optional(if the certs are AuthCerts,
> > doens't make sense the use of this). issuerPubKey and subjectPubKey are
> > needed to perform searchs with the currently selectors (Auth, Subject,
> > Compatible, Name), without having to desserialize the cert.
> 
> I don't think your schema actually supports NameCertSelector and
> CompatibleCertSelector simultaneously: a name cert's subject might also be
> a name, in which case you need separate fields for each.
> 
> So, here's my suggestion for a revised schema:
> 
> cn - canonical name: same as hashMD5
> hashMD5 - the MD5 hash of the cert
> hashSHA1 - the SHA1 hash of the cert
> canonicalSexp - the cert as a canonical s-expression
> issuerMD5 - the MD55 hash of the issuer public key
> issuerSHA1 - the SHA1 hash of the issuer public key
> issuerName - the name assigned by the issuer, if any
> subjectMD5 - the MD55 hash of the subject public key
> subjectSHA1 - the SHA1 hash of the subject public key
> subjectName - the first name component of the subject, if any
> notAfter - the expiration date, so the server can garbage-collect
Only issue is whether to store MD5/SHA1 of (issuer public-key-hash). 
- same as regards to subject

> My reason for supporting both SHA1 and MD5 is that they're both popular. 
> However, if this seems too complicated, we can make these separate
> records.  So each cert would have two records:
> 
> cn - MD5 hash of cert
> canonicalSexp
> issuer -MD5 of issuer key
> issuerName
> subject - MD5 of subject key
> subjectName
> notAfter
> 
> cn - SHA1 hash of cert
> canonicalSexp
> issuer - SHA1 of issuer key
> issuerName
> subject - SHA1 of subject key
> subjectName
> notAfter
> 
> But these records would have to have different type names (spkiCertMD5 and
> spkiCertSHA1, perhaps?) so that people know which hash function to use.
> 
> Sameer
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] JSDSI xml

[Sean R. <sra...@ae...>]

Look good to me Sameer. Nice stuff.

(at first I wondering if the placing of the 'local name' of CarolJones
was correct, but I think it is the right thing to do - not many xml
documents have a tag and a text value as direct children of another
tag).

Sean

On Wed, 2004-02-25 at 02:54, Sameer Ajmani wrote:
> I have just committed a simple Sexp-to-XML converter to JSDSI.  This makes
> it possible to express JSDSI objects as XML (by first converting them to
> S-expressions).  I added the package jsdsi.xml and the class
> jsdsi.xml.XmlWriter, and extended the jsdsi.S2X utility to support xml
> output.  Here's an example:
> 
> Input S-expression:
> 
> (cert
>   (issuer
>     (name
>       (public-key
>         (rsa-pkcs1-md5
>           (e #010001#)
>           (n
>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn
>             5mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk
>             2ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|)))
>       CarolJones))
>   (subject
>     (public-key
>       (rsa-pkcs1-md5
>         (e #010001#)
>         (n
>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R
>           2Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk
>           2SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|)))))
> 
> Output XML:
> 
> <cert>
>   <issuer>
>     <name>
>       <public-key>
>         <rsa-pkcs1-md5>
>           <e>
>             #010001#
>           </e>
>           <n>
>             |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn5
>             mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk2
>             ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|
>           </n>
>         </rsa-pkcs1-md5>
>       </public-key>
>       CarolJones
>     </name>
>   </issuer>
>   <subject>
>     <public-key>
>       <rsa-pkcs1-md5>
>         <e>
>           #010001#
>         </e>
>         <n>
>           |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R2
>           Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk2
>           SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|
>         </n>
>       </rsa-pkcs1-md5>
>     </public-key>
>   </subject>
> </cert>
> 
> The problems with this are that it's not terribly compact (e.g., the "e"
> elements could be all on one line), I'm not sure whether all the
> characters used in the text blocks are allowed, there's no schema or DTD,
> and there's no XmlReader (yet).  But does this conversion look reasonable?
> 
> Sameer
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

RE: [Jsdsi-devel] JSDSI plan

[Sameer A. <aj...@cs...>]

Comments inline:

> Here is the schema that i'm using:
>
>  cn (common name for the cert), u can see this as a unique name;

This should be the cryptographic hash (MD5 or SHA1) of the cert.  This is
guaranteed to be unique (with high probability), and it makes it easy to
find the cert if you already have its hash.

>  javaSerializedObject (sdsi cert), i think that is the best way to
> represent the certs,

I disagree...

> The 'javaSerializedObject' could also be an attribute with other name
> where is content would be an encoded sdsi cert.

The standard way to represent any SDSI/SPKI object is as a canonical
S-expression.  Keep in mind people may want to use this LDAP schema with
non-Java libraries: javaSerializedObject is language-specific;
S-expressions are language-independent (and are already part of the SPKI
standard).  I suggest you rename this field to "canonicalSexp".  (Note
that we can define jsdsi.Obj's serialized form to be its canonical Sexp
form.)

>  issuerPubKey (issuer public key)
Is this the hash of the key or its canonical S-expression?  I suggest
hash, as this is probably how people will search for the key.

>  subjectPubKey (subject public key)
Is this the hash of the key or its canonical S-expression?  I suggest
hash, as this is probably how people will search for the key.

What if the subject is a name?

>  name (name)
Is this the issuer name or the subject name?

> The attribute 'name' can be used as optional(if the certs are AuthCerts,
> doens't make sense the use of this). issuerPubKey and subjectPubKey are
> needed to perform searchs with the currently selectors (Auth, Subject,
> Compatible, Name), without having to desserialize the cert.

I don't think your schema actually supports NameCertSelector and
CompatibleCertSelector simultaneously: a name cert's subject might also be
a name, in which case you need separate fields for each.

So, here's my suggestion for a revised schema:

cn - canonical name: same as hashMD5
hashMD5 - the MD5 hash of the cert
hashSHA1 - the SHA1 hash of the cert
canonicalSexp - the cert as a canonical s-expression
issuerMD5 - the MD55 hash of the issuer public key
issuerSHA1 - the SHA1 hash of the issuer public key
issuerName - the name assigned by the issuer, if any
subjectMD5 - the MD55 hash of the subject public key
subjectSHA1 - the SHA1 hash of the subject public key
subjectName - the first name component of the subject, if any
notAfter - the expiration date, so the server can garbage-collect

My reason for supporting both SHA1 and MD5 is that they're both popular. 
However, if this seems too complicated, we can make these separate
records.  So each cert would have two records:

cn - MD5 hash of cert
canonicalSexp
issuer -MD5 of issuer key
issuerName
subject - MD5 of subject key
subjectName
notAfter

cn - SHA1 hash of cert
canonicalSexp
issuer - SHA1 of issuer key
issuerName
subject - SHA1 of subject key
subjectName
notAfter

But these records would have to have different type names (spkiCertMD5 and
spkiCertSHA1, perhaps?) so that people know which hash function to use.

Sameer

RE: [Jsdsi-devel] JSDSI plan

[Luis P. <lp...@ne...>]

Sameer, 

I like to put the schema to discussion.

In my project i see the ldap server just as a repository for certs and
because of this i don't have certs associated with users like it usual with
X509 certs. Of course that anyone can make that association if it like but
as to follow the schema.

Here is the schema that i'm using:

 cn (common name for the cert), u can see this as a unique name;
 javaSerializedObject (sdsi cert), i think that is the best way to represent
the certs,
 issuerPubKey (issuer public key)
 subjectPubKey (subject public key)
 name (name)  

The attribute 'name' can be used as optional(if the certs are AuthCerts,
doens't make sense the use of this). issuerPubKey and subjectPubKey are
needed to perform searchs with the currently selectors (Auth, Subject,
Compatible, Name), without having to desserialize the cert.

I think that the certs should be searched on the ldap without getting all to
an object like a MultiMap to apply the selectors.

The 'javaSerializedObject' could, also be an attribute with other name where
is content would be an encoded sdsi cert. 

   -- Luis Pedro
 

Re: [Jsdsi-devel] JSDSI plan

[Sean R. <sra...@ae...>]

All sounds good to me.

I will do the Mavenisation tomorrow or Friday. We don't need to agree on
classpaths to external jars as we just reference them in the (your)
Maven Repository - by the way I run my own 'remote maven repository' so
makeing new project jar dependencies available for others is easy.

What version number shall will give this? I would suggest something like
0.5

Sean

On Tue, 2004-02-24 at 22:49, Sameer Ajmani wrote:
> JSDSI developers,
> 
> We've had a lot of activity lately.  It's time we start thinking about how
> to coordinate our efforst, so that we don't conflict.  Here's what I see
> in the immediate future:
> 
> Sean: Eclipsify and Mavenize JSDSI.  First priority is just to get the
> vital Eclipse files (.project, .classpath) in the repository (we'll have
> to agree on classpaths to any externasl jars, such as Cryptix), and make
> sure the tests all run properly (we may have to move the data files used
> by the tests).  Let us know when this part is done, so we can resume
> working.  Also, feel free to add a jsdsi.process package (or whatever name
> you think is appropriate) for the various classes you described to me
> earlier.  I'm still a little concerned about the security implications of
> SuffixTag, so be sure to document it clearly if you choose to implement
> it.
> 
> Luis: Once Sean says the repository is ready, feel free to add a
> jsdsi.ldap package and add your new files there.  Let's discuss how to
> integrate LDAP with the cert path parameters on jsdsi-devel.
> 
> Michael: it seems you're busy with other things right now.  Is there some
> part of JSDSI you'd like to work on?
> 
> Sameer: investigate better parsing techniques; add documentation and tests
> for core classes.  Create jsdsi.xml package using some canonical sexp to
> xml translation.
> 
> All: add tests to jsdsi.test for any classes you write.
> 
> All: if you need to change a class in jsdsi or jsdsi.sexp, please consult
> me first.
> 
> Sameer
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] JSDSI xml

[Sameer A. <aj...@cs...>]

I have just committed a simple Sexp-to-XML converter to JSDSI.  This makes
it possible to express JSDSI objects as XML (by first converting them to
S-expressions).  I added the package jsdsi.xml and the class
jsdsi.xml.XmlWriter, and extended the jsdsi.S2X utility to support xml
output.  Here's an example:

Input S-expression:

(cert
  (issuer
    (name
      (public-key
        (rsa-pkcs1-md5
          (e #010001#)
          (n
            |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn
            5mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk
            2ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|)))
      CarolJones))
  (subject
    (public-key
      (rsa-pkcs1-md5
        (e #010001#)
        (n
          |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R
          2Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk
          2SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|)))))

Output XML:

<cert>
  <issuer>
    <name>
      <public-key>
        <rsa-pkcs1-md5>
          <e>
            #010001#
          </e>
          <n>
            |AKd6zpHoNSq53rFFZ6XZV5m+YZKr1Ym9fUMuE8yHMOZx9AsrWqkZyMxZ9Cn5
            mIPaTLqYEakoJ7lir25a/Nq1IpvFC8mlalpI2LINDRnIt3HbmiFEj97Eaqk2
            ffhwXotFHIbPGyrgrMobOtWIpG56Ru5AK230lG68+ZyntCqB53v5|
          </n>
        </rsa-pkcs1-md5>
      </public-key>
      CarolJones
    </name>
  </issuer>
  <subject>
    <public-key>
      <rsa-pkcs1-md5>
        <e>
          #010001#
        </e>
        <n>
          |AK0aiccf7Yj/Gzx93m6R6suJiPr5o9ZON6dG31wwDyGK2aKoMJUYLxVMWGh5R2
          Wsc+RO+ylvablNhmO7zGiZ9qNiN+vdTjdxMALx4ULFF1aYNi86QsSgU/x8Xrk2
          SiHQ9EkHGDJ7Bpng+4LNSjQtm2DuEscHP3mqz8BzGB+jTek/|
        </n>
      </rsa-pkcs1-md5>
    </public-key>
  </subject>
</cert>

The problems with this are that it's not terribly compact (e.g., the "e"
elements could be all on one line), I'm not sure whether all the
characters used in the text blocks are allowed, there's no schema or DTD,
and there's no XmlReader (yet).  But does this conversion look reasonable?

Sameer

http://ajmani.net

[Jsdsi-devel] JSDSI plan

[Sameer A. <aj...@cs...>]

JSDSI developers,

We've had a lot of activity lately.  It's time we start thinking about how
to coordinate our efforst, so that we don't conflict.  Here's what I see
in the immediate future:

Sean: Eclipsify and Mavenize JSDSI.  First priority is just to get the
vital Eclipse files (.project, .classpath) in the repository (we'll have
to agree on classpaths to any externasl jars, such as Cryptix), and make
sure the tests all run properly (we may have to move the data files used
by the tests).  Let us know when this part is done, so we can resume
working.  Also, feel free to add a jsdsi.process package (or whatever name
you think is appropriate) for the various classes you described to me
earlier.  I'm still a little concerned about the security implications of
SuffixTag, so be sure to document it clearly if you choose to implement
it.

Luis: Once Sean says the repository is ready, feel free to add a
jsdsi.ldap package and add your new files there.  Let's discuss how to
integrate LDAP with the cert path parameters on jsdsi-devel.

Michael: it seems you're busy with other things right now.  Is there some
part of JSDSI you'd like to work on?

Sameer: investigate better parsing techniques; add documentation and tests
for core classes.  Create jsdsi.xml package using some canonical sexp to
xml translation.

All: add tests to jsdsi.test for any classes you write.

All: if you need to change a class in jsdsi or jsdsi.sexp, please consult
me first.

Sameer

http://ajmani.net

Re: [Jsdsi-devel] Re: ConChord

[Sameer A. <aj...@cs...>]

> So what 'version' of algorythms are currently in jsdsi? I presume that
> the RProver uses the 'unresolution' algorythms you describe in 'How to
> Resolve SDSI Names Without Closure'? And the FProver relies on
> 'closure'?

Neither relies on global closure.  If you have closure (i.e., in a
logically-centralized system like ConChord) then no certificate chain
discovery algorithm is needed: all cert chains have already been generated
and indexed.

RProver does "unresolution", a.k.a. subject-based resolution: given a key,
it finds the names / auths granted to that key.  RProver accesses the
CertStore using only SubjectCertSelectors and CompatibleCertSelectors, so
it's designed for the "each principal stores certs issued to them"
architecture.

FProver does "resolution", a.k.a. issuer-based resolution: given an issuer
key and name or auth, it finds the subjects in the value of that name /
that receive that auth.  FProver accesses the CertStore using only
AuthCertSelectors and NameCertSelectors, so it's designed for the "each
principal store sthe certs it issues" architecture.

Sameer