RE: Proposal for stating key type in Commonline subject lines-Reply

["Thien, Will" <will.thien@tgslc.org>]

We have built / building our process is a little different. We pull down
based on subject and the files get placed in directories accordingly.
Along with the file attachments we create a message text file to go with
the downloaded files. I create a control file with e-mail information
and cross reference key encryption information. Since our e-mail system
is generic and can be used on Non-Commonline transmissions, we plan to
use the message area for these system to help in processing.  This gives
us a lot of area for processing information. It will make no difference
to us to use the subject area for CommonLine transmissions, we will be
able to process either way. I can see your reasoning for your process.

wajt


> -----Original Message-----
> From:	PAUL LOGSTON [SMTP:PLOGSTON@usagroup.com]
> Sent:	Friday, March 20, 1998 10:50 AM
> To:	cl-elec-exch@lists.glhec.org; will.thien@tgslc.org
> Subject:	RE: Proposal for stating key type in Commonline subject
> lines-Reply
> 
> The main reason for using the subject line is so that the person
> downloading the mail can filter it by patterns in the subject line. 
> Otherwise, the receiver would have to download the entire message to
> see this information.
> 
> >>> "Thien, Will" <will.thien@tgslc.org> 03/20/98 08:30am >>>
> I know this is just my ignorance. Can we just encrypt the attachments
> and use the message area for other information like encryption type or
> other things we could standardize ? This would leave the subject area
> alone. Is the reason we only use the subject area is because of old
> CompuServe design ?
> 
> 
> 
> 
> > -----Original Message-----
> > From:	PAUL LOGSTON [SMTP:PLOGSTON@usagroup.com]
> > Sent:	Thursday, March 19, 1998 9:38 AM
> > To:	cl-elec-exch@lists.glhec.org
> > Subject:	Proposal for stating key type in Commonline subject
> > lines
> > 
> > 
> > [Adminstrivia: When I use the word "Decrypt", I actually mean
> "Decrypt
> > and Verify Signature".  I'm just too lazy to type that every time.]
> > 
> > During last week's conference call, we determined that it would be
> > useful
> > to specify the key type (RSA or D-H/DSS) in the subject line in the
> > message header, so we could know which key type to use to decrypt
> the
> > message and verify the signature.
> > 
> > The reason we need to know this information is that we may be using
> > two
> > separate PGP products to decrypt files -- one for the RSA keys and
> one
> > for D-H/DSS.  This is due to the fact that PGP's two programming
> > interfaces (the Toolkit and the SDK) only support one key type each.
> 
> > Specifically, the PGP/ViaCrypt Toolkit only supports RSA keys and
> the
> > SDK
> > only supports D-H/DSS.  And, since we are using different tools for
> > each
> > key type, we would likely need to keep separate key rings by key
> type.
> > 
> > All of this points to needing to know the key type used for the
> > encryption
> > before actually processing the file.
> > 
> > However, it is pretty late in the game to be changing the subject
> > lines for
> > CommonLine, since a lot of us (me included) already have code
> written
> > that looks for and specifies the old subject lines.  So, specifying
> > the key
> > type must:
> > 
> > a) be optional, and
> > b) be compatible.
> > 
> > There for, I propose adding an optional identifier after the old
> > CommonLine
> > subject string, but before the optional identifying information.
> That
> > identifier should simply be either "KEYRSA" or "KEYD-H", enclosed in
> > brackets.  So, in general, our new subject line format would be:
> > 
> >     file-identifying-subject [KEYRSA | KEYD-H] <unique identifying
> > number>
> > 
> > The reason for the delimiters around the key type is: a) it is more
> > readable (IMHO) and b) it makes it easier to parse automatically.
> The
> > reason I added the phrase "KEY" to the identifiers is simply to
> drive
> > home
> > the purpose of the field.
> > 
> > For example, a CommonLine v3 App Send file's subject could look like
> > this:
> >     COM03 APP SEND [KEYRSA] <199803180017>
> > 
> > A CommonLine key update transaction with a Diffie-Hellman key would
> > look like:
> >     CL COMM UPDATE [KEYD-H] <USA GROUP GUARANTEE SERVICES>
> > 
> > Since the Key Type is optional, the following is a CommonLine v2 App
> > Response using RSA keys:
> >     COM96 APP RESP <GC19140201>
> > 
> > Comments?