Subject: Re: interchange format for certificates?
From: "Housley, Russ" <[email-masked]>
To: [email-masked], [email-masked]
Date: Tue, 24 Sep 96 14:31:17

You are correct that PKIX is not defining a format for the certificate 
cache; however, Part 2 will address ways to obtain certificates from the 
net.  As you point out, this only deals with a method of obtaining public 
keys.

The transfer of private keys between multiple systems is an open issue.  
Clearly, people who use hardware tokens do not have a problem.  These 
people simple move the token from system to sytem.  Users of software 
cryptography do need a solution.  I know that Microsoft has defined a 
solution for their environment.  Perhaps they are willing to share their 
solution with the Internet?

Russ

______________________________ Reply Separator _________________________________
Subject: interchange format for certificates?
Author:  [email-masked] at internet
Date:    9/21/96 7:36 PM

Hi,

I am not a member of this list so I will not see responses 
that are not directed to me.  I am not sure if the following 
is something your group would be willing to address.  

The use of certificates is becoming more common.  In my view 
there appears to be a problem that has yet to be solved:  

  Each vendor stores the X.509 and other certificates in
  a proprietary file format that cannot be exchanged between 
  computer systems.  For example:  I have a Macintosh at 
  home and a Windows machine at work.  I reciently had to 
  aquire *TWO* certificates from Verisign because they have 
  defined no interchange format allowing me to convert my 
  private keys to an interchange form, copy them to the 
  other system, and reimport them for use in that system.

It seems to me that a simple interchange format, possibly 
patterned after the way the PGP people ASCIIify their keys, 
would be useful.  I do not know why Verisign did not do this 
for their certificates, but maybe the IETF can define an 
informational or experimental RFC describing an interchange 
format and encourage Verisign and other entities to adopt and 
implement it.  

What to you all think,
[email-masked]

From: John Marchioni <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "'John Kennedy'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: RE: NOTICE: DSS Profile for X.509 Certificates to be deleted.
Date: Tue, 24 Sep 1996 13:38:27 -0700

