janitor-dev — dev

[secure-MUA-dev] Re: [secure-mua] is mailman ok?

[Jason P. <ja...@py...>]

de...@sm... is a mailman list.

i thought you didnt want to use that sourceforge list

i am confused.

-jp

[Janitor-dev] Re: [secure-mua] API (cont.)

[Jason P. <ja...@py...>]

just finish a phone conversation w/mike:

ideas were: 3 topics, TOPIC 1, TOPIC 2, TOPIC 3

TOPIC 1:

 confdir/
 cert.xml=
  <?xml version="1.0"?>
  <!-- this is a cert index file -->
  <target t="ja...@py..." include=1></target>
  <target t="ra...@sm..." include=1></target>
  <target t="da...@sm...">
   <proto p=pgp></proto>
   <proto p=smime>
    <cert>
    </cert>
   </proto>
  </target>


  confdir/ja...@py.../cert.xml=
  <?xml version="1.0"?>
  <!-- this is a cert index file for ja...@py... -->
   <proto p=pgp include=1></proto>
   <proto p=smime>
    <cert>
    </cert>
   </proto>
  
  confdir/ja...@py.../pgp/cert.xml=
  <?xml version="1.0"?>
  <!-- this is a cert index file for ja...@py... using pgp -->
    <cert>
    </cert>


TOPIC 2:

the data has 2 indexes target & protocol, the data storage should be
searchable by both. But with out using a database or binary file that
would not be feasable.

drop back to idea in TOPIC 1, but do not limit to only using that, just
use the above for proof of concept.

an interface to the above or substitute, would be like:

  getcert(target,proto)

it would then query, all avail resources it local db (most likely the xml 
db above, then a LDAP server, etc) returning a cert it if can

TOPIC 3:

a MUA should pass all headers to the encryption rutines
further the mime message should be passed in a "vector" form for each
multipart of a message, only if the MUA knows that the enc rutines does
not need somepart/information should it not pass it to the rutines

ie

doencrutine( headers, type&datapair [] )


this could be done using xml as well, but that is irrelevant right now.

headers
text/html, part1data
text,      part2data
sig/pgp,   part3data
smime/bla, part4data

TOPIC 4:

project name is irrelevant. it is the smime project with 4 parts which
needs to be compleated

http://smime.pyerotechnics.com

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                     -
- Jason Pyeron              Pyerotechnics Development -
- Projects Manager          Suite 101/2937 St Paul St -
- 410 467 2266              Baltimore, Maryland 21218 -
-                                                     -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


On Wed, 17 Jan 2001, Dan Kegel wrote:

> Mike Schiraldi wrote:
> > After talking this over with coworkers, perhaps a hybrid solution is in
> > order - XML definitely makes sense for the file format, but it's not easy
> > to search through. So maybe we should have each chunk of data be stored as
> >XML, but save it in a directory hierarchy like we talked about:
> 
> That sounds sensible.
> 
> (By the way, Universal Keyring is a nice project name.No google hits.
> ukr is not a great abbreviation, though, since it matches the abbreviation
> for Ukraine, and there are scads of google hits..ukeyring is nice
> and unique.)
> 
> - Dan
> 
> To unsubscribe from this group, send an email to:
> sec...@eg...
> 
> 
> 

[Janitor-dev] Re: mutt and S/MIME

[Jason P. <ja...@py...>]

working things out in my head I realized that some users have multiple
emails in a cert (the spec allows this) but not all of their certs will
be the same so a tree should use the prog/cert/owner struct.


BUT 


it would be nice to view by owner/prog/cert 

it would be nice to use a dual index, but that would require not using a
tree(directory struct) instead a hash from a file or a sql table.

opinions?

On Wed, 10 Jan 2001, Mike Schiraldi wrote:

> Dan: Jason and i propose calling the project "janitor", at least for the
> time being. (it's better than foobar, i suppose). The name, of course,
> comes from the fact that it's got a whole bunch of keys.
> 
> Anyway, i was musing on a way of storing the keys. How about something
> like this:
> 
> .janitor/<protocol>/<datatype>/<identifier>
> 
> e.g.
> 
> .janitor/smime/certificates/bo...@ya...
> .janitor/smime/private-keys/my-private-key-1
> .janitor/smime/private-keys/my-private-key-2
> .janitor/gpg/public-keys/rm...@gn...
> 
> That might actually remove a layer - we wouldn't have to write any
> database code. Instead of calling "database --smime
> --display-the-certificate-for ju...@co..." and looking at the output,
> you could just call "cat .janitor/smime/certificates/ju...@co..." and
> look at the output.
>