{ JK's comments }

Basically, I agree that the X9.57 ARC should be used for certificates =
but I=20
disagree regarding the use of the X9.57 ARC for the public numbers and =
system parameters.  Why not stick with the X.42 ARC for those?

Regards,

-John Kennedy

p.s. For follow-ups, I suggest we prune down the distribution to only =
Cc:=20
[email-masked] and [email-masked]

OK by me, I thought X9.42 was still lacking a registered ARC, that's the =
only reason I suggested using X9.57's ARC.  It would be nice, if X9.57 =
does include the Diffie-Hellman certificate profile, to have all related =
OIDs for Diffie-Hellman (the X9.42 OID values) also included in X9.57, =
just a suggestion.

- John Marchioni

Subject: Re: Authorization on WEB using Certs?
To: "PALAMBER.US.ORACLE.COM" <[email-masked]>
Date: Tue, 24 Sep 1996 08:06:38 +0100 (BST)
From: Ben Laurie <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Content-Length: 1830      

PALAMBER.US.ORACLE.COM wrote:
> 
> 
> --=_ORCL_7816495_0_11919609231949230
> Content-Transfer-Encoding:7bit
> Content-Type:text/plain; charset="US-ASCII"
> 
>  
> The W3C has an activity on "Web Content Signing". 

Yeah, and its a nice friendly closed group, price of admission $50,000.

Cheers,

Ben.

>  
> Paul 
>  
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
> Paul Lambert                     Director of Security Products 
> Oracle Corporation               Phone:         (415) 506-0370 
> 500 Oracle Parkway, Box 659410     Fax:         (415) 633-2963 
> Redwood Shores, CA  94065       E-Mail: [email-masked] 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
> "Secure Jobs"  ->  send resumes to: [email-masked]   
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
>   
> 
> 
> --=_ORCL_7816495_0_11919609231949230
> Content-Type:message/rfc822
> 
> Date: 23 Sep 96 13:26:57
> From:"Sri Vidya Rajagopal <[email-masked]>" <[email-masked]>
> To:[email-masked]
> Subject:Authorization on WEB using Certs?
> X-Mailer:Elm [revision: 112.2]
> MIME-Version: 1.0
> Content-Transfer-Encoding:7bit
> Content-Type:text/plain; charset="US-ASCII"
> 
> Hi! 
> Does anyone know of any standards or document to do AUthorization of
> Web Documents using Certificates? I am looking for any information/pointers
> we pages... anything to get me going in the right direction.
> 
> 
> thanks
> 
> -sri
> 
> 
> --=_ORCL_7816495_0_11919609231949230--
> 

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: [email-masked]
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.            Apache Group member (http://www.apache.org)

Date: 23 Sep 96 18:04:34 -0700
From: "PALAMBER.US.ORACLE.COM" <[email-masked]>
To: [email-masked]
Subject: Re: Authorization on WEB using Certs?
Cc: [email-masked]

--=_ORCL_7816495_0_11919609231949230
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"

The W3C has an activity on "Web Content Signing". 
 
Paul 
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
Paul Lambert                     Director of Security Products 
Oracle Corporation               Phone:         (415) 506-0370 
500 Oracle Parkway, Box 659410     Fax:         (415) 633-2963 
Redwood Shores, CA  94065       E-Mail: [email-masked] 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
"Secure Jobs"  ->  send resumes to: [email-masked]   
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

--=_ORCL_7816495_0_11919609231949230
Content-Type:message/rfc822

Date: 23 Sep 96 13:26:57
From:"Sri Vidya Rajagopal <[email-masked]>" <[email-masked]>
To:[email-masked]
Subject:Authorization on WEB using Certs?
X-Mailer:Elm [revision: 112.2]
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"

Hi! 
Does anyone know of any standards or document to do AUthorization of
Web Documents using Certificates? I am looking for any information/pointers
we pages... anything to get me going in the right direction.

thanks

-sri

--=_ORCL_7816495_0_11919609231949230--

From: Sri Vidya Rajagopal <[email-masked]>
Subject: test
To: [email-masked]
Date: Mon, 23 Sep 1996 15:31:16 PDT

testing out to see if I can get a discussion started, is this the right 
address, I found it on the WEB.

-Sri Rajagopal
--

Date: Mon, 23 Sep 96 14:44:38 PDT
From: John Kennedy <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: RE: NOTICE: DSS Profile for X.509 Certificates to be deleted.
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

  > At 10:40 AM 9/23/96 -0700, John Marchioni wrote:

{Recommendation from John Marchioni deleted}
 
  > 
  > For the benefit of everyone, I have attached below a copy of the 
referenced
  > e-mail from me.  I won't include the uuencoded Word attachment on such a
  > wide distribution as this message, but will send it to anyone requesting
  >  it.
  > 
  > >The Diffie-Hellman cert profile should be added next when it is agreed
  >  that
  > the D-H cert section of ANSI >X9.42 is stable.  I recommend that the IETF
  > and ANSI X9.42 use the same ARC for OIDs as in X9.57 when >dealing with
  >  D-H
  > keys and certificates, if this ARC is registered and valid.
  > 
  > The X9.57 arc is certainly registered (under ANSI as an ANSI standard)
  >  and
  > valid, and we have used it for X9.57 and X9.55.  I would not object to
  >  using
  > it also for X9.42

Warwick,

I have just received a newly assigned ARC for ANSI X9.42 (Diffie-Hellman).  I 
suspect the parameter syntax and encoding section for X9.42 to undergo some 
revision after the ANSI X9.F1 next week after I get some feedback. (BTW, you 
should have received hardcopy of this document a few weeks ago.  Please let me 
know if you haven't. (That goes for anyone else that needs a copy, too)).

I have assumed that X9.57 and X9.55 would be integrating details on 
constructing and encoding Diffie-Hellman certificates.  I.e., I deliberately 
ommitted a D-H certificate section since I considered out of scope.  As such, 
I only specified public number and system parameter syntax and encoding in 
X9.42.

Basically, I agree that the X9.57 ARC should be used for certificates but I 
disagree regarding the use of the X9.57 ARC for the public numbers and system 
parameters.  Why not stick with the X.42 ARC for those?

Regards,

-John Kennedy

p.s. For follow-ups, I suggest we prune down the distribution to only Cc: 
[email-masked] and [email-masked]

Date: Mon, 23 Sep 1996 17:08:00 -0400
To: John Marchioni <[email-masked]>, "[email-masked]" <[email-masked]>, "'carlisle (c.m.) adams'" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: RE: NOTICE: DSS Profile for X.509 Certificates to be deleted. 
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

At 10:40 AM 9/23/96 -0700, John Marchioni wrote:
>That's correct, it should have been "section 7" of "pkix-1" which is
essentially correct but we don't like the current OID value for DSA with
SHA1, looks like the leftover from the NIST OIW/OSE.  
>
>Warwick just distributed a softcopy of a paper from his work with the NIST
PKI TWG which seems to be >comprehensive in filling in the holes for DSA
certs.  If Warwick folds this into "section 7" then I think >the DSA cert
profile work for IETF is complete for now.  

For the benefit of everyone, I have attached below a copy of the referenced
e-mail from me.  I won't include the uuencoded Word attachment on such a
wide distribution as this message, but will send it to anyone requesting it.

>The Diffie-Hellman cert profile should be added next when it is agreed that
the D-H cert section of ANSI >X9.42 is stable.  I recommend that the IETF
and ANSI X9.42 use the same ARC for OIDs as in X9.57 when >dealing with D-H
keys and certificates, if this ARC is registered and valid.

The X9.57 arc is certainly registered (under ANSI as an ANSI standard) and
valid, and we have used it for X9.57 and X9.55.  I would not object to using
it also for X9.42

Warwick
----------------------------------
>Date: Mon, 23 Sep 1996 10:39:36 -0400
>To: [email-masked],[email-masked]
>From: Warwick Ford <[email-masked]>
>Subject: DSA Algorithm Definitions
>X-Attachments: C:\Business\ANSIX9\Algids.doc;
>
>Attached are the latest algorithm definitions from ANSI X9.57.  When Russ,
Rich Ankney, and I devised this set, we hoped we had developed one answer
that would satisfy everyone (ANSI, PKIX, and the FPKI).
>
>There are 3 algorithmIds:
>- dsa - has p, q, and g parameters - for use in subjectPublicKeyInfo
>- dsa-with-sha-1 - no parameters - for use in the signature fields
>- dsa-match - has key length as parameter - for use in those situations
where you want to determine the capabilities of a remote system, e.g., in
supportedAlgorithms attribute
> 
>Warwick
>
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

Date: Mon, 23 Sep 1996 16:44:58 -0400
To: [email-masked], [email-masked], [email-masked]
From: Warwick Ford <[email-masked]>
Subject: X.509 Bug Regarding Policy Constraints
Cc: [email-masked]

An error has been uncovered regarding policy constraints in the X.509
certificate extensions amendment.  I have drafted the attached defect report
for consideration at the October meeting of the ISO/IEC/ITU Directory group.
I would appreciate hearing from anyone who objects to policySet being
deleted from policy constraints.

Thanks to John Pawling of JG VanDyke for finding the error.  

Warwick
--------------------------------------

DEFECT REPORT FORM

1.	Defect Report Number:	9594/

2.	Source:   	Warwick Ford	

3.	Addressed to:	ISO/IEC JTC1/SC21/WG4 and CCITT Study Group VII
		Editor Group on the Directory

4.	(a)  WG Secretariat:	Japan (JISC)
	(b)  CCITT WP:	SG VII/WP IV

5.	Date Circulated by WG Secretariat:

6.	Deadline for Response from Editor:

7.	Defect Report Concerning:
	(number and title of IS or DIS final text/CCITT Recommendation)

X.509 & IS 9594-8 The Directory - Authentication Framework - Amendment 1 on
Certificate Extensions

8.	Qualifier:   (e.g.: error, omission, clarification required)	

Error

9.	References in Document:  (e.g.: page, clause/section, figure, and/or
table numbers)

	12.4.2.3 and 12.4.3

10.	Nature of Defect:  (complete, concise explanation of the perceived problem)

12.4.2.3 (Policy constraints field) includes a policySet component in the
ASN.1 and describes its semantics, but the path processing procedure in
12.4.3 does not include processing for that component.  If processing for
policySet were to be added to 12.4.3, the algorithm would become very
complex, with little real benefit.  It is the submitter's contention that
policySet should have been removed in the DAM editing process (the same
component was removed from the Name constraints field), but was
inadvertently left in.

11.	Solution Proposed by the Source:  (optional)

In 12.4.2.3, remove the policySet component from the ASN.1 and delete the
first paragraph after the ASN.1.  Also remove the SEQUENCE OF from the
ASN.1, as this becomes unnecessary.  Assign the extension a new OID (id-ce
36) to avoid confusion.  Reflect the same ASN.1 changes in Annex A.

12.	Editor's Response:
(any material proposed for processing as an erratum to, an amendment to, or a
commentary on the IS or DIS final text/CCITT Recommendation or Draft
Recommendation is attached separately to this completed report).

-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

From: Sri Vidya Rajagopal <[email-masked]>
Subject: Authorization on WEB using Certs?
To: [email-masked]
Date: Mon, 23 Sep 1996 13:26:57 PDT

Hi! 
Does anyone know of any standards or document to do AUthorization of
Web Documents using Certificates? I am looking for any information/pointers
we pages... anything to get me going in the right direction.

thanks

-sri

From: John Marchioni <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'carlisle (c.m.) adams'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: NOTICE: DSS Profile for X.509 Certificates to be deleted. 
Date: Mon, 23 Sep 1996 10:40:42 -0700

That's correct, it should have been "section 7" of "pkix-1" which is =
essentially correct but we don't like the current OID value for DSA with =
SHA1, looks like the leftover from the NIST OIW/OSE. =20

Warwick just distributed a softcopy of a paper from his work with the =
NIST PKI TWG which seems to be comprehensive in filling in the holes for =
DSA certs.  If Warwick folds this into "section 7" then I think the DSA =
cert profile work for IETF is complete for now. =20

The Diffie-Hellman cert profile should be added next when it is agreed =
that the D-H cert section of ANSI X9.42 is stable.  I recommend that the =
IETF and ANSI X9.42 use the same ARC for OIDs as in X9.57 when dealing =
with D-H keys and certificates, if this ARC is registered and valid.
- John

----------
From: 	carlisle (c.m.) adams
Sent: 	Monday, September 23, 1996 7:23 AM
To: 	[email-masked]
Cc: 	[email-masked]; [email-masked]; [email-masked]; =
[email-masked]; [email-masked]
Subject: 	re:NOTICE: DSS Profile for X.509 Certificates to be deleted.=20

In message "NOTICE: DSS Profile for X.509 Certificates to be deleted.",=20
[email-masked] writes:

>
>I received the following message from the Internet-Drafts Administrator =
about=20
>a month ago regarding the deletion of the I-D John Marchioni and I =
co-authored=20
>on a "DSS Profile for X.509 Certificates".  This draft was submitted =
only as=20
>an interim solution since the PKIX was just coming up to speed and had =
not yet=20
>included this material in the PKIX draft.  I do not know exactly what =
the=20
>status of the X.509 DSS profile is in the PKIX document so I am sharing =
this=20
>current status information with you now.  As far as I know DSS =
Certificates=20
>are being used in both the SKIP and ISAKMP/Oakley reference =
implementations=20
>and the aforementioned draft is cited in the applicable I-D's for these =
key=20
>management protocols.
>
>I have a number of choices:
>
>a) Do nothing and let the draft gracefully expire.
>b) Update and submit a revised draft of =

X400-Received:   by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 23 Sep 1996 11:36:26 -0400 
X400-Received:   by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 23 Sep 1996 10:32:06 -0400 
X400-Received:   by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 23 Sep 1996 10:23:00 -0400 
Date:  Mon, 23 Sep 1996 10:23:00 -0400 
X400-Originator:  /dd.id=1651623/g=carlisle/i=cm/s=adams/@bnr.ca 
X400-MTS-Identifier:   [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.690:23.08.96.14.32.06] 
X400-Content-Type:  P2-1984 (2) 
Content-Identifier:  re:NOTICE: DS... 
From: "carlisle (c.m.) adams" <[email-masked]>
Sender: "carlisle (c.m.) adams" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject:  re:NOTICE: DSS Profile for X.509 Certificates to be deleted.

In message "NOTICE: DSS Profile for X.509 Certificates to be deleted.", 
[email-masked] writes:

>
>I received the following message from the Internet-Drafts Administrator about 
>a month ago regarding the deletion of the I-D John Marchioni and I co-authored 
>on a "DSS Profile for X.509 Certificates".  This draft was submitted only as 
>an interim solution since the PKIX was just coming up to speed and had not yet 
>included this material in the PKIX draft.  I do not know exactly what the 
>status of the X.509 DSS profile is in the PKIX document so I am sharing this 
>current status information with you now.  As far as I know DSS Certificates 
>are being used in both the SKIP and ISAKMP/Oakley reference implementations 
>and the aforementioned draft is cited in the applicable I-D's for these key 
>management protocols.
>
>I have a number of choices:
>
>a) Do nothing and let the draft gracefully expire.
>b) Update and submit a revised draft of draft-ietf-ipsec-dss-cert-00.txt.
>c) Pester the PKIX editors to make sure this material gets absorbed into their 
>next draft if it is not already there. (hint, hint...:) )
>
>My preference and intention is to do (a) and (c) and at most submit a revised 
>draft that simply points to PKIX.  It is not clear that a revised draft is 
>even necessary if current IPSEC and other working group drafts which point to 
>draft-ietf-ipsec-dss-cert-00.txt are revised to now point to pkix-3.

Do you really mean "pkix-3" here, or do you mean "pkix-1".  Part three is
the certificate management protocols -- it's not clear to me that a DSS profile
for X.509 certificates belongs there.  Or am I missing something?

Carlisle.

Date: Fri, 20 Sep 1996 17:33:32 -0500 (CDT)
From: "Brian M. Thomas" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: java & CryptoAPI 2

> From: Tom Johnston <[email-masked]>
> Brian -- what we've done is provided COM (OLE Automation) objects which
> can be called from Java.  (For more information, check out Visual J++ at
> http://www.microsoft.com/visualj/).  Regarding cross-platform, today
> CryptoAPI is available on Win95 (IE 3) and WinNT 4.  We've licensed it
> to RSA, they are free to port it to other platforms, and we're looking
> to provide functionality at export strength level on other platforms
> ourselves.
> 

That is a step - a big step, I would say - in the right direction.
Something this basic should, however, be a component of the Java core,
even if implemented in a native-method interface.  On the other hand,
there might be nothing to prohibit a JVM builder from intercepting the
Java core crypto API calls with routines to call your API so that the
functionality is always available in the same way.

As a major builder of enterprise architectures, I will never build a
tool which gives my users no choice of client platform vendor.  Unlike
so many of my fellow architects, I remember what life was like when
there was only one vendor to choose, and I will never go back to that.
If the choice is to do without something Microsoft offers or to shut
out all users who do not use Microsoft products, I will choose the
first, even at considerable cost.  I do not single out Microsoft in
this; the same is true for all other vendors, but none of them has the
market share to make that choice painful for me; consequently I have
made it frequently.

I strongly recommend that, if you wish to be first in this, that you
seek in some fashion to integrate it into the core Java packages and
let the other vendors catch up with you.  If you do it first:  good
for you.  If you do it best:  even better.  If you do it in a way that
makes all web sites that use it effectively put up a sign that says,
"browsers running on non-Microsoft platforms not welcome here", may
you be crisped in your flying toasters; I will not use your product.

brian

Brian Thomas - Distributed Systems Architect  [email-masked]
Southwestern Bell                             [email-masked]
One Bell Center,  Room 23Q1                   Tel: 314 235 3141
St. Louis, MO 63101                           Fax: 314 331 2755

From: Tom Johnston <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: java & CryptoAPI 2
Date: Fri, 20 Sep 1996 15:02:38 -0700
Encoding: 36 TEXT

Brian -- what we've done is provided COM (OLE Automation) objects which
can be called from Java.  (For more information, check out Visual J++ at
http://www.microsoft.com/visualj/).  Regarding cross-platform, today
CryptoAPI is available on Win95 (IE 3) and WinNT 4.  We've licensed it
to RSA, they are free to port it to other platforms, and we're looking
to provide functionality at export strength level on other platforms
ourselves.

	-TJ
>----------
>From: 	Brian M. Thomas[SMTP:[email-masked]]
>Sent: 	Friday, September 20, 1996 7:49 AM
>To: 	Tom Johnston; [email-masked]
>Subject: 	Re: announce:  CryptoAPI 2 developers' release
>
>> >and encoding.  It incorporates all of the cryptography present in
>>CryptoAPI 1
>> >(key generation, key management, key exchange, encryption and decryption,
>> >hashing, signing and signature verification).  CryptoAPI 2 can be called
>>from
>> Java, Visual Basic, VB Script, and C/C++.
>
>Since I have not heard your announcement that you are contributing
>these methods to the Java core, I assume that it is callable from Java
>on a native-method basis only, no?  And of course you are providing
>implementations on other platforms so that the primary goal of Java
>(write once, run anywhere) is met?
>
>
>Brian Thomas - Distributed Systems Architect  [email-masked]
>Southwestern Bell                             [email-masked]
>One Bell Center,  Room 23Q1                   Tel: 314 235 3141
>St. Louis, MO 63101                           Fax: 314 331 2755
>
>
>

Date: Fri, 20 Sep 96 13:19:10 PDT
From: John Kennedy <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: NOTICE: DSS Profile for X.509 Certificates to be deleted.
Cc: [email-masked]

I received the following message from the Internet-Drafts Administrator about 
a month ago regarding the deletion of the I-D John Marchioni and I co-authored 
on a "DSS Profile for X.509 Certificates".  This draft was submitted only as 
an interim solution since the PKIX was just coming up to speed and had not yet 
included this material in the PKIX draft.  I do not know exactly what the 
status of the X.509 DSS profile is in the PKIX document so I am sharing this 
current status information with you now.  As far as I know DSS Certificates 
are being used in both the SKIP and ISAKMP/Oakley reference implementations 
and the aforementioned draft is cited in the applicable I-D's for these key 
management protocols.

I have a number of choices:

a) Do nothing and let the draft gracefully expire.
b) Update and submit a revised draft of draft-ietf-ipsec-dss-cert-00.txt.
c) Pester the PKIX editors to make sure this material gets absorbed into their 
next draft if it is not already there. (hint, hint...:) )

My preference and intention is to do (a) and (c) and at most submit a revised 
draft that simply points to PKIX.  It is not clear that a revised draft is 
even necessary if current IPSEC and other working group drafts which point to 
draft-ietf-ipsec-dss-cert-00.txt are revised to now point to pkix-3.

So, if anybody thinks I need to do (b) let me know.  Otherwise, please reset 
your DSS / X.509 certificate pointers, questions, and comments to their proper 
home in PKIX.

Thanks,

-John Kennedy

----------------BEGIN INCLUDED MESSAGE----------------------------
Date: Fri, 23 Aug 1996 14:35:52 -0400
 From: Internet-Drafts Administrator <[email-masked]>
Subject: <draft-ietf-ipsec-dss-cert-00.txt> to be deleted.
To: John Kennedy <[email-masked]>
Cc: IESG Secretary <[email-masked]>

The Internet-Draft:

       Title       : DSS Profile for X.509 Certificates                    
       Author(s)   : John Kennedy, John Marchioni
       Filename    : <draft-ietf-ipsec-dss-cert-00.txt>
       Last Updated: 02/24/1996
       Pages       : 3
 
 will be deleted from the internet-drafts directories in the next few weeks
 as it has exceeded its maximum time allocated as an Internet-Draft. If a 
 updated version of the draft is available please submit it the next few 
 days.                                     

From: <[email-masked]>
Date: 20 Sep 96 16:38
To: [email-masked]
Subject: unsubscribe
Encoding: 1 TEXT

unsubscribe

Date: Fri, 20 Sep 1996 09:49:01 -0500 (CDT)
From: "Brian M. Thomas" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: announce:  CryptoAPI 2 developers' release

> >and encoding.  It incorporates all of the cryptography present in CryptoAPI 1
> >(key generation, key management, key exchange, encryption and decryption,
> >hashing, signing and signature verification).  CryptoAPI 2 can be called from
> Java, Visual Basic, VB Script, and C/C++.

Since I have not heard your announcement that you are contributing
these methods to the Java core, I assume that it is callable from Java
on a native-method basis only, no?  And of course you are providing
implementations on other platforms so that the primary goal of Java
(write once, run anywhere) is met?

Brian Thomas - Distributed Systems Architect  [email-masked]
Southwestern Bell                             [email-masked]
One Bell Center,  Room 23Q1                   Tel: 314 235 3141
St. Louis, MO 63101                           Fax: 314 331 2755

From: Tom Johnston <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: interchange format for certificates?
Date: Thu, 19 Sep 1996 18:59:26 -0700
Encoding: 48 TEXT

This is exactly one of the problems the PFX (Personal Information
Exchange)  data format and protocol were designed to solve.  PFX is
designed to allow users to move their keys, certificates and other
personal information - securely - from one platform to another.  PFX has
been submitted to the W3C Subgroup on Identity.

documentation is available on
http://www.microsoft.com/intdev/security/misf11_7.htm
a presentation is available on
http://www.microsoft.com/intdev/security/misf11_5.htm

	-TJ

>----------
>From: 	anonymous-netscape-user[SMTP:[email-masked]]
>Sent: 	Thursday, September 19, 1996 6:21 PM
>To: 	[email-masked]
>Subject: 	interchange format for certificates?
>
>Hi,
>
>I am not a member of this list so I will not see responses
>that are not directed to me.  I am not sure if the following
>is something your group would be willing to address.  
>
>The use of certificates is becoming more common.  In my view
>there appears to be a problem that has yet to be solved:  
>
>  Each vendor stores the X.509 and other certificates in
>  a proprietary file format that cannot be exchanged between
>  computer systems.  For example:  I have a Macintosh at 
>  home and a Windows machine at work.  I reciently had to
>  aquire *TWO* certificates from Verisign because they have
>  defined no interchange format allowing me to convert my
>  private keys to an interchange form, copy them to the 
>  other system, and reimport them for use in that system.
>
>It seems to me that a simple interchange format, possibly
>patterned after the way the PGP people ASCIIify their keys,
>would be useful.  I do not know why Verisign did not do this
>for their certificates, but maybe the IETF can define an
>informational or experimental RFC describing an interchange
>format and encourage Verisign and other entities to adopt
>and implement it.  
>
>What to you all think,
>[email-masked]
>

Date: Thu, 19 Sep 1996 20:21:17 -0500
From: anonymous-netscape-user <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: interchange format for certificates?

Hi,

I am not a member of this list so I will not see responses
that are not directed to me.  I am not sure if the following
is something your group would be willing to address.  

The use of certificates is becoming more common.  In my view
there appears to be a problem that has yet to be solved:  

  Each vendor stores the X.509 and other certificates in
  a proprietary file format that cannot be exchanged between
  computer systems.  For example:  I have a Macintosh at 
  home and a Windows machine at work.  I reciently had to
  aquire *TWO* certificates from Verisign because they have
  defined no interchange format allowing me to convert my
  private keys to an interchange form, copy them to the 
  other system, and reimport them for use in that system.

It seems to me that a simple interchange format, possibly
patterned after the way the PGP people ASCIIify their keys,
would be useful.  I do not know why Verisign did not do this
for their certificates, but maybe the IETF can define an
informational or experimental RFC describing an interchange
format and encourage Verisign and other entities to adopt
and implement it.  

What to you all think,
[email-masked]

From: Peter Williams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Tom Johnston'" <[email-masked]>
Subject: RE: announce:  CryptoAPI 2 developers' release
Date: Thu, 19 Sep 1996 14:22:20 -0700

Tom, 

If I undersatnd the reviewed material correctly:

as much of the high-level functionality for certs (and PKCS#10-based cert mgt) is available
via a COM interface, does this mean that, with time, the same
methods will be also available via Distributed COM?

Whilst the MS announcement is (of course) very significant,
both generally, and for windows platforms, for consumers of PKIX cert management services,
its surely even more important if there is cross-platform and networked
access and support built into the mgt architecture via supprot for RPC/[D]COM, which
now seem to come via MS strategic support for DCOM object brokering (via CORBA) with
non-Windows server platforms.

It seems that MS has not only hidden the nasties of ASN.1, and cert/PKCS formats
behind a nice high-level programming interface, but, with the supprot for
a COM/DCOM interface negotiation, the very location of the various cert mgt services is
also distributable (and being based on an object architecture) subclassable and
extensible ad infinitum for each communities policy-based key distribution
needs.

Am I way off in my understanding of the implications of the COM interface to
the cert mgt announcement?

Peter.

----------
From: 	Tom Johnston
Sent: 	Thursday, September 19, 1996 9:46 AM
To: 	[email-masked]'
Subject: 	announce:  CryptoAPI 2 developers' release

CryptoAPI 2 gives developers the ability to incorporate certificates in
applications, and removes much of the work of dealing with encapsulation
>and encoding.  It incorporates all of the cryptography present in CryptoAPI 1
>(key generation, key management, key exchange, encryption and decryption,
>hashing, signing and signature verification).  CryptoAPI 2 can be called from
Java, Visual Basic, VB Script, and C/C++.  It supports X.509, ASN.1, and
PKCS 7.
>
>For more information, check out http://www.microsoft.com/intdev/security.  It
includes presentations on topics such as CryptoAPI 2, Secure Channel
Services (SSL, etc), the Microsoft Certificate Server, Personal
>Information Exchange, Smart Cards and more.  It also includes the CryptoAPI 2
>developers' release (.dll's, documentation, sample applications and source
>code), WinInet and WinSock 2 interfaces allowing developers to use
>Microsoft's implementation of SSL rather than rolling your own.
>
>To give us feedback, or to participate in discussions about CryptoAPI 2,
>please subscribe to the CryptoAPI mailing list:
>
>write to [email-masked]
>and, in the text of your message (not the subject line), write:
>
>SUBSCRIBE CryptoAPI John Doe
>
>substituting your own name of course.
>
>-TJ

From: Tom Johnston <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: announce:  CryptoAPI 2 developers' release
Date: Thu, 19 Sep 1996 09:46:51 -0700
Encoding: 28 TEXT

CryptoAPI 2 gives developers the ability to incorporate certificates in
applications, and removes much of the work of dealing with encapsulation
>and encoding.  It incorporates all of the cryptography present in CryptoAPI 1
>(key generation, key management, key exchange, encryption and decryption,
>hashing, signing and signature verification).  CryptoAPI 2 can be called from
Java, Visual Basic, VB Script, and C/C++.  It supports X.509, ASN.1, and
PKCS 7.
>
>For more information, check out http://www.microsoft.com/intdev/security.  It
includes presentations on topics such as CryptoAPI 2, Secure Channel
Services (SSL, etc), the Microsoft Certificate Server, Personal
>Information Exchange, Smart Cards and more.  It also includes the CryptoAPI 2
>developers' release (.dll's, documentation, sample applications and source
>code), WinInet and WinSock 2 interfaces allowing developers to use
>Microsoft's implementation of SSL rather than rolling your own.
>
>To give us feedback, or to participate in discussions about CryptoAPI 2,
>please subscribe to the CryptoAPI mailing list:
>
>write to [email-masked]
>and, in the text of your message (not the subject line), write:
>
>SUBSCRIBE CryptoAPI John Doe
>
>substituting your own name of course.
>
>-TJ

Date: Thu, 19 Sep 1996 09:10:48 -0700
To: [email-masked]
From: Kaye Caldwell <[email-masked]>
Subject: ** 9/24 Ca. Dig. Sig. Working Group Meeting **

Apologies for duplicates - some of you I'm sure are on multiple notice lists
for this.

California Digital Signature Regulations Working Group
sponsored by the Software Industry Coalition and CommerceNet

THIS MEETING IS OPEN TO ANYONE WHO WISHES TO ATTEND
However, please let me know if you will be attending via e-mail to:
[email-masked]

WHEN: Tuesday September 24, 1-4 PM
WHERE: Sun Microsystems, 901 San Antonio Rd, (Building PAL-1)
              (corner of  S. A. & Charleston, just off 101), Palo Alto
              Cancun Conference Room, 2nd Floor 

AGENDA 

I. Report on status of Secretary of State's Task Force 
     - request for demos of technology in Sacramento
II. Review of draft of our principle 1, suggestions for additional principles
III. Review of current draft of outline of regulations
IV. Review of draft Digital Signature Acceptance Procedures background paper
V. Draft language for additional technologies

For more information, e-mail Kaye Caldwell at [email-masked] or call
408-479-8743.

Kaye Caldwell
Software Industry Coalition Policy Director
CommerceNet Adovocacy and Public Policy Committee Chair
-------------------------------

Date: Mon, 16 Sep 1996 11:59:11 -0700
From: Branislav Meandzija <[email-masked]>
Reply-To: [email-masked]
Organization: Meta Communications, Inc.
To: [email-masked]
Subject: Call for Papers - Global Internet - IEEE Communications Magazine

CALL FOR PAPERS
                IEEE COMMUNICATIONS MAGAZINE
           SPECIAL ISSUE ON THE GLOBAL INTERNET

The IEEE Communications Magazine is soliciting original
tutorial-style manuscripts for a planned Special Issue on
the Global Internet. From its origins as a US government
research project, the Internet has grown to become a major
component of the global world-wide network infrastructure,
linking millions of machines and tens of millions of users
around the world. If the Internet were a stock it would be
considered a market phenomenon, with sustained double-digit
growth and no apparent end in sight to its upward spiral. 

Over 70 countries have full TCP/IP Internet connectivity, 
and about 150 have at least e-mail services through IP or
via more limited means of connectivity (e.g., UUCP or Fidonet).

Given such phenomenal growth, the Global Internet is increasingly
viewed as the catalyst for a communications revolution resulting
in a plethora of new technological, economic, and social changes.
The focus of the special issue is on the technologies of the 
Internet, the technological changes driven by the emergence of
a truly Global Internet, and collateral economic and social 
issues. Papers are solicited on the following specific subjects:

        * Internet Applications - information retrieval,
         directory services, catalogs, search tools and
         user agents; electronic publishing; education;
         www; languages; collaborative work environments.
 
        * Internet Connectivity Infrastructure - service
         characteristics ("best effort" vs. guaranteed); 
         reliability (utility); addressing; multicasting;
         routing; protocols.
 
        * Internet Administrative Infrastructure - regulation;
         public policy; economics; standards.
 
        * Internet Security - security technology; export 
         controls; privacy.
 
        * Internet Management - protocols; agent technology;
         standards; platforms.
 
        * Internet Commerce - electronic banking; virtual 
         retailing; payment systems.

Submitted manuscripts must be no longer than 12 single-spaced 
pages. The cover page should include the title of the paper, 
a brief abstract, a list of keywords, and the full name, 
affiliation, postal address, telephone number, and electronic 
mail address of each author. Papers may be submitted in 
postscript format via e-mail or as hardcopy (six copies).  
Authors should obtain company and government clearances prior
to submission of papers. Papers should be submitted by 
October 31, 1996 to either of the guest co-editors. 

All papers will go through a peer-review process. They will be
judged with respect to their quality and relevance to the 
Special Issue and the IEEE Communications Magazine. 
Authors will be notified of acceptance or rejection by 
December 15, 1996. Final copies of accepted papers will 
be due by January 31, 1997. Publication is scheduled 
for May 1997.

Please submit manuscripts by October 31 to either:

Branislav Meandzija     - OR-           Lyman Chapin
Meta Communications, Inc.               BBN CORPORATION
322 North Cleveland Ave., Suite 100     10 Moulton Street
Oceanside, CA 92054 USA                 Cambridge, MA 02138 USA
Phone:  +1 619 721 6033                 Phone:  +1 617 873 3133
Fax:    +1 619 456 7472                 Fax:    +1 617 873 3243
e-mail: [email-masked]               e-mail: [email-masked]

Date: Mon, 16 Sep 1996 09:18:50 -0400
From: Bill Buffam <[email-masked]>
Reply-To: [email-masked]
Organization: Unisys
To: Peter Williams <[email-masked]>
CC: [email-masked]
Subject: Re: FW: Off topic - DLL security

>As the S/MIMEcommunity is discovering, one can take
>the MS security mechanism, and bundle them
>together in such a manner as to enhance the
>opportunities of fraud!

Really? I must have missed something. Can you expand on this?

-- 

Bill Buffam
Unisys, Malvern PA
[email-masked]

Date: Sun, 15 Sep 1996 16:28:09 -0500
To: "Hamilton, Ed @ OTT" <[email-masked]>
From: [email-masked] (Stephen Kent)
Subject: Re: FW: Off topic - DLL security
Cc: dave horvath <[email-masked]>, chandras <[email-masked]>, ietf-pkix <[email-masked]>

Ed,

        I doubt that PKIX will address any of the details of the topics you
raised.  We are working on certification infrastructure standards issues.
The security of the interface between application software and a crypto
token is a local issue, that depends on the OS, the token, etc.  Digitally
signing software may be of some use in this context, but it probably is not
a panacea and it also is not within the scope of the WG.

Steve

Date: Sun, 15 Sep 1996 14:02:20 -0400
To: [email-masked]
From: Michael S Baum <[email-masked]> (by way of Warwick Ford <[email-masked]>)
Subject: meeting notice

FYI...

==========================================================
                       MEETING NOTICE
==========================================================

                       Please correspond with:
                                Michael S. Baum, Esq.
                                33 Tremont Street
                                Cambridge, MA  02139-1227  USA
                                V: +1 617.661.1234
                                F: +1 617.661.0716
                                E: [email-masked]

Subject:     INFORMATION SECURITY COMMITTEE MEETING NOTICE

Dear Committee Member:

You are cordially invited to participate in a meeting of the Information
Security Committee, Section of Science & Technology, American Bar
Association, on Friday/Saturday, October 18-19, 1996, in Boston.  The
Committee will advance its development of commercial key escrow guidelines
as well as consider digital signature legislative initiatives in the
several States and other jurisdictions, and continue its consideration of
digital signature evidence and liability. 

Consistent with Section policy, ISC meeting participants MUST be members
of both the ABA and the ABA Section of Science and Technology.  Please
contact Ann Kowalsky, Manager Section of Science & Technology, at ABA
offices in Chicago by phone: +1 312.988.5599, fax: +1 312.988.5628, or
email: [email-masked] for membership information. It is possible
to become a paid member of the ABA and the ISC at the meeting.

Dan Greenwood, ISC member, has kindly agreed to host the meeting at the
Information Technology Division of the Commonwealth of Massachusetts.  Dan
can be reached at 617.973.0071 or [email-masked] for directions &
logistical information. 

Meeting details appear below. I look forward to seeing you in Boston. 

Sincerely,

Michael S. Baum
Chair, Information Security Committee
Section of Science & Technology, ABA

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

                  INFORMATION SECURITY COMMITTEE
                         October 18-19, 1996

                          Tentative Agenda
                 (see "Meeting Details," next page)
        (In extended sessions, breaks will be taken as needed.)

October 18, 1996  Friday

 8:30-9:00   Greetings, breakfast, administrative matters.
 9:00-9:30   Introductions, meeting logistics, Guidelines update,
              questions; PKI-relevant standards reports.
 9:30-12:00  Legislative/Regulatory Update (including open conference call
              with digital signature leg./reg. drafting committee
              representatives in the US and abroad).
12:00-13:00  Joint lunch with Boston Bar Assn, Computer Law Committee.
13:00-18:00  Continuation of legislative/regulatory update with digital
              signature leg./reg. drafting committee representatives.
18:00-????   Watering hole discussions; possible continuation of work
              group meetings.

October 19, 1996  Saturday

 8:30-9:00   Breakfast, et cetera.
 9:00-10:00  Presentation by Key Escrow work group.
10:00-12:00  Breakout sessions on work groups.
12:00-13:00  Working lunch and guest presentation on "Assuring Quality and 
              the Accreditation of Certification Authorities" by 
              invited representative of the Nat'l Inst. of Standards and Tech.
13:00-15:00  Presentations by Work Groups.
15:00-15:30  Path Forward; wrap-up.

                             ISC MEETING DETAILS
                              October 18-19, 1996

Members are urged to participate in one of the work groups that will be
presenting/meeting during the ISC's meeting.

    "Addendum" Work Group
     Contact: Ruven Schwartz ([email-masked])
              Tom Smedinghoff ([email-masked])
              Joe Wackerman ([email-masked])
       The Addendum Work Group will continue drafting a digital signature
       trading partner agreement -- integrating the principles of the 
       Digital Signature Guidelines, and developing additional practical
       commentary for this model form of electronic commerce agreement.
        
    Evidentiary Work Group
    Contact: Stan Kurzban ([email-masked]) or 
             Serge Parisien ([email-masked])
       The Evidentiary Work Group will complete and present
       a provisional outline for a tutorial on the evidentiary 
       implications of digitally signed information and advance drafting 
       of material for each section of the tutorial.

    Key Escrow Work Group (KEWG)
    Contact: Dwight Olson ([email-masked]) or
             Randy Sabett ([email-masked])
       The KEWG will focus on the legal and technical aspects 
       of commercial key escrow.  The group will seek to accurately 
       explore all major issues surrounding this topic, and produce a set 
       of draft guidelines for comment.  The proposed guidelines are 
       intended to facilitate secure electronic commerce by
       clarifying the rights and obligations of the parties involved 
       in voluntary commercial key escrow. The work product may take 
       one or more forms including:
       (i)   a "restatement" of the relevant law and practice,
       (ii)  a model state or federal law or international convention,
       (iii) a set of principles that can be incorporated by reference 
               into agreements or used for the interpretation of legal 
               aspects of voluntary key escrow, or
       (iv)  a set of "gap filler" provisions.

    Liability Work Group
    Contact: Maureen Adamache ([email-masked])
       The liability work group will meet as necessary to discuss 
       the apportionment of liabilities among PKI providers and users.  
       Previously, this task was considered in the ISC's own work-product,
       the Digital Signature Guidelines.  Future documents that will
       be considered include Certification Practice Statements, and digital 
       signature legislative and regulatory work product.

    State Government Digital Signatures Laws & Regulations
    Contact: Dan Greenwood ([email-masked])
       The digital signature legislative and regulatory working group
       will compile, evaluate and compare the various emerging 
       approaches by states and other jurisdictions. Work product will 
       include a web-based comprehensive "one-stop shop" for 
       jurisdictions wishing to review current approaches.

First-time participants (who plan to attend the October 18-19, 1996
meeting) must request attendance and submit a brief work-product
(typically 3-5 pages) relevant to the subject matter. Please contact Ruven
Schwartz (v: 612.687.8095, f: 612.687.7907, or e:
[email-masked]) for details. 

Meeting Location:
McCormack Building (Across Bowdoin Street from the State House)
1 Ashburton Place
Room 1, 21st Floor
Boston, Massachusetts USA
(Contact: Dan Greenwood +1 617.973.0071)

Meals:  The cafeteria will be available for lunch on Friday for those ISC
Members who choose to work through the joint lunch session.  On Saturday
we will probably order in pizza. 

Lodging: A very nearby hotel is the Holiday Inn, Government Center, 5
Blossom Street, Boston. The regular rate during our meeting dates is
$219.95/night.  However, the Reservation Supervisor (Kim) has offered a
rate of $199.95 to Committee members who request the "Great Rate"  plan. 
Call reservations at +1 617.742.7630.  For a better (but more expensive)
hotel near Government Center, try the Parker House at +1 617.227.8600. 
The Omni Parker House (nicer than Holiday Inn) quoted a rate of $169/night
for a single with a king or queen bed and $119/night for a single with a
double bed.  The rooms are very small - but the hotel is nice.  See also a
Greater Boston Bed & Breakfast directory:
http://www.inovatec.com/bb/resservc/GREATER/GREATER.htm. 

RSVP:  Please confirm your intention to participate to Ann Kowalsky,
Section Manager, Section of Science and Technology
([email-masked]) as soon as possible.

See you in Boston!

===========================================================================

From: Peter Williams <[email-masked]>
To: "'dave horvath'" <[email-masked]>, "'Hamilton, Ed @ OTT'" <[email-masked]>, "'Peter Williams'" <[email-masked]>, "'Tom Johnston'" <[email-masked]>
Cc: "'chandras'" <[email-masked]>, "'ietf-pkix'" <[email-masked]>
Subject: RE: FW: Off topic - DLL security
Date: Fri, 13 Sep 1996 13:17:24 -0700

Tom,

Thanks for the clarification - that the various Windows 
system  security services are themselves usable by third parties IN ANY manner
designers/developers may wish - to provide whatever controls are desired.

I have personally only the highest respect for Microsoft's
development and mass deployment of the missing
security infrastructure pieces, and (FURTHEREMORE) the
architecting of their components such that they can
be used in many different ways. We have waited for
so long!

To agree with something MS said recently, MS has
now done the grunt work of signatures and certs programming, ASN.1
fiddling (now, fortunately, all hidden!), and provided high-level language
programming of these constructs enabling access by anyone capable of
programming Basic and using the web. Now the community at large
can go build security conrtols of whatever nature it wishes -
upon the cross-vendor/cross-O/S platform.

Whilst we as a community (which clearly now
integrates Microsoft's contribution) have now solved a big
piece of the infrastructure bootstrap problem by
agreeing the standards, and having a major vendor  like
MS deploy a conforming implementation widely and freely
in a developers framework, we perhaps now need to
concentrate on the promotion of "good ways" to
use the various mechanisms. Goodness, of
course, is rather subjective.

"A gun is a powerful defense tool; but it often shoots the
firer in the foot when used by untrained people!" Whislt
MS has given the public security facilites (withCryptoAPI 1)
and now (with CryptoAPI 2) solid security mechanisms, we need
to give them also guidance on how to use them
properly to construct valid security services, so as not to lead to many
a crypto accident or false sense of security.

As the S/MIMEcommunity is discovering, one can take
the MS security mechanism, and bundle them
together in such a manner as to enhance the
opportunities of fraud!

Now that we have free and open technology, the vendors who know
how to design secure protocols and applications really need to take
a strong leadership role in promoting assured
security designs.

Peter

----------
From: 	Tom Johnston
Sent: 	Friday, September 13, 1996 11:30 AM
To: 	'dave horvath'; 'Hamilton, Ed @ OTT'; 'Peter Williams'
Cc: 	'chandras'; 'ietf-pkix'
Subject: 	RE: FW: Off topic - DLL security

>Microsoft's winverifytrust() api is directly to the purpose of providing .dll
>security.  You can find information on it at
>http://www.microsoft.com/intdev/security/misf8_2.htm.  We provide both a
>signing format and a model for writing your own code verification policies.
>
>The signature format is the standard PKCS#7 SignedData structure with some
additional published attributes. There's a a set of libraries and tools
>for signing a DLL with your own key, inserting the signature directly into
>the DLL along with any relevant certificates, and parsing and verifing the
>signature.

>The thorny problem is who calls the API.  Authenticode calls it at
>installation; you could certainly write an agent that would call the API at
>other times, though this might require hooking system services.

	-TJ

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Friday, September 13, 1996 10:08 AM
>To: 	dave horvath; 'Hamilton, Ed @ OTT'
>Cc: 	chandras; ietf-pkix
>Subject: 	RE: FW: Off topic - DLL security
>
>Microsoft does indeed claim to use signatures and tamperproof
>loading implementation technology to control loading of a crypto DLL.
>However,
>this seems to be an exception to the design being advanced
>for the commercial market:
>
>The general tendency seems to be that DLL (or any other content type)
>is evaluated at *introduce/install* time as to whether its behaviour (upon
>loading) or
>mere existance (in the system) would negatively impact the continuing
>accreditation
>of a host system to be operating at level C2 (or other level).
>
>
>----------
>From: 	Hamilton, Ed @ OTT
>Sent: 	Thursday, September 12, 1996 8:13 AM
>To: 	dave horvath
>Cc: 	chandras; ietf-pkix
>Subject: 	Re: FW: Off topic - DLL security
>
>
>Hi Dave,
>
>     I would love to use a trusted operating system, however, it would 
>basically be a waste of money, in the sense that the software that I need to 
>run on it is Commercial and not certifiable on a B2 system.
>     For the end-user platforms, we have been mandated to find a way to 
>implement the required security on a C2 platform (namingly Windows NT). 
> However, at the same time we must address the issues of I&A from our 
>applications to the user and to a PCMCIA card.  We must also ensure the 
>integrity of the label generated by our software to ensure that it gets to 
>the PCMCIA card without modification.
>     So, we need partially C2 certified application software.  One way for 
>us to get there is to utilize static linked libraries, but commercial 
>vendors do not want to give these types of things away, plus it makes 
>maintenance a real pain.
>     I was lead to believe that the ietf (specifically the pkix) was looking 
>at this issue and would be proposing something in the near future.  I have 
>not heard a response to this fact.  I believe that they were looking at 
>digitally signing a DLL to ensure that the DLL in use is valid.  I believe 
>that Microsoft is also implementing something like this for use with their 
>capi DLLs.
>     Can anyone tell me what is going on?
>
> --- [email-masked]
> ----------
>From: dave horvath
>To: chandras; ietf-pkix; ehamilt
>Subject: Re: FW: Off topic - DLL security
>Date: Thursday, September 12, 1996 10:19AM
>
>> From [email-masked] Thu Sep 12 09:04:52 1996
>> From: "Hamilton, Ed @ OTT" <[email-masked]>
>> To: chandras <[email-masked]>, ietf-pkix 
><[email-masked]>
>> Subject: FW: Off topic - DLL security
>> Date: Thu, 12 Sep 96 08:41:00 EDT
>> Encoding: 24 TEXT
>> X-Mailer: Microsoft Mail V3.0
>> Content-Length: 993
>>
>>
>>
>>  ----------
>> From: Hamilton, Ed @ OTT
>> To: 'Security Mail
>> Subject: Off topic - DLL security
>> Date: Wednesday, September 11, 1996 10:42AM
>>
>> Hi,
>>
>>      I believe this is a little off topic, but it really should be
>> considered here as well.  I am looking at implementing a secure product
>that
>> uses a DLL for various means including accessing a PCMCIA Card.  My 
>concern
>> is that someone can spoof this DLL and gain access to my password.
>>      The relevance to www-security is the use of PC Cards or Smart Cards 
>to
>> authenticate individuals to a web application which in turn uses secure
>http
>> or whatever to communicate to a location such as a bank.
>>      Does anyone have any suggestions. implementation, ideas on how
>> authentication can be securely performed to PC Card via a DLL?  Are there
>> any standards in the works?  I really want to start a *BIG* discussion on
>> this.  Does anyone know of other lists that I can send this to that will 
>be
>> interested in this topic?
>
>        It is true that the use of DLLs may exagerate the security risks
>        associated with solicitation of passwords and pins, however the
>        risk will always be there if you don't use a trusted system.
>
>        There are various levels of security that are available in
>        operating system products to help minimize the threat of someone
>        gaining access to your information.  One mechanism is trusted paths
>        wich are implemented in higher level assurance operating systems.
>        Trusted paths provide some level of assurance that you are
>        communicating with a device, process, etc.  They are requirement
>        of B2 and above or CMW systems. (see TCSEC from NCSC , i think )
>
>        The trusted path is a direct and unmistakably distinct communication
>        mechanism between the Trusted Computing Base (TCB) and the system
>        users.  The use of a trusted path ensures that a user cannot be
>        tricked into communicating with a process that pretends to be
>        the trusted software.
>
>        It is all based on the level of threat you determine you will
>        encounter, and how much money you want to spend to minimize the
>        risk.
>
>        On a Windows platform you may be able to provide some minimally
>        higher level of assurance by signing the DLL, but the security
>        will still be generally weak due to limations in Windows itself.
>
>
>Dave Horvath
>Chromatix, Inc
>
>
>

From: Tom Johnston <[email-masked]>
To: "'dave horvath'" <[email-masked]>, "'Hamilton, Ed @ OTT'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Cc: "'chandras'" <[email-masked]>, "'ietf-pkix'" <[email-masked]>
Subject: RE: FW: Off topic - DLL security
Date: Fri, 13 Sep 1996 11:30:58 -0700
Encoding: 146 TEXT

>Microsoft's winverifytrust() api is directly to the purpose of providing .dll
>security.  You can find information on it at
>http://www.microsoft.com/intdev/security/misf8_2.htm.  We provide both a
>signing format and a model for writing your own code verification policies.
>
>The signature format is the standard PKCS#7 SignedData structure with some
additional published attributes. There's a a set of libraries and tools
>for signing a DLL with your own key, inserting the signature directly into
>the DLL along with any relevant certificates, and parsing and verifing the
>signature.

>The thorny problem is who calls the API.  Authenticode calls it at
>installation; you could certainly write an agent that would call the API at
>other times, though this might require hooking system services.

	-TJ

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Friday, September 13, 1996 10:08 AM
>To: 	dave horvath; 'Hamilton, Ed @ OTT'
>Cc: 	chandras; ietf-pkix
>Subject: 	RE: FW: Off topic - DLL security
>
>Microsoft does indeed claim to use signatures and tamperproof
>loading implementation technology to control loading of a crypto DLL.
>However,
>this seems to be an exception to the design being advanced
>for the commercial market:
>
>The general tendency seems to be that DLL (or any other content type)
>is evaluated at *introduce/install* time as to whether its behaviour (upon
>loading) or
>mere existance (in the system) would negatively impact the continuing
>accreditation
>of a host system to be operating at level C2 (or other level).
>
>
>----------
>From: 	Hamilton, Ed @ OTT
>Sent: 	Thursday, September 12, 1996 8:13 AM
>To: 	dave horvath
>Cc: 	chandras; ietf-pkix
>Subject: 	Re: FW: Off topic - DLL security
>
>
>Hi Dave,
>
>     I would love to use a trusted operating system, however, it would 
>basically be a waste of money, in the sense that the software that I need to 
>run on it is Commercial and not certifiable on a B2 system.
>     For the end-user platforms, we have been mandated to find a way to 
>implement the required security on a C2 platform (namingly Windows NT). 
> However, at the same time we must address the issues of I&A from our 
>applications to the user and to a PCMCIA card.  We must also ensure the 
>integrity of the label generated by our software to ensure that it gets to 
>the PCMCIA card without modification.
>     So, we need partially C2 certified application software.  One way for 
>us to get there is to utilize static linked libraries, but commercial 
>vendors do not want to give these types of things away, plus it makes 
>maintenance a real pain.
>     I was lead to believe that the ietf (specifically the pkix) was looking 
>at this issue and would be proposing something in the near future.  I have 
>not heard a response to this fact.  I believe that they were looking at 
>digitally signing a DLL to ensure that the DLL in use is valid.  I believe 
>that Microsoft is also implementing something like this for use with their 
>capi DLLs.
>     Can anyone tell me what is going on?
>
> --- [email-masked]
> ----------
>From: dave horvath
>To: chandras; ietf-pkix; ehamilt
>Subject: Re: FW: Off topic - DLL security
>Date: Thursday, September 12, 1996 10:19AM
>
>> From [email-masked] Thu Sep 12 09:04:52 1996
>> From: "Hamilton, Ed @ OTT" <[email-masked]>
>> To: chandras <[email-masked]>, ietf-pkix 
><[email-masked]>
>> Subject: FW: Off topic - DLL security
>> Date: Thu, 12 Sep 96 08:41:00 EDT
>> Encoding: 24 TEXT
>> X-Mailer: Microsoft Mail V3.0
>> Content-Length: 993
>>
>>
>>
>>  ----------
>> From: Hamilton, Ed @ OTT
>> To: 'Security Mail
>> Subject: Off topic - DLL security
>> Date: Wednesday, September 11, 1996 10:42AM
>>
>> Hi,
>>
>>      I believe this is a little off topic, but it really should be
>> considered here as well.  I am looking at implementing a secure product
>that
>> uses a DLL for various means including accessing a PCMCIA Card.  My 
>concern
>> is that someone can spoof this DLL and gain access to my password.
>>      The relevance to www-security is the use of PC Cards or Smart Cards 
>to
>> authenticate individuals to a web application which in turn uses secure
>http
>> or whatever to communicate to a location such as a bank.
>>      Does anyone have any suggestions. implementation, ideas on how
>> authentication can be securely performed to PC Card via a DLL?  Are there
>> any standards in the works?  I really want to start a *BIG* discussion on
>> this.  Does anyone know of other lists that I can send this to that will 
>be
>> interested in this topic?
>
>        It is true that the use of DLLs may exagerate the security risks
>        associated with solicitation of passwords and pins, however the
>        risk will always be there if you don't use a trusted system.
>
>        There are various levels of security that are available in
>        operating system products to help minimize the threat of someone
>        gaining access to your information.  One mechanism is trusted paths
>        wich are implemented in higher level assurance operating systems.
>        Trusted paths provide some level of assurance that you are
>        communicating with a device, process, etc.  They are requirement
>        of B2 and above or CMW systems. (see TCSEC from NCSC , i think )
>
>        The trusted path is a direct and unmistakably distinct communication
>        mechanism between the Trusted Computing Base (TCB) and the system
>        users.  The use of a trusted path ensures that a user cannot be
>        tricked into communicating with a process that pretends to be
>        the trusted software.
>
>        It is all based on the level of threat you determine you will
>        encounter, and how much money you want to spend to minimize the
>        risk.
>
>        On a Windows platform you may be able to provide some minimally
>        higher level of assurance by signing the DLL, but the security
>        will still be generally weak due to limations in Windows itself.
>
>
>Dave Horvath
>Chromatix, Inc
>
>
>

From: Peter Williams <[email-masked]>
To: dave horvath <[email-masked]>, "'Hamilton, Ed @ OTT'" <[email-masked]>
Cc: chandras <[email-masked]>, ietf-pkix <[email-masked]>
Subject: RE: FW: Off topic - DLL security
Date: Fri, 13 Sep 1996 10:08:33 -0700

Microsoft does indeed claim to use signatures and tamperproof
loading implementation technology to control loading of a crypto DLL. However,
this seems to be an exception to the design being advanced
for the commercial market:

The general tendency seems to be that DLL (or any other content type)
is evaluated at *introduce/install* time as to whether its behaviour (upon loading) or
mere existance (in the system) would negatively impact the continuing accreditation
of a host system to be operating at level C2 (or other level).

----------
From: 	Hamilton, Ed @ OTT
Sent: 	Thursday, September 12, 1996 8:13 AM
To: 	dave horvath
Cc: 	chandras; ietf-pkix
Subject: 	Re: FW: Off topic - DLL security

Hi Dave,

     I would love to use a trusted operating system, however, it would 
basically be a waste of money, in the sense that the software that I need to 
run on it is Commercial and not certifiable on a B2 system.
     For the end-user platforms, we have been mandated to find a way to 
implement the required security on a C2 platform (namingly Windows NT). 
 However, at the same time we must address the issues of I&A from our 
applications to the user and to a PCMCIA card.  We must also ensure the 
integrity of the label generated by our software to ensure that it gets to 
the PCMCIA card without modification.
     So, we need partially C2 certified application software.  One way for 
us to get there is to utilize static linked libraries, but commercial 
vendors do not want to give these types of things away, plus it makes 
maintenance a real pain.
     I was lead to believe that the ietf (specifically the pkix) was looking 
at this issue and would be proposing something in the near future.  I have 
not heard a response to this fact.  I believe that they were looking at 
digitally signing a DLL to ensure that the DLL in use is valid.  I believe 
that Microsoft is also implementing something like this for use with their 
capi DLLs.
     Can anyone tell me what is going on?

 --- [email-masked]
 ----------
From: dave horvath
To: chandras; ietf-pkix; ehamilt
Subject: Re: FW: Off topic - DLL security
Date: Thursday, September 12, 1996 10:19AM

> From [email-masked] Thu Sep 12 09:04:52 1996
> From: "Hamilton, Ed @ OTT" <[email-masked]>
> To: chandras <[email-masked]>, ietf-pkix 
<[email-masked]>
> Subject: FW: Off topic - DLL security
> Date: Thu, 12 Sep 96 08:41:00 EDT
> Encoding: 24 TEXT
> X-Mailer: Microsoft Mail V3.0
> Content-Length: 993
>
>
>
>  ----------
> From: Hamilton, Ed @ OTT
> To: 'Security Mail
> Subject: Off topic - DLL security
> Date: Wednesday, September 11, 1996 10:42AM
>
> Hi,
>
>      I believe this is a little off topic, but it really should be
> considered here as well.  I am looking at implementing a secure product
that
> uses a DLL for various means including accessing a PCMCIA Card.  My 
concern
> is that someone can spoof this DLL and gain access to my password.
>      The relevance to www-security is the use of PC Cards or Smart Cards 
to
> authenticate individuals to a web application which in turn uses secure
http
> or whatever to communicate to a location such as a bank.
>      Does anyone have any suggestions. implementation, ideas on how
> authentication can be securely performed to PC Card via a DLL?  Are there
> any standards in the works?  I really want to start a *BIG* discussion on
> this.  Does anyone know of other lists that I can send this to that will 
be
> interested in this topic?

        It is true that the use of DLLs may exagerate the security risks
        associated with solicitation of passwords and pins, however the
        risk will always be there if you don't use a trusted system.

        There are various levels of security that are available in
        operating system products to help minimize the threat of someone
        gaining access to your information.  One mechanism is trusted paths
        wich are implemented in higher level assurance operating systems.
        Trusted paths provide some level of assurance that you are
        communicating with a device, process, etc.  They are requirement
        of B2 and above or CMW systems. (see TCSEC from NCSC , i think )

        The trusted path is a direct and unmistakably distinct communication
        mechanism between the Trusted Computing Base (TCB) and the system
        users.  The use of a trusted path ensures that a user cannot be
        tricked into communicating with a process that pretends to be
        the trusted software.

        It is all based on the level of threat you determine you will
        encounter, and how much money you want to spend to minimize the
        risk.

        On a Windows platform you may be able to provide some minimally
        higher level of assurance by signing the DLL, but the security
        will still be generally weak due to limations in Windows itself.

Dave Horvath
Chromatix, Inc

Date: Thu, 12 Sep 1996 19:11:58 -0700 (PDT)
From: "David W. Morris" <[email-masked]>
To: "Hamilton, Ed @ OTT" <[email-masked]>
cc: chandras <[email-masked]>, ietf-pkix <[email-masked]>
Subject: Re: Off topic - DLL security

On Thu, 12 Sep 1996, Hamilton, Ed @ OTT wrote:

> 
> Hi Dave,
> 
>      The fact that you have a product in existence is a good thing.  It 
> indicates a need for this technology and it indicates a need for 
> standardization of this technology.  The next step is to get a standard in 
> place so that this technology can be used in each and every circumstance 
> that may be applicable.

Well standards are useful when interoperability is needed. In this case,
what might be needed is a new API from the platform vendor. In my case, 
what I described is my application of an approach recommended by our
secure payment technology/service vendor. My adaptation was simply to
force a correlation between the DLL actually loaded by win/95 and the
dll I validate using their MD5 library and verification routine.

So I think this could be added to a security issues chapter of someone's
book but it doesn't deserve collective effort.