Subject: Re: Displaying an X.509 certificate
From: <[email-masked]>
To: [email-masked]
Date: Sat, 30 Nov 1996 13:37:35 (NZDT)

>Does anyone know where I can find a program that, given an X.509 certificate,
>will display its fields and their values in some human-readable form?
 
I've written a simple program to do this (it's pretty minimal, it only knows
about the OID's I was interested in, only does DER, and has a few other
limitations - I wasn't trying to create a general-purpose browser, just a quick
debugging tool), you can get it as
http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c.
 
Peter.

To: [email-masked]
Cc: [email-masked]
From: Yoshito <[email-masked]>
Date: Fri, 29 Nov 1996 17:58:05 +0900

subscribe

Date: Wed, 27 Nov 1996 16:16:18 -0500
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Internet Draft on Certificate Policy and CPS Framework
Status:   

A new Internet Draft, for discussion at the San Jose PKIX meeting, has been
prepared.  Unfortunately, it just missed the I-D publication deadline so
will likely not make it to the I-D directories before the meeting.  You may
obtain a copy from: http://www.cygnacom.com/docfiles/CPS.txt.

-------------------------------------
Certificate Policy and Certification Practice Statement Framework
(Chokhani/Ford)

<draft-ietf-pkix-polfmwk-00.txt>

ABSTRACT

This document presents an initial draft of a framework to assist  the
writers  of  X.509  certificate  policies  or  certification practice
statements for  public  key  infrastructures  with  their  task.   In
particular,  the  framework identifies a comprehensive list of topics
that potentially (at the writer's discretion) need to be  covered  in
an X.509 certificate policy or a certification practice statement.

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

Date: Wed, 27 Nov 1996 12:08:48 +0100
From: Fernando Garcia Exposito <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: subcriber
Info: Signet Systems Pty Ltd
Original-Content-Type: text/plain
Status:   

Please, I need Information about all type of certificates. X,509, PGP, PKCS, etc

Date: Wed, 27 Nov 1996 16:16:18 -0500
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Internet Draft on Certificate Policy and CPS Framework

A new Internet Draft, for discussion at the San Jose PKIX meeting, has been
prepared.  Unfortunately, it just missed the I-D publication deadline so
will likely not make it to the I-D directories before the meeting.  You may
obtain a copy from: http://www.cygnacom.com/docfiles/CPS.txt.

-------------------------------------
Certificate Policy and Certification Practice Statement Framework
(Chokhani/Ford)

<draft-ietf-pkix-polfmwk-00.txt>

ABSTRACT

This document presents an initial draft of a framework to assist  the
writers  of  X.509  certificate  policies  or  certification practice
statements for  public  key  infrastructures  with  their  task.   In
particular,  the  framework identifies a comprehensive list of topics
that potentially (at the writer's discretion) need to be  covered  in
an X.509 certificate policy or a certification practice statement.

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

To: IETF-Announce:;@tandem.com
cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki3cmp-01.txt
Date: Wed, 27 Nov 1996 11:33:17 -0500
Sender: [email-masked]

--NextPart

 A Revised Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the Public-Key Infrastructure 
 (X.509) Working Group of the IETF.                                        

       Title     : Internet Public Key Infrastructure  Part III: 
                   Certificate Management Protocols                        
       Author(s) : S. Farrell, C. Adams
       Filename  : draft-ietf-pkix-ipki3cmp-01.txt
       Pages     : 45
       Date      : 11/27/1996

This is the fourth draft of the Internet Public Key Infrastructure X.509 
Certificate Management Protocols. This version builds on 
draft-ietf-pkix-ipki3cmp-00.txt and discussions on the PKIX mailing list 
([email-masked]) and at the Montreal IETF meeting (June 1996).       

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-pkix-ipki3cmp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki3cmp-01.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-ietf-pkix-ipki3cmp-01.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki3cmp-01.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-pkix-ipki3cmp-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 27 Nov 1996 12:08:48 +0100
From: Fernando Garcia Exposito <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: subcriber
Status:   

Please, I need Information about all type of certificates. X,509, PGP, PKCS, etc

Date: Wed, 27 Nov 1996 12:08:48 +0100
From: Fernando Garcia Exposito <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: subcriber

Please, I need Information about all type of certificates. X,509, PGP, PKCS, etc

To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: ANNOUNCEMENT: ISOC 1997 SYMPOSIUM NETWORK & DISTRIBUTED SYSTEM SECURITY
Date: Tue, 26 Nov 1996 21:35:11 -0500
From: "David M. Balenson" <[email-masked]>

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

                 THE INTERNET SOCIETY 1997 SYMPOSIUM ON
                 NETWORK AND DISTRIBUTED SYSTEM SECURITY
                              (NDSS '97)

                          10-11 FEBRUARY 1997

            SAN DIEGO PRINCESS RESORT, SAN DIEGO, CALIFORNIA

  This fourth annual symposium will bring together researchers,
  implementors, and users of network and distributed system security
  technologies to discuss today's important security issues and
  challenges.  It will provide a mix of technical papers and panel
  presentations that describe promising new approaches to security
  problems that are practical, and to the extent possible, have
  been implemented.  We hope to foster the exchange of technical
  information and encourage the Internet community to deploy
  available security technologies and develop new solutions to
  unsolved problems.

WHY YOU SHOULD ATTEND

  The use of the Internet is rapidly growing and expanding into
  all aspects of our society.  Commercial organizations are coming
  under increasing pressure to make their services available on-line.
  This in turn is increasing the need for rapid and widespread
  deployment of usable and effective network and distributed system
  security technologies.  High visibility attacks on the Internet
  underscore the vulnerabilities of the Internet and the need to
  solve its security problems.  There is growing concern for securing
  the network infrastructure itself.  Recent trends in software
  distribution (such as Java and ActiveX technologies) have made
  certain attacks easier to carry out.  Privacy has become an
  important issue for the Internet.

  NDSS '97 will bring together researchers, implementors, and users
  of network and distributed system technologies to discuss today's
  important security issues and challenges.  We have selected the
  technical papers and panel presentations that describe promising
  new approaches to security problems that are practical, and to
  the extent possible, have been implemented.  Topics to be addressed
  include Internet infrastructure and routing security, security
  for the World Wide Web, Java and ActiveX security, cryptographic
  protocols, public key management, and protection of privacy.

  The symposium will have a positive impact on the state of Internet
  security.  You will have the opportunity to actively participate
  in the dialog.  Ask questions of the speakers, raise your important
  issues during the panel sessions, and let other participants know
  of your requirements, observations, and experience in this
  important area.  We hope to encourage the wide-scale deployment
  of security technologies and to promote new research that can
  address the currently unmet security needs of the Internet
  community.

CONTENTS

  Preliminary Program
  Organizing Committee
  San Diego Princess Resort
  Registration Information
  Registration Form

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

                 P R E L I M I N A R Y   P R O G R A M

SUNDAY, FEBRUARY 9

6:00 P.M. - 8:00 P.M.
RECEPTION

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

MONDAY, FEBRUARY 10

7:30 A.M.
CONTINENTAL BREAKFAST

8:30 A.M.
OPENING REMARKS

9:00 A.M.
SESSION 1: THINGS THAT GO BUMP IN THE NET
Chair: Stephen T. Kent (BBN Corporation, USA)

  Experimental Results of Covert Channel Elimination in One-Way
  Communication Systems, Nick Ogurtsov, Hilarie Orman, Richard
  Schroeppel, Sean O'Malley, and Oliver Spatscheck (University
  of Arizona, USA)

  Blocking Java Applets at the Firewall, David M. Martin Jr.,
  Sivaramakrishnan Rajagopalan and Aviel D. Rubin (Bellcore, USA)

  Continuous Assessment of a Unix Configuration: Integrating
  Intrusion Detection & Configuration Analysis, Abdelaziz Mounji
  and Baudouin Le Charlier (Institut D'Informatique, Namur,
  BELGIUM)

10:30 A.M.
BREAK

11:00 A.M.
SESSION 2: PANEL: SECURITY OF DOWNLOADABLE EXECUTABLE CONTENT
Chair: Aviel Rubin (Bellcore, USA)

12:30 NOON
LUNCH

2:00 P.M.
SESSION 3: PROTOCOL IMPLEMENTATION AND ANALYSIS
Chair: Christoph Schuba (Purdue University, USA)

  An Interface Specification Language for Automatically Analyzing
  Cryptographic Protocols, Stephen H. Brackin (Arca Systems, USA)

  Probable Plaintext Cryptanalysis of the IP Security Protocols,
  Steven M. Bellovin (AT&T Research, USA)

  Misplaced Trust: Kerberos Version 4 Session Keys, Bryn Dole (Sun 
  Microsystems), Steve Lodin (Delco Electronics), and Eugene Spafford
  (Purdue University, USA)

3:30 P.M.
BREAK

4:00 P.M.
SESSION 4: PANEL: SECURITY OF THE INTERNET INFRASTRUCTURE
Chair: Russ Mundy (Trusted Information Systems, USA)

7:00 P.M.
DINNER BANQUET

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

TUESDAY, FEBRUARY 11

7:30 A.M.
CONTINENTAL BREAKFAST

8:30 A.M.
SESSION 5: ROUTING SECURITY
Chair: Hilarie Orman (DARPA, USA)

  Securing the Nimrod Routing Architecture, Karen E. Sirois and
  Stephen T. Kent (BBN Corporation, USA)

  Securing Distance-Vector Routing Protocols, Bradley R. Smith,
  Shree Murthy and J.J. Garcia-Luna-Aceves (University of California
  Santa Cruz, USA)

  Reducing the Cost of Security in Link-State Routing, R. Hauser,
  A. Przygienda and G. Tsudik (IBM and USC/ISI, USA)

10:00 A.M.
BREAK

10:30 A.M.
SESSION 6: SECURITY FOR THE WORLD WIDE WEB
Chair: Win Treese (OpenMarket, USA)

  Securing Web Access with DCE, Brian C. Schimpf (Gradient 
  Technologies, USA)

  PANEL: SECURITY FOR THE WORLD WIDE WEB
  Chair: Win Treese (OpenMarket, USA)

12:00 A.M.
LUNCH

1:30 P.M.
SESSION 7: PUBLIC KEY MANAGEMENT
Chair: Jonathan Trostle (CyberSafe, USA)

  Hierarchical Organization of Certification Authorities for
  Secure Environments, Lourdes Lopez (Universidad Politecnica de
  Madrid, SPAIN)

  Trust Models in ICE-TEL, Andrew Young and Nada Kapidzic Cicovic
  (Univeristy of Salford, UNITED KINGDOM)

  Distributed Authentication in Kerberos Using Public Key
  Cryptography, Marvin Sirbu and John Chung-I Chuang (Carnegie 
  Mellon University, USA)

3:00 P.M.
BREAK

3:30 P.M.
SESSION 8: PANEL: WEB PRIVACY AND ANONYMITY
Chair: (To Be Determined)

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

                O R G A N I Z I N G   C O M M I T T E E

GENERAL CHAIR
  David Balenson, Trusted Information Systems

PROGRAM CHAIRS
  Clifford Neuman, USC Information Sciences Institute
  Matt Bishop, University of California at Davis

PROGRAM COMMITTEE
  Steve Bellovin, AT&T Research
  Tom Berson, Anagram Laboratories
  Doug Engert, Argonne National Laboratory
  Warwick Ford, Verisign
  Richard Graveman, Bellcore
  Li Gong, JavaSoft
  Burt Kaliski, RSA Laboratories
  Steve Kent, BBN Corporation
  Tom Longstaff, CERT
  Doug Maughan, National Security Agency
  Dan Nessett, 3Com Corporation
  Hilarie Orman, DARPA/ITO
  Michael Roe, University of Cambridge
  Christoph Schuba, Purdue University
  Jonathan Trostle, CyberSafe
  Theodore Ts'o, Massachusetts Institute of Technology
  Doug Tygar, Carnegie Mellon University
  Vijay Varadharajan, University of W. Sydney
  Roberto Zamparo, Telia Research

PUBLICATIONS CHAIR
  Steve Welke, Institute for Defense Analyses

LOCAL ARRANGEMENTS CHAIR
  Thomas Hutton, San Diego Supercomputer Center

REGISTRATIONS CHAIR
  Torryn Brazell, Internet Society

STEERING GROUP
  Internet Research Task Force, Privacy and Security Research Group

SPONSORED BY THE INTERNET SOCIETY
  Donald M. Heath, President & CEO
  Martin Burack, Executive Director

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

           S A N   D I E G O   P R I N C E S S   R E S O R T

LOCATION

  The Symposium venue is the San Diego Princess Resort, a tropical
  paradise on a forty-four acre island in Mission Bay, ten minutes
  from the international airport.  Lush gardens landscaped with
  hundreds of species of tropical and subtropical plants are
  always ablaze with color and perfect for themed group events.
  Charming pathways wander among sparkling waterfalls, across
  quaint footbridges and sleepy lagoons filled with water lilies
  and waterfowl.  A white sand beach curves around the island
  for over a mile, and the award-winning grounds encompass five
  swimming pools and six lighted tennis courts.

  Spouses and family members can catch a convenient Harbor Hopper
  for a quick trip to Sea World.  Plan to visit La Jolla, the world
  famous San Diego Zoo or Mexico, only 30 minutes by car or Trolley.

HOUSING INFORMATION

  We have reserved a special block of sleeping rooms at the San Diego
  Princess Resort at the following rates:

      Lanai Patio Rooms           $ 81*
      Lanai Garden Rooms          $114

  * This represents the Government Rate for San Diego.  A limited 
    number of rooms are available at this rate.  Reservations must 
    be made no later than January 13, 1997.  You must present a 
    valid government id upon check-in.

  Based on room type and space availability, the special group
  rates are applicable two days prior to and two days after the
  symposium.  Current Room Tax is 10.5%.

  Check-in availability cannot be committed prior to 4:00 p.m.
  Check-out time is 12:00 noon. The San Diego Princess Resort
  will make every effort to accommodate any early arrivals, so
  make sure you give them your arrival time when you make your
  reservation.

TO MAKE A RESERVATION

  Contact the San Diego Princess Resort at +1-800-344-2626
  (+1-619-274-4630 if outside the United States).  To receive
  the special group rates, reservations must be made no later
  than January 20, 1997.  To receive the special goverment 
  rate, you must make your reservation by January 13, 1997.

CLIMATE

  February weather in San Diego is normally very pleasant.  Early
  morning temperatures average 55 degrees while afternoon
  temperatures average 67 degrees.  Generally, a light jacket or
  sweater is adequate, although, occasionally it rains.

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

            R E G I S T R A T I O N   I N F O R M A T I O N

FEES                                      ISOC            Non-
                                         Members         Member*
  Early registration 
  (postmarked on/before Jan. 22)         $305            $345

  Late registration                      $375            $415

REGISTRATION INCLUDES

  - Attendance      - Symposium Proceedings     - Two luncheons
  - Reception       - Banquet                   - Coffee Breaks

  * Non-Member fee includes one year Internet Society membership.

FOR MORE INFORMATION 

  Contact Carol Gray at the Internet Society at +1-703-648-9888 
  or send E-mail to [email-masked].

WEB PAGE

  Additional information about the symposium and San Diego, plus
  on-line registration, are available via the Web at:

            http://www.isoc.org/conferences/ndss97

SPONSORSHIP OPPORTUNITIES AVAILABLE!

  Contact Torryn Brazell at the Internet Society at +1-703-648-9888 
  or send E-mail to [email-masked].

---------------------------------------------------------------------------

                  R E G I S T R A T I O N   F O R M

INTERNET SOCIETY SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY
10-11 FEBRUARY, 1997                       SAN DIEGO, CALIFORNIA, USA

Fill out this form and FAX it to NDSS'97 Registration at +1-703-648-9887,
send it via E-mail to [email-masked], or mail it to NDSS97,
12020 Sunrise Valley Drive, Suite 210, Reston, VA, 20191, USA

PERSONAL INFORMATION

  __Mr __Ms __Mrs __Dr __Prof __M __Prof Dr __Dip Ing __Ing __Miss __Mlle

  First Name: ________________________________  MI: ____________________

  Family Name: ___________________________________  __Sr __Jr __II __III

  Badge Name: __________________________________________________________
  Please enter your name as you would like it to appear on your name tag.

CONTACT INFORMATION

  Title: _______________________________________________________________

  Organization: ________________________________________________________

  Street address: ______________________________________________________

  ______________________________________________________________________

  City: ________________________________________________________________

  State/Province: ___________________________  Postal Code: ____________

  Country: _____________________________________________________________

  Telephone Number (work): _____________________________________________

  Telephone Number (home): _____________________________________________

  Fax Number: __________________________________________________________

  E-mail address: ______________________________________________________

SPECIAL NEEDS?  (Vegetarian meals, wheelchair access, etc?)

  ______________________________________________________________________

  ______________________________________________________________________

APPEAR ON REGISTRANTS LIST?

  ___  Please check here if you would NOT like your name included 
       in the list of registrants.

PAYMENT INFORMATION

  All Payments must be in United States Dollars.

  Conference Fee
  --------------

  If you are an Internet Society member, you are eligible for a
  reduced conference registration fee.  Non-member symposium 
  attendees will receive a one year Internet Society membership 
  as part of the non-member registration fees.

  Check one:                        On/Before        After
                                    January 22    January 22
                                    ----------    ----------
  ___ Internet Society Member Fee   US$ 305.00    US$ 375.00

  ___ Non-Member Fee                US$ 345.00    US$ 415.00

  Method of Payment
  -----------------

  Payment must be received on/before February 7, 1997 or we will 
  be unable to pre-register you.

  1. ___ Check.  Make payable to the Internet Society.  

  2. ___ Credit Card. ___ American Express ___ Visa ___ Mastercard

         Name on Credit Card: ____________________________________
  
         Credit Card Number: _____________________________________

         Expiration Date: ________________________________________

  3. ___ CyberCash.  Account Number: _____________________________

  4. ___ First Virtual.  Account Number: _________________________

  5. ___ Wire Transfer*		

         Bank ABA Number: 054000030
         Account Number: Internet Society 148 387 10

         Riggs National Bank of Virginia   
         950 Herndon Parkway               
         Herndon, VA  20171  USA

         Wire Transfer Confirmation Number: ______________________

         * Please process wire transfer before sending registration 
	   form.

  6. ___ U.S. Government Purchase Order*

         P.O. Number: ____________________________________________

         * Please fax or mail a copy of your purchase order along 
	   with your registration form.

  Cancellation Policy
  -------------------

  Refunds (less a $25 processing fee) will be issued for cancellations 
  received on/before February 7, 1997.  No refunds will be issued 
  after February 7, 1997.

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

Date: Fri, 22 Nov 1996 14:46:18 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Displaying an X.509 certificate -Reply
Status:   

I concur with the desirability of having a convenient way to display 
ALL of the contents of a certificate, even those private attributes
for which the syntax may not be known to a given application
program. 

But in addition to having a convenient and user-friendly (Unicode)
certificate dump program, it would also be extremely useful if
the major CA and CA tool developers would publish the standard
syntax and semantics of the certificates they are currently 
producing or plan to produce. I don't think vendors ought to have
to reverse-engineer certificate formats in order to display the 
contents within an application.

I'd like to specifically request that VeriSign and GTE CyberTrust 
provide some industry leadership in such an initiative.

Bob

>>> Peter Williams <[email-masked]> 11/21/96 10:40am >>>
This is highly touchy subject!

For several legal reasons there are needs to "document"
a certificate. There is a formal notation system for
ASN.1 values, fortunately, as there are for
ASN.1 types. Its been my recommendation to
date that one uses this formalism as
it has international recognition, and therefore
a certain legal standing because of that
concensus, review, and voting procedure.

Whilst ASN.1 value notation may suit court proceedings, the particular
form, arguably, does not suit residential consumers - from
the perpective of their fully understanding what
is being presented. But, looking at EDI, SPKI, PGP and ASN.1
certs, I dont think anyone of these forms will ever fit that bill, however. 

next. The world is no longer reduced to American ascii character
sets, and in an international setting such as the
internet, any popular consumer format really has to embrace
multi-byte char sets, especially when these chars are used 
to signal peoples names. ASN.1 has the benefit (and deliberate design) that
its value notation is flexible enough to present strings in
particular char sets natively (human readable form!), not in
encoded octet form.

I think it would be useful for PKIX to establish an Internet
presentation format for Internet PKI certs, which does not rely on encoding
forms. Elements of the above would all be useful as starting point.

(its worth noting that the legally-relevant EDI messaging and
trusted third-party msg delivery industry has not demonstrated
huge legal/consumer problems with its estoteric, highly-computer-centric
encoding and data presentation formats; but then its not your residential
consumer who has very often been the intended recipient of the service)

Peter.

----------
From: 	[email-masked]
Sent: 	Wednesday, November 20, 1996 6:44 PM
To: 	[email-masked]
Subject: 	Displaying an X.509 certificate

Does anyone know where I can find a program that, given an X.509 certificate, will
display its fields and their values in some human-readable form?

Thanks,

Gillian Elcock

Date: Fri, 22 Nov 1996 11:49:21 -0800
From: [email-masked] (Hoa Ly)
Reply-To: [email-masked]
Organization: Netscape Communications
To: [email-masked]
Subject: subscribe 
Status:   

subscribe [email-masked] ietf-pkix

Date: Fri, 22 Nov 1996 14:46:18 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Displaying an X.509 certificate -Reply

I concur with the desirability of having a convenient way to display 
ALL of the contents of a certificate, even those private attributes
for which the syntax may not be known to a given application
program. 

But in addition to having a convenient and user-friendly (Unicode)
certificate dump program, it would also be extremely useful if
the major CA and CA tool developers would publish the standard
syntax and semantics of the certificates they are currently 
producing or plan to produce. I don't think vendors ought to have
to reverse-engineer certificate formats in order to display the 
contents within an application.

I'd like to specifically request that VeriSign and GTE CyberTrust 
provide some industry leadership in such an initiative.

Bob

>>> Peter Williams <[email-masked]> 11/21/96 10:40am >>>
This is highly touchy subject!

For several legal reasons there are needs to "document"
a certificate. There is a formal notation system for
ASN.1 values, fortunately, as there are for
ASN.1 types. Its been my recommendation to
date that one uses this formalism as
it has international recognition, and therefore
a certain legal standing because of that
concensus, review, and voting procedure.

Whilst ASN.1 value notation may suit court proceedings, the particular
form, arguably, does not suit residential consumers - from
the perpective of their fully understanding what
is being presented. But, looking at EDI, SPKI, PGP and ASN.1
certs, I dont think anyone of these forms will ever fit that bill, however. 

next. The world is no longer reduced to American ascii character
sets, and in an international setting such as the
internet, any popular consumer format really has to embrace
multi-byte char sets, especially when these chars are used 
to signal peoples names. ASN.1 has the benefit (and deliberate design) that
its value notation is flexible enough to present strings in
particular char sets natively (human readable form!), not in
encoded octet form.

I think it would be useful for PKIX to establish an Internet
presentation format for Internet PKI certs, which does not rely on encoding
forms. Elements of the above would all be useful as starting point.

(its worth noting that the legally-relevant EDI messaging and
trusted third-party msg delivery industry has not demonstrated
huge legal/consumer problems with its estoteric, highly-computer-centric
encoding and data presentation formats; but then its not your residential
consumer who has very often been the intended recipient of the service)

Peter.

----------
From: 	[email-masked]
Sent: 	Wednesday, November 20, 1996 6:44 PM
To: 	[email-masked]
Subject: 	Displaying an X.509 certificate

Does anyone know where I can find a program that, given an X.509 certificate, will
display its fields and their values in some human-readable form?

Thanks,

Gillian Elcock

Date: Fri, 22 Nov 1996 11:49:21 -0800
From: [email-masked] (Hoa Ly)
Reply-To: [email-masked]
Organization: Netscape Communications
To: [email-masked]
Subject: subscribe 

subscribe [email-masked] ietf-pkix

From: [email-masked]
Sender: Post Master <[email-masked]>
To: Denis Trcek <[email-masked]>
CC: [email-masked]
Date: Fri, 22 Nov 1996 08:03:54 +0000
Subject: RE: Displaying an X.509 certificate
Priority: normal

Sorry,

Our WWW site is http://www.iol.ie/~formal

David

> Date:          Fri, 22 Nov 1996 08:37:47 +0100
> From:          Denis Trcek <[email-masked]>
> Subject:       RE: Displaying an X.509 certificate
> To:            "[email-masked]'" <[email-masked]>

> 
> We have a Windows NT program "Certificate Viewer" to do just this.
> 
> Visit out WWW site and you can get a copy.
> 
> 
> Sorry, David, would you mind to tell the address of your server /
> www.formal.ie doesn' t work. ?Thanks.	/denis
> 
> 

.......................................................
David Gray                      e-mail: [email-masked]
Formal Systems                http://www.iol.ie/~formal
4 Roebuck Castle
Roebuck Road
Clonskeagh
Dublin 14
Ireland
.......................................................

From: <[email-masked]>
Sender: Post Master <[email-masked]>
To: [email-masked], [email-masked]
Date: Thu, 21 Nov 1996 21:11:51 +0000
Subject: Re: Displaying an X.509 certificate
Priority: normal
Status:   

Hi Gillian,

We have a Windows NT program "Certificate Viewer" to do just this.

Visit out WWW site and you can get a copy.

David

> From:          [email-masked]
> To:            [email-masked]
> Subject:       Displaying an X.509 certificate
> Date:          Wed, 20 Nov 96 21:44:08 -0500

> 
> 
> 
> Does anyone know where I can find a program that, given an X.509
> certificate, will display its fields and their values in some
> human-readable form?
> 
> 
> 
> Thanks,
> 
> Gillian Elcock
> 

.......................................................
David Gray                      e-mail: [email-masked]
Formal Systems                http://www.iol.ie/~formal
4 Roebuck Castle
Roebuck Road
Clonskeagh
Dublin 14
Ireland
.......................................................

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Displaying an X.509 certificate
Date: Thu, 21 Nov 1996 09:40:06 -0800
Status:   

This is highly touchy subject!

For several legal reasons there are needs to "document"
a certificate. There is a formal notation system for
ASN.1 values, fortunately, as there are for
ASN.1 types. Its been my recommendation to
date that one uses this formalism as
it has international recognition, and therefore
a certain legal standing because of that
concensus, review, and voting procedure.

Whilst ASN.1 value notation may suit court proceedings, the particular
form, arguably, does not suit residential consumers - from
the perpective of their fully understanding what
is being presented. But, looking at EDI, SPKI, PGP and ASN.1
certs, I dont think anyone of these forms will ever fit that bill, however. 

next. The world is no longer reduced to American ascii character
sets, and in an international setting such as the
internet, any popular consumer format really has to embrace
multi-byte char sets, especially when these chars are used 
to signal peoples names. ASN.1 has the benefit (and deliberate design) that
its value notation is flexible enough to present strings in
particular char sets natively (human readable form!), not in
encoded octet form.

I think it would be useful for PKIX to establish an Internet
presentation format for Internet PKI certs, which does not rely on encoding
forms. Elements of the above would all be useful as starting point.

(its worth noting that the legally-relevant EDI messaging and
trusted third-party msg delivery industry has not demonstrated
huge legal/consumer problems with its estoteric, highly-computer-centric
encoding and data presentation formats; but then its not your residential
consumer who has very often been the intended recipient of the service)

Peter.

----------
From: 	[email-masked]
Sent: 	Wednesday, November 20, 1996 6:44 PM
To: 	[email-masked]
Subject: 	Displaying an X.509 certificate

Does anyone know where I can find a program that, given an X.509 certificate, will
display its fields and their values in some human-readable form?

Thanks,

Gillian Elcock

From: <[email-masked]>
Sender: Post Master <[email-masked]>
To: [email-masked], [email-masked]
Date: Thu, 21 Nov 1996 07:52:27 +0000
Subject: Re: Displaying an X.509 certificate
Priority: normal
Status:   

Hi Gillian,

We have a Windows NT program "Certificate Viewer" to do just this.

Visit out WWW site and you can get a copy.

David

> From:          [email-masked]
> To:            [email-masked]
> Subject:       Displaying an X.509 certificate
> Date:          Wed, 20 Nov 96 21:44:08 -0500

> 
> 
> 
> Does anyone know where I can find a program that, given an X.509 certificate, will
> display its fields and their values in some human-readable form?
> 
> 
> 
> Thanks,
> 
> Gillian Elcock
> 

.......................................................
David Gray                      e-mail: [email-masked]
Formal Systems                http://www.iol.ie/~formal
4 Roebuck Castle
Roebuck Road
Clonskeagh
Dublin 14
Ireland
.......................................................

From: [email-masked]
Sender: Post Master <[email-masked]>
To: [email-masked], [email-masked]
Date: Thu, 21 Nov 1996 21:11:51 +0000
Subject: Re: Displaying an X.509 certificate
Priority: normal

Hi Gillian,

We have a Windows NT program "Certificate Viewer" to do just this.

Visit out WWW site and you can get a copy.

David

> From:          [email-masked]
> To:            [email-masked]
> Subject:       Displaying an X.509 certificate
> Date:          Wed, 20 Nov 96 21:44:08 -0500

> 
> 
> 
> Does anyone know where I can find a program that, given an X.509
> certificate, will display its fields and their values in some
> human-readable form?
> 
> 
> 
> Thanks,
> 
> Gillian Elcock
> 

.......................................................
David Gray                      e-mail: [email-masked]
Formal Systems                http://www.iol.ie/~formal
4 Roebuck Castle
Roebuck Road
Clonskeagh
Dublin 14
Ireland
.......................................................

From: "Robin Garner" <[email-masked]>
To: <[email-masked]>
Subject: unsubscribe
Date: Thu, 21 Nov 1996 16:02:28 +1100
Info: Evaluation version at ntdev.signet.org.au
Status:   

unsubscribe [email-masked]

--
Robin Garner
System Management Consultant
SMTP:  [email-masked]
      [email-masked]

To: [email-masked]
Subject: Re: Delivery-Report (failure) for [email-masked] 
Date: Thu, 21 Nov 1996 09:32:56 -0500
From: "Charles W. Gardiner" <[email-masked]>
Status:   

    Can't someone remove [email-masked] from this mailing list so we won't
all get junk reject messages?  

Date: Thu, 21 Nov 96 10:05:39 CET
From: "Haydn, Josef" <[email-masked]>
To: [email-masked]
Subject: Betr.:: Delivery-Report (failure) for [email-masked]
Status:   

     
     I get a lot of mails looking like this every day. Could someone 
     correct the address or remove it from the list.
     
     Regards,
     
     Josef Haydn

____________________________ Antwort-Abtrennung ________________________________
Betreff: Delivery-Report (failure) for [email-masked]
Autor:  [email-masked] bei Internet
Datum:    20.11.96 12:53

 messsage id: <[email-masked]> 
 subject: Re: Re[2]: X.509 V3
Delivery failed to [email-masked]
 reason:  INVALID DESTINATION ADDRESS 

From: [email-masked]
Sender: Post Master <[email-masked]>
To: [email-masked], [email-masked]
Date: Thu, 21 Nov 1996 07:52:27 +0000
Subject: Re: Displaying an X.509 certificate
Priority: normal

Hi Gillian,

We have a Windows NT program "Certificate Viewer" to do just this.

Visit out WWW site and you can get a copy.

David

> From:          [email-masked]
> To:            [email-masked]
> Subject:       Displaying an X.509 certificate
> Date:          Wed, 20 Nov 96 21:44:08 -0500

> 
> 
> 
> Does anyone know where I can find a program that, given an X.509 certificate, will
> display its fields and their values in some human-readable form?
> 
> 
> 
> Thanks,
> 
> Gillian Elcock
> 

.......................................................
David Gray                      e-mail: [email-masked]
Formal Systems                http://www.iol.ie/~formal
4 Roebuck Castle
Roebuck Road
Clonskeagh
Dublin 14
Ireland
.......................................................

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Displaying an X.509 certificate
Date: Thu, 21 Nov 1996 09:40:06 -0800

This is highly touchy subject!

For several legal reasons there are needs to "document"
a certificate. There is a formal notation system for
ASN.1 values, fortunately, as there are for
ASN.1 types. Its been my recommendation to
date that one uses this formalism as
it has international recognition, and therefore
a certain legal standing because of that
concensus, review, and voting procedure.

Whilst ASN.1 value notation may suit court proceedings, the particular
form, arguably, does not suit residential consumers - from
the perpective of their fully understanding what
is being presented. But, looking at EDI, SPKI, PGP and ASN.1
certs, I dont think anyone of these forms will ever fit that bill, however. 

next. The world is no longer reduced to American ascii character
sets, and in an international setting such as the
internet, any popular consumer format really has to embrace
multi-byte char sets, especially when these chars are used 
to signal peoples names. ASN.1 has the benefit (and deliberate design) that
its value notation is flexible enough to present strings in
particular char sets natively (human readable form!), not in
encoded octet form.

I think it would be useful for PKIX to establish an Internet
presentation format for Internet PKI certs, which does not rely on encoding
forms. Elements of the above would all be useful as starting point.

(its worth noting that the legally-relevant EDI messaging and
trusted third-party msg delivery industry has not demonstrated
huge legal/consumer problems with its estoteric, highly-computer-centric
encoding and data presentation formats; but then its not your residential
consumer who has very often been the intended recipient of the service)

Peter.

----------
From: 	[email-masked]
Sent: 	Wednesday, November 20, 1996 6:44 PM
To: 	[email-masked]
Subject: 	Displaying an X.509 certificate

Does anyone know where I can find a program that, given an X.509 certificate, will
display its fields and their values in some human-readable form?

Thanks,

Gillian Elcock

Organization: Consensus Development Corporation <http://www.consensus.com/>
Date: Thu, 21 Nov 1996 09:33:09 -0800
To: "Haydn, Josef" <[email-masked]>
From: Christopher Allen <[email-masked]>
Subject: Re: Betr.:: Delivery-Report (failure) for [email-masked]
Cc: [email-masked]

At 2:05 AM -0800 11/21/96, Haydn, Josef wrote:
>     I get a lot of mails looking like this every day. Could someone
>     correct the address or remove it from the list.

(caveat, I am not a list administrator on this list) I have tried to get
this person deleted from the list by sending a request to the tandem
postmaster, who has reported to me that the list administrator for this
list is no longer with tandem.

I'm not sure how to resolve the problem -- I'll try forging an unsubscribe
message however if Tandem is using any reasonably decent list server
software it will probably reject my request.

------------------------------------------------------------------------
..Christopher Allen                  Consensus Development Corporation..
..<[email-masked]>                 1563 Solano Avenue #355..
..                                             Berkeley, CA 94707-2116..
..Home of "SSL Plus:                      o510/559-1500  f510/559-1505..
..  SSL 3.0 Integration Suite(tm)" <http://www.consensus.com/SSLPlus/>..

To: [email-masked]
Subject: Re: Delivery-Report (failure) for [email-masked] 
Date: Thu, 21 Nov 1996 09:32:56 -0500
From: "Charles W. Gardiner" <[email-masked]>

    Can't someone remove [email-masked] from this mailing list so we won't
all get junk reject messages?  

Date: Thu, 21 Nov 96 10:05:39 CET
From: "Haydn, Josef" <[email-masked]>
To: [email-masked]
Subject: Betr.:: Delivery-Report (failure) for [email-masked]

     
     I get a lot of mails looking like this every day. Could someone 
     correct the address or remove it from the list.
     
     Regards,
     
     Josef Haydn

____________________________ Antwort-Abtrennung ________________________________
Betreff: Delivery-Report (failure) for [email-masked]
Autor:  [email-masked] bei Internet
Datum:    20.11.96 12:53

 messsage id: <[email-masked]> 
 subject: Re: Re[2]: X.509 V3
Delivery failed to [email-masked]
 reason:  INVALID DESTINATION ADDRESS 

From: "Robin Garner" <[email-masked]>
To: <[email-masked]>
Subject: unsubscribe
Date: Thu, 21 Nov 1996 16:02:28 +1100
Status:   

unsubscribe [email-masked]

--
Robin Garner
System Management Consultant
SMTP:  [email-masked]
      [email-masked]

Date: Thu, 21 Nov 1996 08:51:05 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: "Hoffman, Mort" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Self-signed root transport and CA expiration

Mort,

Au contraire - I'd suggest the integrity of the CA business lies on
the web of trust side of the scale simply because the notion of
'assurance' is a fundamental part of that paradigm.

--
Mark Shuttleworth
Thawte Consulting

From: <[email-masked]>
To: [email-masked]
Subject: Displaying an X.509 certificate
Date: Wed, 20 Nov 96 21:44:08 -0500
Status:   

Does anyone know where I can find a program that, given an X.509 certificate, will
display its fields and their values in some human-readable form?

Thanks,

Gillian Elcock

From: <[email-masked]>
Date: 20 Nov 96 21:02:48 (-0500)
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked]
Message-Type: Delivery Report
Status:   

	messsage id:	<[email-masked]>
	subject:	Re: Re[2]: X.509 V3
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

From: <[email-masked]>
Date: 20 Nov 96 12:53:02 (-0500)
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked]
Message-Type: Delivery Report
Info: Evaluation version at ntdev.signet.org.au
Status:   

	messsage id:	<[email-masked]>
	subject:	Re: Re[2]: X.509 V3
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

From: "Robin Garner" <[email-masked]>
To: <[email-masked]>
Subject: unsubscribe
Date: Thu, 21 Nov 1996 16:02:28 +1100

unsubscribe [email-masked]

--
Robin Garner
System Management Consultant
SMTP:  [email-masked]
      [email-masked]

From: <[email-masked]>
To: [email-masked]
Subject: Displaying an X.509 certificate
Date: Wed, 20 Nov 96 21:44:08 -0500

Does anyone know where I can find a program that, given an X.509 certificate, will
display its fields and their values in some human-readable form?

Thanks,

Gillian Elcock

From: <[email-masked]>
Date: 20 Nov 96 21:02:48 (-0500)
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked]
Message-Type: Delivery Report

	messsage id:	<[email-masked]>
	subject:	Re: Re[2]: X.509 V3
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

From: <[email-masked]>
Date: 20 Nov 96 17:30:01 (-0500)
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked]
Message-Type: Delivery Report
Status:   

	messsage id:	<[email-masked]>
	subject:	Re: Re[2]: X.509 V3
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

From: Stefan Kelm <[email-masked]>
Date: Wed, 20 Nov 1996 14:37:34 +0100 (MET)
To: [email-masked]
Subject: Re: Re[2]: X.509 V3
Reply-To: [email-masked]
Info: Evaluation version at ntdev.signet.org.au
Original-Content-Type: text/plain
Status:   

> 
> although i don't think the connection to our server are very slow, i would agree
> that european access would be best done to a mirror site. i was unaware of the
> site mentioned below. however, i do have an agreement with the following site to
> mirror the contents of OSIdirectory (i am unsure the one mentioned below has the
> asn.1 for the v1 and v2 certificates)
> 
>   ftp://ftp.nameflow.dante.net/mirror/OSIdirectory
> 
>    hoyt

Sorry, Hoyt, but the connections from Germany to bull.com *are* very slow,
that's why I set up the mirror in the first place. As for the contents, we
copy the complete path (ftp://NC-17.MA02.Bull.com/pub/OSIdirectory/) once a
week (w/o an agreement, that is, which we do not need, anyway).

Greets,

	Stefan.

______________________________________________________________________________
Stefan Kelm <[email-masked]>                WWW: http://www.pca.dfn.de/~kelm/
DFN-PCA,  University of Hamburg, Vogt-Koelln-Str. 30,  22527 Hamburg (Germany)
                                 Phone: +49-40-54942262 / Fax: +49-40-54942241
             ["finger [email-masked]" to get my PGP key]

Priority: Normal
To: [email-masked]
From: Edward Russell <[email-masked]>
Sender: Edward Russell <[email-masked]>
Subject: RE: Self-signed root transport and CA expiration
Date: Wed, 20 Nov 1996 11:10:55 -0500
Info: Evaluation version at ntdev.signet.org.au
Status:   

Ned Smith ([email-masked]) said on 11/19/96

|||
|||Have you considered the possibility of including the issuer public key in
|||the subject's certificate? That way every certificate is a self-signed
|||cert.
|||Users(applications) that become reasonably familiar with any particular
|||public key - and therefore trust it implicitly could choose not to verify to
|||the root to obtain a self-signed cert.

To which Ed Russell replies

"Familiar with any particular public key" - How would I know whether it is
the public key I am familiar with other than comparing the key itself or
its fingerprint if you included that too with every CA public key I have 
in my local store (or the set I am "familiar" with).

Whether I check the signature of a certificate with a public key included in
that certificate or with the public key in a certificate accompanying the message,
I still have to make sure that the key claiming to be the CA key is in fact
the same key that I think is the CA key.

Once I have accomplished that I have to make sure the CA key is valid in the chain.
I either do that by chasing it to the root, or flagging it as one I am "familiar" with.
However the familiarity bit must be 1. secured from being flipped without my knowledge
and 2. periodically rechecked since higher level CA certs may expire (I guess they are 
still valid in that case anyway) or even put onto a CRL 
("Bribery Discovered at XYZ Cert Authority!!! - all certs suspect!")

Edward Russell
[email-masked]

From: <[email-masked]>
Date: 20 Nov 96 12:53:02 (-0500)
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked]
Message-Type: Delivery Report
Status:   

	messsage id:	<[email-masked]>
	subject:	Re: Re[2]: X.509 V3
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

From: <[email-masked]>
Date: 20 Nov 96 17:30:01 (-0500)
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked]
Message-Type: Delivery Report

	messsage id:	<[email-masked]>
	subject:	Re: Re[2]: X.509 V3
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

Date: Wed, 20 Nov 1996 14:30:41 -0800
To: Edward Russell <[email-masked]>
From: Ned Smith <[email-masked]>
Subject: RE: Self-signed root transport and CA expiration
Cc: [email-masked], [email-masked]

At 11:10 AM 11/20/96 -0500, Edward Russell wrote:
>Ned Smith ([email-masked]) said on 11/19/96
>
>|||
>|||Have you considered the possibility of including the issuer public key in
>|||the subject's certificate? That way every certificate is a self-signed
>|||cert.
>|||Users(applications) that become reasonably familiar with any particular
>|||public key - and therefore trust it implicitly could choose not to verify to
>|||the root to obtain a self-signed cert.
>
>To which Ed Russell replies
>
>"Familiar with any particular public key" - How would I know whether it is
>the public key I am familiar with other than comparing the key itself or
>its fingerprint if you included that too with every CA public key I have 
>in my local store (or the set I am "familiar" with).
>
>Whether I check the signature of a certificate with a public key included in
>that certificate or with the public key in a certificate accompanying the
message,
>I still have to make sure that the key claiming to be the CA key is in fact
>the same key that I think is the CA key.

You have to do this regardles of whether the certificate contains the
issuer's public key or just the issuers DN. If the DN is provided then we
have to lookup the key from an external table before we can verify the
signature on the subject cert. If the issuer public key is provided then we
can verify the signature straight away. But we still must check to see if
the key is one we are familiar with, which equates to an external table
lookup. So the two approaches appear to be at least equal cost up to this point.

Yes I agree, the table of "familiar" keys should be updated according to
revocation messages issued by trusted CAs (who themselves likely would be on
the list).

If the number of keys the user is "familiar" with is small say 0-100 then
the lookup operation could be quite inexpensive. Using the other model,
every stage of the verification process requires every issuer DN in the
chain to also have an entry in the table. Otherwise, how would the verify
process know what key to use to verify the signature? This seems to imply
that the table potentially should have a DN/key entry for every public key
issued under the trusted domain. This could become a rather large table.
Plus this table must be kept consistent across all nodes performing
verfication checks (within the same domain). This seems to suggest some form
of distributed database or directory infrastructure is needed? My conjecture
is that the lookup costs of a large directory is larger than that of a small
one. Furthermore the majority of the costs of building and maintaining the
directory infrastructure must be paid upfront. 

If we assume the only way to get a cert chain is from the sender of a
message and the chain is comprised of self-signed certs, then a directory
service is not needed to verify the cert chain.

If we assume the cost of sending additional certificates with messages is
equal to the cost of maintaining consistent copies of a distributed
directory,  then the two approaches may very well have the same net cost in
terms of total computation and transmission.

However, the later (where every cert is a self-signed cert) does not first
require the deployment of the directory service before the verification
procedures can start operating. Interactions between principals in common
sub-domains could  send only the number of certs in the chain to get to the
common sub-domain (say intra-company messages). The unneeded part of the
chain above the sub-domain could be dropped since all principals are
familiar with the sub-domain key (and trust the sub-domain). This suggests
that the overhead of always needing to send the complete cert chain is not
mandatory.

Barring the mental gymnastics above, self-signed certs would make
bootstrapping a global certificate infrastructure more palatable IMHO.

Regards,
Ned

>
>Once I have accomplished that I have to make sure the CA key is valid in
the chain.
>I either do that by chasing it to the root, or flagging it as one I am
"familiar" with.
>However the familiarity bit must be 1. secured from being flipped without
my knowledge
>and 2. periodically rechecked since higher level CA certs may expire (I
guess they are 
>still valid in that case anyway) or even put onto a CRL 
>("Bribery Discovered at XYZ Cert Authority!!! - all certs suspect!")
>
>
>
>
>Edward Russell
>[email-masked]
>
>
>
Ned Smith~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Intel Architecture Labs  2111 N.E. 25th Ave.  Hillsboro, OR. 97124     
Ph: 503.264.2692 Fax: x1805  Email: mailto:[email-masked]   
http://www.intel.com/ial/security/index.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From: Peter Williams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Hoffman, Mort'" <[email-masked]>
Subject: RE: Self-signed root transport and CA expiration
Date: Wed, 20 Nov 1996 13:10:43 -0800

Mort,

Ill reply widely, given your legit moan, even though its off topic for an IETF work
list. I try to keep talk and work lists separate, in general ; I sometimes
forget though I try hard to be a good citizen on lists.

"Web of Trust" is almost a trademarked term - owned by PGPers. So
I dont use it (*), particularly as its PGP(tm) connotation is not what I
am asserting. (* except as intended by PGPers)

I am asserting X.509 (not-tm),  which has a defined procedure and internationally
standardised syntaxes for determining both forward and reverse cert
paths which, when combined, enable joint agreement of common points
of trust, not necessarily known a priori. it also has a procedure
and clauses which say - you can do whatever you like, if
you dont think this fits your needs.

This procedure has little to do with PGP, as we know it. It has lots to
do with corporate and public management domains, and scaling up an multi-domain
mixed private and public authentication infrastructures to allow both interworking,
use of any mass-market application, AND instrument localization
of authentication security policy when relying on the infrastructure.

I would have expected you to support, in general, standard procedures
ratified internationally. Whether any given path determination
system is suitable for a given environment of application is always a matter
for local system designers. 

Im sorry, Mort; I just dont subscribe to the "one true way". I was
trained to be a utilitarian. if PGP format certs is what customers want,
you can be sure VeriSign will be providing them. Ill argue for
standards use as ever, but I will not force them on people who dont want
them. Similarly,. Ill advise the benefits of hierarchical elements 
in key management domain mgt to promote the bigger PKI; but Im not going to
force the pace nor the nature of open networking theory on those who,say, definitively
want the commercial privacy properties of the  Entrust n*n peer-peer model. I do
see the procedure of X.509 for common trust point determination
as being that which, over time, will allow mix and match of
whatever gets shipped during the first five years of our industry. I
dont expect the Internet PKI to get built overnight.

Contrary to the first 20 years of commercial key management services
sold to militaries, there is unlikely to be any one way of doing *it*
in the commercial world. Companies which are succesful in this
space think open, and be open. Im glad to see a major company like GTE
(and  with GTE's fine symmetric-key management credentials)
finally taking part openly in the pertinent IETF forum! I just
wish Motorola GEG would step up their activity, too,
to ensure we get the benfit of their systems-wide experience
and MISSI/NSA work.

Do you have any comments on what youd like changed in the PKIX drafts
which you are willing to share on the mailing list?

Do you share VeriSign's hope that the industry moves to implement
and offer services/products which seek to conform to the specs
ASAP, when engaged in IETF layer protocols like PEM, TLS, IPSEC,
etc.

 ----------
From: 	Hoffman, Mort
Sent: 	Wednesday, November 20, 1996 11:43 AM
To: 	[email-masked]'; [email-masked]'; [email-masked]'
Subject: 	RE: Self-signed root transport and CA expiration

Peter,

Sorry for responding so slowly, but you left me (and pkix) off your
to/cc list, and while I got your first message on pkix, I did not get
your latter message at all.

I am quite familiar with Web of Trust models, and there are certainly
applications where it is a serviceable and even desireable model.
However, there are other applications, many of them non-military, where
such a model is weak.  In particular, I consider the retail banking
model one such model.  If everyone individually decides who to trust
based on private criteria, then I'm not sure how disputes get resolved.
My suspicion is that it would be far more expensive, when MasterCard
needs to check out Joe's personal certificate generation program to
decide if it is willing to trust or challenge Mary's assertion that it
must be a good signature because Joe said so.

Indeed, the viability of the whole CA business may be based on this
problem!  Clearly, this is not to challenge the notion of multiple trust
points that X.509 so clearly includes in its model.  From my own
perspective, when there are a relatively small number of them, I would
characterize it as cross-certification rather than root-less.  If
Verisign asserts that it has no root, it seems to be suggesting that
its' certificates should only be trusted based on personal faith -- we
all have faith (of some sorts), but they tend not to be consistent
enough to each other to form the basis of commercial trust.

I guess the other part of the discussion pertained to the lack of root
certificate of the (pardon my personal description of the beast) Versign
root.  Do I understand you correctly that the reason is that X.509 would
make you have a certificate expiration date if you had a certificate, so
that you avoid the problem by avoiding the certificate?  Surely you
could issue a new certificate if you still liked the key ...  It only
need happen every few years.

Mort
----------------------------------------

Mort,

If you read the self-governing regulations for the VeriSign public
certification
services (CPS), you will notice the declaration of a "VeriSign Root" -
an 
authority
with a defined function, which serves to register public key of
*VeriSign* CAs, 
and which
outputs a package known as a self-signed public key (read the document
for
precise terminology). Said package exists for the purpose of conveying
a trust point (see X.509) for use in the context of administering
local security policy of systems which wish to validate user certs which
impelment some control system (MOA, key distribution, etc)

The transport vehicle used to convey trust points and assure their
authenticity 
when used in a validating system can be a Fortezza
card slot, else a EMV smartcard public key slot or EMV smarctard reader
trusted 
terminal.
Other proprietary techniques exist on a per token basis which may
not be be based on public key techniques. It may also be a Netscape
technique for learning trust points dynamically. Ask the vendor
of the local security policy enforcing MIB!

You and I differ on protocol-bound chain semantics for internet
protocols; I try
to best follow the X.509 std in that within a useful trust chain is a
trust 
point. It may
be at the top, it may be in the middle, it may be at the level of a user
certificate. it may
not even be present within the set of certs of which the party which
quotes a user cert is even aware of. Such knowledge may be hidden
for sensitivity reasons. In OSI and PEM protocols, the cert bag sent
to accompany a protected service may even allow for suggest selection of
multiple
common trust points by the receipient. (* SSL does not seem to have this
flexibility)

The mechanism which enables trust points to
be entered into the local security context is not internationally 
standardized to my knowledge, though X.509 tailored profiles for
speciifc 
environments,
such as SET and 1422, do specify their own mechanism for gaining the
knowledge 
of at
least one trust point (SET Root and IPRA). Just as there will be many
escrow 
solutions, there
should be many mechanisms for learning/hiding trust points which
instrument a 
local policy
of reliance on the control system facilitated by certs. And this is the
heart ot 
Tim's
question, I believe.

In other non 1422-like models, there is only one trust point of
consequence - 
the public 
key of the most local CA to a relying party, else a relying parties own
signing 
key
in the degenerate case.

By determining  a common point of trust, and merging a locally generated
partial
path, with a path truncated at the common trust point, a recipient
releases
no knowlege of the use of, or makes any assumption upon, any particular
public "root" - rather the public key used to begin a trust path
evaulation
is always highly localised, and cert chains are "constructed" to ensure
a 
complete
set of intermediate certs which validate the user cert to be relied on,
and for which local audit records are kept.

This process is fully disclosed in X.509 std. The aim is to learn (but
not 
necesarily
displose) common points of trust. (These may be subject to non-std
systems of 
local
policy acceptance when determining their acceptability for a given
purpose, and their utility in path formulation for a given 
sensitivity/criticality of
a given user cert validation and its use to enable the
protection service).

Unelss you consider the user CAs public key, else the users own signing
key, to be a "root", the notion of trust point is far more useful (and
X.509 
standard). The
VeriSign PCS plans for a classical 1422 root, as a means (in an
acntipcated
dynamic and changing, multi-common-trust-point finding environment)
of finding at least one path through the maze. Following establishment
of
some basic channel, parties can, over that channel, perform key
distirbution
for subsequent association, according to different rules which may not
be made
public.

For a competent discussion of this, see X.509. Im just someone who
implements
stds as best & as fully as I can; Im not someone who writes them! All
errors of understanding are mine own.

The nice thing about X.509 (in general case) is that I dont have to
disclose, as 
a recipient,
which trust chain I used in validating. Though a party may be able
to learn that I used a security service which relies upon his/her cert,
they may not be able to learn what trust path I relied upon (or had
knowledge
of the existance of) in my decision taking. This affects the balance of
power in court.

So,

When is a root not a root?. When its just a key, like any other.

When can I rely on a cert? when you have determined/used your trust
point
and any necessary common trust points necessary for path detemination
and evaluation of security, and at least one statement of issuing policy
for any cert in a chain, prior to reliance.

Peter.

--------------
Morton D. Hoffman     GTE Cybertrust          [email-masked]
(617) 455-2413           Fax (617) 455-3105

Priority: Normal
To: [email-masked]
From: Edward Russell <[email-masked]>
Sender: Edward Russell <[email-masked]>
Subject: RE: Self-signed root transport and CA expiration
Date: Wed, 20 Nov 1996 11:10:55 -0500
Status:   

Ned Smith ([email-masked]) said on 11/19/96

|||
|||Have you considered the possibility of including the issuer public key in
|||the subject's certificate? That way every certificate is a self-signed
|||cert.
|||Users(applications) that become reasonably familiar with any particular
|||public key - and therefore trust it implicitly could choose not to verify to
|||the root to obtain a self-signed cert.

To which Ed Russell replies

"Familiar with any particular public key" - How would I know whether it is
the public key I am familiar with other than comparing the key itself or
its fingerprint if you included that too with every CA public key I have 
in my local store (or the set I am "familiar" with).

Whether I check the signature of a certificate with a public key included in
that certificate or with the public key in a certificate accompanying the message,
I still have to make sure that the key claiming to be the CA key is in fact
the same key that I think is the CA key.

Once I have accomplished that I have to make sure the CA key is valid in the chain.
I either do that by chasing it to the root, or flagging it as one I am "familiar" with.
However the familiarity bit must be 1. secured from being flipped without my knowledge
and 2. periodically rechecked since higher level CA certs may expire (I guess they are 
still valid in that case anyway) or even put onto a CRL 
("Bribery Discovered at XYZ Cert Authority!!! - all certs suspect!")

Edward Russell
[email-masked]

From: Stefan Kelm <[email-masked]>
Date: Wed, 20 Nov 1996 14:37:34 +0100 (MET)
To: [email-masked]
Subject: Re: Re[2]: X.509 V3
Reply-To: [email-masked]
Status:   

> 
> although i don't think the connection to our server are very slow, i would agree
> that european access would be best done to a mirror site. i was unaware of the
> site mentioned below. however, i do have an agreement with the following site to
> mirror the contents of OSIdirectory (i am unsure the one mentioned below has the
> asn.1 for the v1 and v2 certificates)
> 
>   ftp://ftp.nameflow.dante.net/mirror/OSIdirectory
> 
>    hoyt

Sorry, Hoyt, but the connections from Germany to bull.com *are* very slow,
that's why I set up the mirror in the first place. As for the contents, we
copy the complete path (ftp://NC-17.MA02.Bull.com/pub/OSIdirectory/) once a
week (w/o an agreement, that is, which we do not need, anyway).

Greets,

	Stefan.

______________________________________________________________________________
Stefan Kelm <[email-masked]>                WWW: http://www.pca.dfn.de/~kelm/
DFN-PCA,  University of Hamburg, Vogt-Koelln-Str. 30,  22527 Hamburg (Germany)
                                 Phone: +49-40-54942262 / Fax: +49-40-54942241
             ["finger [email-masked]" to get my PGP key]

From: "Hoffman, Mort" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Self-signed root transport and CA expiration
Date: Wed, 20 Nov 1996 14:43:15 -0500
Encoding: 178 TEXT

Peter,

Sorry for responding so slowly, but you left me (and pkix) off your
to/cc list, and while I got your first message on pkix, I did not get
your latter message at all.

I am quite familiar with Web of Trust models, and there are certainly
applications where it is a serviceable and even desireable model.
However, there are other applications, many of them non-military, where
such a model is weak.  In particular, I consider the retail banking
model one such model.  If everyone individually decides who to trust
based on private criteria, then I'm not sure how disputes get resolved.
My suspicion is that it would be far more expensive, when MasterCard
needs to check out Joe's personal certificate generation program to
decide if it is willing to trust or challenge Mary's assertion that it
must be a good signature because Joe said so.

Indeed, the viability of the whole CA business may be based on this
problem!  Clearly, this is not to challenge the notion of multiple trust
points that X.509 so clearly includes in its model.  From my own
perspective, when there are a relatively small number of them, I would
characterize it as cross-certification rather than root-less.  If
Verisign asserts that it has no root, it seems to be suggesting that
its' certificates should only be trusted based on personal faith -- we
all have faith (of some sorts), but they tend not to be consistent
enough to each other to form the basis of commercial trust.

I guess the other part of the discussion pertained to the lack of root
certificate of the (pardon my personal description of the beast) Versign
root.  Do I understand you correctly that the reason is that X.509 would
make you have a certificate expiration date if you had a certificate, so
that you avoid the problem by avoiding the certificate?  Surely you
could issue a new certificate if you still liked the key ...  It only
need happen every few years.

Mort
----------------------------------------

Mort,

If you read the self-governing regulations for the VeriSign public
certification
services (CPS), you will notice the declaration of a "VeriSign Root" -
an 
authority
with a defined function, which serves to register public key of
*VeriSign* CAs, 
and which
outputs a package known as a self-signed public key (read the document
for
precise terminology). Said package exists for the purpose of conveying
a trust point (see X.509) for use in the context of administering
local security policy of systems which wish to validate user certs which
impelment some control system (MOA, key distribution, etc)

The transport vehicle used to convey trust points and assure their
authenticity 
when used in a validating system can be a Fortezza
card slot, else a EMV smartcard public key slot or EMV smarctard reader
trusted 
terminal.
Other proprietary techniques exist on a per token basis which may
not be be based on public key techniques. It may also be a Netscape
technique for learning trust points dynamically. Ask the vendor
of the local security policy enforcing MIB!

You and I differ on protocol-bound chain semantics for internet
protocols; I try
to best follow the X.509 std in that within a useful trust chain is a
trust 
point. It may
be at the top, it may be in the middle, it may be at the level of a user
certificate. it may
not even be present within the set of certs of which the party which
quotes a user cert is even aware of. Such knowledge may be hidden
for sensitivity reasons. In OSI and PEM protocols, the cert bag sent
to accompany a protected service may even allow for suggest selection of
multiple
common trust points by the receipient. (* SSL does not seem to have this
flexibility)

The mechanism which enables trust points to
be entered into the local security context is not internationally 
standardized to my knowledge, though X.509 tailored profiles for
speciifc 
environments,
such as SET and 1422, do specify their own mechanism for gaining the
knowledge 
of at
least one trust point (SET Root and IPRA). Just as there will be many
escrow 
solutions, there
should be many mechanisms for learning/hiding trust points which
instrument a 
local policy
of reliance on the control system facilitated by certs. And this is the
heart ot 
Tim's
question, I believe.

In other non 1422-like models, there is only one trust point of
consequence - 
the public 
key of the most local CA to a relying party, else a relying parties own
signing 
key
in the degenerate case.

By determining  a common point of trust, and merging a locally generated
partial
path, with a path truncated at the common trust point, a recipient
releases
no knowlege of the use of, or makes any assumption upon, any particular
public "root" - rather the public key used to begin a trust path
evaulation
is always highly localised, and cert chains are "constructed" to ensure
a 
complete
set of intermediate certs which validate the user cert to be relied on,
and for which local audit records are kept.

This process is fully disclosed in X.509 std. The aim is to learn (but
not 
necesarily
displose) common points of trust. (These may be subject to non-std
systems of 
local
policy acceptance when determining their acceptability for a given
purpose, and their utility in path formulation for a given 
sensitivity/criticality of
a given user cert validation and its use to enable the
protection service).

Unelss you consider the user CAs public key, else the users own signing
key, to be a "root", the notion of trust point is far more useful (and
X.509 
standard). The
VeriSign PCS plans for a classical 1422 root, as a means (in an
acntipcated
dynamic and changing, multi-common-trust-point finding environment)
of finding at least one path through the maze. Following establishment
of
some basic channel, parties can, over that channel, perform key
distirbution
for subsequent association, according to different rules which may not
be made
public.

For a competent discussion of this, see X.509. Im just someone who
implements
stds as best & as fully as I can; Im not someone who writes them! All
errors of understanding are mine own.

The nice thing about X.509 (in general case) is that I dont have to
disclose, as 
a recipient,
which trust chain I used in validating. Though a party may be able
to learn that I used a security service which relies upon his/her cert,
they may not be able to learn what trust path I relied upon (or had
knowledge
of the existance of) in my decision taking. This affects the balance of
power in court.

So,

When is a root not a root?. When its just a key, like any other.

When can I rely on a cert? when you have determined/used your trust
point
and any necessary common trust points necessary for path detemination
and evaluation of security, and at least one statement of issuing policy
for any cert in a chain, prior to reliance.

Peter.

--------------
Morton D. Hoffman     GTE Cybertrust          [email-masked]
(617) 455-2413           Fax (617) 455-3105

From: <[email-masked]>
Date: 20 Nov 96 12:53:02 (-0500)
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked]
Message-Type: Delivery Report

	messsage id:	<[email-masked]>
	subject:	Re: Re[2]: X.509 V3
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

Priority: Normal
To: [email-masked]
From: Edward Russell <[email-masked]>
Sender: Edward Russell <[email-masked]>
Subject: RE: Self-signed root transport and CA expiration
Date: Wed, 20 Nov 1996 11:10:55 -0500

Ned Smith ([email-masked]) said on 11/19/96

|||
|||Have you considered the possibility of including the issuer public key in
|||the subject's certificate? That way every certificate is a self-signed
|||cert.
|||Users(applications) that become reasonably familiar with any particular
|||public key - and therefore trust it implicitly could choose not to verify to
|||the root to obtain a self-signed cert.

To which Ed Russell replies

"Familiar with any particular public key" - How would I know whether it is
the public key I am familiar with other than comparing the key itself or
its fingerprint if you included that too with every CA public key I have 
in my local store (or the set I am "familiar" with).

Whether I check the signature of a certificate with a public key included in
that certificate or with the public key in a certificate accompanying the message,
I still have to make sure that the key claiming to be the CA key is in fact
the same key that I think is the CA key.

Once I have accomplished that I have to make sure the CA key is valid in the chain.
I either do that by chasing it to the root, or flagging it as one I am "familiar" with.
However the familiarity bit must be 1. secured from being flipped without my knowledge
and 2. periodically rechecked since higher level CA certs may expire (I guess they are 
still valid in that case anyway) or even put onto a CRL 
("Bribery Discovered at XYZ Cert Authority!!! - all certs suspect!")

Edward Russell
[email-masked]

From: Stefan Kelm <[email-masked]>
Date: Wed, 20 Nov 1996 14:37:34 +0100 (MET)
To: [email-masked]
Subject: Re: Re[2]: X.509 V3
Reply-To: [email-masked]

> 
> although i don't think the connection to our server are very slow, i would agree
> that european access would be best done to a mirror site. i was unaware of the
> site mentioned below. however, i do have an agreement with the following site to
> mirror the contents of OSIdirectory (i am unsure the one mentioned below has the
> asn.1 for the v1 and v2 certificates)
> 
>   ftp://ftp.nameflow.dante.net/mirror/OSIdirectory
> 
>    hoyt

Sorry, Hoyt, but the connections from Germany to bull.com *are* very slow,
that's why I set up the mirror in the first place. As for the contents, we
copy the complete path (ftp://NC-17.MA02.Bull.com/pub/OSIdirectory/) once a
week (w/o an agreement, that is, which we do not need, anyway).

Greets,

	Stefan.

______________________________________________________________________________
Stefan Kelm <[email-masked]>                WWW: http://www.pca.dfn.de/~kelm/
DFN-PCA,  University of Hamburg, Vogt-Koelln-Str. 30,  22527 Hamburg (Germany)
                                 Phone: +49-40-54942262 / Fax: +49-40-54942241
             ["finger [email-masked]" to get my PGP key]

From: "Marc Duplessis" <[email-masked]>
To: <[email-masked]>
Subject: unsubscribe
Date: Tue, 19 Nov 1996 21:20:29 -0500
Status:   

unsubscribe [email-masked]

Marc Duplessis, B.Ing., M.Sc.A.
Les Consultants Marc Duplessis Inc.
4205 Morisset
Laval, Quebec, Canada, H7R 1P7
email: [email-masked], [email-masked]

Date: Wed, 20 Nov 1996 21:02:30 +0900
To: [email-masked]
From: Jae-Chul Mun <[email-masked]>
Status:   

unsubscribe 

From: <[email-masked]>
Date: Wed, 20 Nov 1996 07:23:21 +0700
To: [email-masked]
Subject: UNSUBCRIBE
Status:   

unsubcribe [email-masked] [email-masked]

From: "Marc Duplessis" <[email-masked]>
To: <[email-masked]>
Subject: unsubscribe
Date: 	Tue, 19 Nov 1996 21:20:29 -0500

unsubscribe [email-masked]

Marc Duplessis, B.Ing., M.Sc.A.
Les Consultants Marc Duplessis Inc.
4205 Morisset
Laval, Quebec, Canada, H7R 1P7
email: [email-masked], [email-masked]

From: <[email-masked]>
Date: 19 Nov 96 21:12:10 (-0500)
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked], [email-masked]
Message-Type: Delivery Report

	messsage id:	<[email-masked]>
	subject:	Re[2]: X.509 V3
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

From: <[email-masked]>
Date: Tue, 19 Nov 96 14:29:06 MST
Encoding: 48 Text
To: [email-masked]
Subject: Re[2]: X.509 V3
Status:   

although i don't think the connection to our server are very slow, i would agree
that european access would be best done to a mirror site. i was unaware of the
site mentioned below. however, i do have an agreement with the following site to
mirror the contents of OSIdirectory (i am unsure the one mentioned below has the
asn.1 for the v1 and v2 certificates)

  ftp://ftp.nameflow.dante.net/mirror/OSIdirectory

   hoyt
_______________________________________________________________________________
Subject: Re: X.509 V3
From:    [email-masked] at AZ05-SMTP
Date:    11/19/96  3:15

Hi,

since Jochen is in Germany I'd recommend for him (and everyone else located
in Europe) to copy the files from our (german) mirror site:

 ftp://ftp.pca.dfn.de/pub/pca/documents/X509/

since the lines to bull.com are usually extremely slow.

Regards,

 Stefan.

______________________________________________________________________________
Stefan Kelm <[email-masked]>                WWW: http://www.pca.dfn.de/~kelm/
DFN-PCA,  University of Hamburg, Vogt-Koelln-Str. 30,  22527 Hamburg (Germany)
                                 Phone: +49-40-54942262 / Fax: +49-40-54942241
             ["finger [email-masked]" to get my PGP key]

[snip]

> Subject: X.509 V3
> From:    Jochen Keutel <[email-masked]> at AZ05-SMTP
> Date:    11/18/96  10:43
> 
> Hi,
>   could anybody please give me the description of a X.509 V3
> certificate and X.509 V3 revocation list? ASN.1 description would be
> sufficient; some explanation would be great.
>   Can I find this somewhere in the Web? I know that "normal" ISO/ITU
> standards are not available for free ...
> 
> Thanks,
>   Jochen.

Date: Tue, 19 Nov 1996 12:14:47 -0800
From: [email-masked] (Hao Ly)
Reply-To: [email-masked]
Organization: Netscape Communications
To: [email-masked]
Subject: subscri
Status:   

From: <[email-masked]>
Date: 19 Nov 96 17:12:54 (-0500)
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked]
Message-Type: Delivery Report
Status:   

	messsage id:	<[email-masked]>
	subject:	Re: X.509 V3
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

From: <[email-masked]>
Date: 19 Nov 96 19:42:22 (-0500)
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked], [email-masked]
Message-Type: Delivery Report

	messsage id:	<[email-masked]>
	subject:	Re[2]: X.509 V3
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

Date: Tue, 19 Nov 1996 16:22:29 -0800
To: Tim Dierks <[email-masked]>
From: Ned Smith <[email-masked]>
Subject: Re: Self-signed root transport and CA expiration
Cc: <[email-masked]>

At 04:02 PM 11/18/96 -0800, Tim Dierks wrote:
>
>The solutions seem pretty clumsy: either construct some heuristic to
>determine which key a certificate was issued with (based on validity times,
>perhaps), or require that validating applications iterate across potential
>issuers with identical names, attempting to verify the signature with each
>key (which would be very expensive).
>
> - Tim Dierks
>
>[Please forgive my submitting this to ssl-talk, smime-dev, and ietf-pkix]
>
>Tim Dierks - [email-masked] - www.consensus.com
>     Software Haruspex - Consensus Development
>  Developer of SSL Plus: SSL 3.0 Integration Suite

Have you considered the possibility of including the issuer public key in
the subject's certificate? That way every certificate is a self-signed cert.
Users(applications) that become reasonably familiar with any particular
public key - and therefore trust it implicitly could choose not to verify to
the root to obtain a self-signed cert.

Regards,
Ned Smith
Ned Smith~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Intel Architecture Labs  2111 N.E. 25th Ave.  Hillsboro, OR. 97124     
Ph: 503.264.2692 Fax: x1805  Email: mailto:[email-masked]   
http://www.intel.com/ial/security/index.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From: <[email-masked]>
Date: Wed, 20 Nov 1996 07:23:21 +0700
To: [email-masked]
Subject: UNSUBCRIBE

unsubcribe [email-masked] [email-masked]

Date: Wed, 20 Nov 1996 21:02:30 +0900
To: [email-masked]
From: Jae-Chul Mun <[email-masked]>

unsubscribe 

Date: Tue, 19 Nov 1996 11:13:06 -0800
To: [email-masked]
From: Tim Dierks <[email-masked]>
Subject: Re: Self-signed root transport and CA expiration
Cc: [email-masked]
Status:   

At 9:11 AM -0500 11/19/96, David P. Kemp wrote:

>> There's been some discussion recently on whether it is appropriate to
>> include self-signed root CA certificates in a certificate chain being sent
>> to support a particular certificate. (I've seen this both with respect to
>> S/MIME and SSL.) One point in support of sending roots, which I haven't
>> seen mentioned, is the question of resolving CA keys.
>
>
>Tim,
>  I'm missing something in the context of this question - what is the
>purpose of sending the root CA certificate?
>
>Since the receiver of the certificate chain must validate the 2nd
>(1 level down from root) cert with the root's securely-configured
>public key (i.e. not a putative root key received on-the-fly), what
>is the benefit of *ever* sending the root cert as part of a chain?
>
>In 1999 when the Verisign root expires, it's probably best to install
>the new root cert using the same procedure the old one was installed
>with in the first place (verifying fingerprints from a newspaper
>ad, physical transport, or whatever).  Anything else is just
>begging for trouble.
>
>        dpk

Clearly, the root needs to be verified against a trusted database which
contains trusted root certificates; the advantage of having it sent it is
that you are provided with an unambiguous statement as to exactly which key
a certificate has been signed with. The Distinguished Name in the issuer
field of a certificate is insufficient to specify the signing key. As
certificate authorities expire and roll over from old to new, there will be
a period of time when a received certificate may have been signed with the
old key or the new key. During this period (which may be indefinite,
depending on policy), the only way to check the signature is to try all
possible keys.

 - Tim

Tim Dierks - [email-masked] - www.consensus.com
     Software Haruspex - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

From: <[email-masked]>
Date: 19 Nov 96 17:12:54 (-0500)
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked]
Message-Type: Delivery Report

	messsage id:	<[email-masked]>
	subject:	Re: X.509 V3
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

From: "Hoffman, Mort" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Subject: RE: Self-signed root transport and CA expiration
Date: Tue, 19 Nov 1996 17:09:56 -0500
Encoding: 116 TEXT

Peter,

I confess to being a little confused.  It seems to me that at the top of
every certificate chain, there must be a certificate (unless the chain
is null).  Now, that certificate must be signed (or it is not a
certificate).  It can be signed either by its own key (the evil
self-signed key) or another key.  Leaving aside the possibility that
this other key is below the certificate in the chain, it could be signed
by a key above it.  Since no key above it has a certificate (by
definition) it must be a private key without a public certificate.  In
any event, I would contend that it is the root or the private key
associated with a self-signed certificate is the root.

Given this somewhat pedantic argument, I am left to conclude that you
mean that Verisign has not one root, but a multitude of roots for
different products and/or customers.  Or else you meant that you do not
have a root certificate (which would make sense in line with your
statement that the root cannot expire, although private keys can expire
separately from associated public keys, but probably not what you
meant).

In either of these interpretations, I don't understand how your comments
address the issues which you were responding to.  Perhaps there is
another interpretation I am not thinking of.  Could you clarify for me
so that I can understand the point you are making?

Thanks,

Mort

P. S. on the original question, I see self-signed root certificates as
providing integrity, and may make it easier for software to chase a
certificate chain (and identifying its end-point).  It also provides
identification data which may assist with authentication, although
certainly cannot provide authentication by itself.

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Tuesday, November 19, 1996 3:04 PM
>To: 	[email-masked]; [email-masked]
>Subject: 	RE: Self-signed root transport and CA expiration
>
>There is no VeriSign root. It cannot expire, therefore. We
>were very careful to stay out of the militeristic hierachy
>path; the danger of some govt hijacking it capabilities 
>were far too great.
>
>The people who want to operate grand-unified roots tend to have 
>big-brother or domination motives; often they seek some defense contractor to
>enforce big-brother on their behalf. 
>
>Ive realised possibly why the debate on formal naming has emerged -
>so DN and cert type technology can be used to instrument the
>dormant encryption capability, where a cert from both
>govts is required.
>
>Does anyone know if KEA enforcement is being used
>to join the two distinct control systems,
>and if capstone/keystone has been altered to
>faciliate this? It could be used in a variation of the LEAF
>technology, used for access to raw capability on
>th Fortezza card, versus data.
>
>In terms of PKIX profiling, is there now a mission to
>instrument this "non-internet-purposed" control sytems using
>the cert profile?
>
>Perhaps we need to ensure that subject DNs are NOT
>mandatory for conformance, to assure the public
>the internet stds are not simply being engineered to enable
>govt control systems (without open debate, and concensus, at
>least).
>
>(Personally speaking, I really dont want the IETF to be enabling some
>dictatorial govt to impose controls like this on dissenting people! Let <X>
>and <Y>
>et al enable apartheid-enforcing pass-book controls systems and
>the like; not the IETF!)
>
>
>----------
>From: 	David P. Kemp
>Sent: 	Tuesday, November 19, 1996 6:11 AM
>To: 	[email-masked]; [email-masked]
>Subject: 	Re: Self-signed root transport and CA expiration
>
>
>> There's been some discussion recently on whether it is appropriate to
>> include self-signed root CA certificates in a certificate chain being sent
>> to support a particular certificate. (I've seen this both with respect to
>> S/MIME and SSL.) One point in support of sending roots, which I haven't
>> seen mentioned, is the question of resolving CA keys.
>
>
>Tim,
>  I'm missing something in the context of this question - what is the
>purpose of sending the root CA certificate?
>
>Since the receiver of the certificate chain must validate the 2nd 
>(1 level down from root) cert with the root's securely-configured
>public key (i.e. not a putative root key received on-the-fly), what
>is the benefit of *ever* sending the root cert as part of a chain?
>
>In 1999 when the Verisign root expires, it's probably best to install
>the new root cert using the same procedure the old one was installed
>with in the first place (verifying fingerprints from a newspaper
>ad, physical transport, or whatever).  Anything else is just
>begging for trouble.
>
>        dpk
>
>
>
>
>
>

Date: Tue, 19 Nov 1996 17:03:47 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked]
Subject: RE: Self-signed root transport and CA expiration

> There is no VeriSign root. It cannot expire, therefore. We
> were very careful to stay out of the militeristic hierachy
> path; the danger of some govt hijacking it capabilities 
> were far too great.

I must be especially stupid today.  If VeriSign is not a "root",
then substitute for that term one of:

1. the certificate farthest from the the leaf in a certification path, or

2. one of the distinguished certificates pre-embedded into products
   like Navigator and IE, or

3. a certificate of the globally-well-known entity which Rivest's SDSI
   proposal refers to as "Verisign!!"

I know some people are offended by referring to Washington's football
team as the "Redskins"; if VeriSign is offended by being referred to
as a "root", then we will just have to find some other shorthand
term for the service it is selling.  What do you suggest?

Date: Tue, 19 Nov 1996 16:41:29 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked]
Subject: Re: Self-signed root transport and CA expiration

> 
> Clearly, the root needs to be verified against a trusted database which
> contains trusted root certificates; the advantage of having it sent it is
> that you are provided with an unambiguous statement as to exactly which key
> a certificate has been signed with. The Distinguished Name in the issuer
> field of a certificate is insufficient to specify the signing key. As
> certificate authorities expire and roll over from old to new, there will be
> a period of time when a received certificate may have been signed with the
> old key or the new key. During this period (which may be indefinite,
> depending on policy), the only way to check the signature is to try all
> possible keys.
> 
>  - Tim

Or send the root certificate's fingerprint instead of the full cert,
and match against the fingerprints of all the certs in the database.
Trying all possible keys at 100 ms each might be a problem in some
situations, but doing a memcmp against a list of 20 byte hashes
will be faster than against a list of 600 byte certs.

If one is designing a protocol, it makes sense to design it in such a
way as to preclude implementors from making mistakes.  If the full cert
is sent, somewhere someone's implementation is going to use it to
validate the chain without bothering with the database check.  Oops.

     dpk

From: [email-masked]
Date: Tue, 19 Nov 96 14:29:06 MST
Encoding: 48 Text
To: [email-masked]
Subject: Re[2]: X.509 V3

although i don't think the connection to our server are very slow, i would agree
that european access would be best done to a mirror site. i was unaware of the
site mentioned below. however, i do have an agreement with the following site to
mirror the contents of OSIdirectory (i am unsure the one mentioned below has the
asn.1 for the v1 and v2 certificates)

  ftp://ftp.nameflow.dante.net/mirror/OSIdirectory

   hoyt
_______________________________________________________________________________
Subject: Re: X.509 V3
From:    [email-masked] at AZ05-SMTP
Date:    11/19/96  3:15

Hi,

since Jochen is in Germany I'd recommend for him (and everyone else located
in Europe) to copy the files from our (german) mirror site:

 ftp://ftp.pca.dfn.de/pub/pca/documents/X509/

since the lines to bull.com are usually extremely slow.

Regards,

 Stefan.

______________________________________________________________________________
Stefan Kelm <[email-masked]>                WWW: http://www.pca.dfn.de/~kelm/
DFN-PCA,  University of Hamburg, Vogt-Koelln-Str. 30,  22527 Hamburg (Germany)
                                 Phone: +49-40-54942262 / Fax: +49-40-54942241
             ["finger [email-masked]" to get my PGP key]

[snip]

> Subject: X.509 V3
> From:    Jochen Keutel <[email-masked]> at AZ05-SMTP
> Date:    11/18/96  10:43
> 
> Hi,
>   could anybody please give me the description of a X.509 V3
> certificate and X.509 V3 revocation list? ASN.1 description would be
> sufficient; some explanation would be great.
>   Can I find this somewhere in the Web? I know that "normal" ISO/ITU
> standards are not available for free ...
> 
> Thanks,
>   Jochen.

From: Stefan Kelm <[email-masked]>
Date: Tue, 19 Nov 1996 09:25:58 +0100 (MET)
To: [email-masked]
Subject: Re: X.509 V3
Reply-To: [email-masked]
Status:   

Hi,

since Jochen is in Germany I'd recommend for him (and everyone else located
in Europe) to copy the files from our (german) mirror site:

	ftp://ftp.pca.dfn.de/pub/pca/documents/X509/

since the lines to bull.com are usually extremely slow.

Regards,

	Stefan.

______________________________________________________________________________
Stefan Kelm <[email-masked]>                WWW: http://www.pca.dfn.de/~kelm/
DFN-PCA,  University of Hamburg, Vogt-Koelln-Str. 30,  22527 Hamburg (Germany)
                                 Phone: +49-40-54942262 / Fax: +49-40-54942241
             ["finger [email-masked]" to get my PGP key]

[snip]

> Subject: X.509 V3
> From:    Jochen Keutel <[email-masked]> at AZ05-SMTP
> Date:    11/18/96  10:43
> 
> Hi,
>   could anybody please give me the description of a X.509 V3
> certificate and X.509 V3 revocation list? ASN.1 description would be
> sufficient; some explanation would be great.
>   Can I find this somewhere in the Web? I know that "normal" ISO/ITU
> standards are not available for free ...
> 
> Thanks,
>   Jochen.

Date: Tue, 19 Nov 1996 08:13:44 -0800
From: John Rovner <[email-masked]>
To: [email-masked]
Subject: unsubscribe
Status:   

unsubscribe

[email-masked]

Date: Tue, 19 Nov 1996 14:39:11 -0200
From: Ricardo Komatsu de Almeida <[email-masked]>
Reply-To: [email-masked]
Organization: Scopus Tecnologia S.A.
To: [email-masked]
Cc: [email-masked]
Subject: unsubscribe
Status:   

unsubscribe

Ricardo K. Almeida
Scopus Tecnologia S.A.
Sao Paulo, SP, Brazil

From: <[email-masked]>
Date: 19 Nov 96 04:31:33 (-0500)
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked]
Message-Type: Delivery Report
Status:   

	messsage id:	<[email-masked]>
	subject:	Re: X.509 V3
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

Date: Tue, 19 Nov 1996 12:14:47 -0800
From: [email-masked] (Hao Ly)
Reply-To: [email-masked]
Organization: Netscape Communications
To: [email-masked]
Subject: subscribe

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Self-signed root transport and CA expiration
Date: Tue, 19 Nov 1996 12:04:25 -0800

There is no VeriSign root. It cannot expire, therefore. We
were very careful to stay out of the militeristic hierachy
path; the danger of some govt hijacking it capabilities 
were far too great.

The people who want to operate grand-unified roots tend to have 
big-brother or domination motives; often they seek some defense contractor to
enforce big-brother on their behalf. 

Ive realised possibly why the debate on formal naming has emerged -
so DN and cert type technology can be used to instrument the
dormant encryption capability, where a cert from both
govts is required.

Does anyone know if KEA enforcement is being used
to join the two distinct control systems,
and if capstone/keystone has been altered to
faciliate this? It could be used in a variation of the LEAF
technology, used for access to raw capability on
th Fortezza card, versus data.

In terms of PKIX profiling, is there now a mission to
instrument this "non-internet-purposed" control sytems using
the cert profile?

Perhaps we need to ensure that subject DNs are NOT
mandatory for conformance, to assure the public
the internet stds are not simply being engineered to enable
govt control systems (without open debate, and concensus, at
least).

(Personally speaking, I really dont want the IETF to be enabling some
dictatorial govt to impose controls like this on dissenting people! Let <X> and <Y>
et al enable apartheid-enforcing pass-book controls systems and
the like; not the IETF!)

----------
From: 	David P. Kemp
Sent: 	Tuesday, November 19, 1996 6:11 AM
To: 	[email-masked]; [email-masked]
Subject: 	Re: Self-signed root transport and CA expiration

> There's been some discussion recently on whether it is appropriate to
> include self-signed root CA certificates in a certificate chain being sent
> to support a particular certificate. (I've seen this both with respect to
> S/MIME and SSL.) One point in support of sending roots, which I haven't
> seen mentioned, is the question of resolving CA keys.

Tim,
  I'm missing something in the context of this question - what is the
purpose of sending the root CA certificate?

Since the receiver of the certificate chain must validate the 2nd 
(1 level down from root) cert with the root's securely-configured
public key (i.e. not a putative root key received on-the-fly), what
is the benefit of *ever* sending the root cert as part of a chain?

In 1999 when the Verisign root expires, it's probably best to install
the new root cert using the same procedure the old one was installed
with in the first place (verifying fingerprints from a newspaper
ad, physical transport, or whatever).  Anything else is just
begging for trouble.

        dpk

Date: Tue, 19 Nov 1996 11:13:06 -0800
To: [email-masked]
From: Tim Dierks <[email-masked]>
Subject: Re: Self-signed root transport and CA expiration
Cc: [email-masked]

At 9:11 AM -0500 11/19/96, David P. Kemp wrote:

>> There's been some discussion recently on whether it is appropriate to
>> include self-signed root CA certificates in a certificate chain being sent
>> to support a particular certificate. (I've seen this both with respect to
>> S/MIME and SSL.) One point in support of sending roots, which I haven't
>> seen mentioned, is the question of resolving CA keys.
>
>
>Tim,
>  I'm missing something in the context of this question - what is the
>purpose of sending the root CA certificate?
>
>Since the receiver of the certificate chain must validate the 2nd
>(1 level down from root) cert with the root's securely-configured
>public key (i.e. not a putative root key received on-the-fly), what
>is the benefit of *ever* sending the root cert as part of a chain?
>
>In 1999 when the Verisign root expires, it's probably best to install
>the new root cert using the same procedure the old one was installed
>with in the first place (verifying fingerprints from a newspaper
>ad, physical transport, or whatever).  Anything else is just
>begging for trouble.
>
>        dpk

Clearly, the root needs to be verified against a trusted database which
contains trusted root certificates; the advantage of having it sent it is
that you are provided with an unambiguous statement as to exactly which key
a certificate has been signed with. The Distinguished Name in the issuer
field of a certificate is insufficient to specify the signing key. As
certificate authorities expire and roll over from old to new, there will be
a period of time when a received certificate may have been signed with the
old key or the new key. During this period (which may be indefinite,
depending on policy), the only way to check the signature is to try all
possible keys.

 - Tim

Tim Dierks - [email-masked] - www.consensus.com
     Software Haruspex - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

Date: Tue, 19 Nov 1996 08:13:44 -0800
From: John Rovner <[email-masked]>
To: [email-masked]
Subject:  unsubscribe

unsubscribe

[email-masked]

Date: Tue, 19 Nov 1996 14:39:11 -0200
From: Ricardo Komatsu de Almeida <[email-masked]>
Reply-To: [email-masked]
Organization: Scopus Tecnologia S.A.
To: [email-masked]
CC: [email-masked]
Subject: unsubscribe

unsubscribe

Ricardo K. Almeida
Scopus Tecnologia S.A.
Sao Paulo, SP, Brazil

Date: Tue, 19 Nov 1996 09:11:42 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked]
Subject: Re: Self-signed root transport and CA expiration

> There's been some discussion recently on whether it is appropriate to
> include self-signed root CA certificates in a certificate chain being sent
> to support a particular certificate. (I've seen this both with respect to
> S/MIME and SSL.) One point in support of sending roots, which I haven't
> seen mentioned, is the question of resolving CA keys.

Tim,
  I'm missing something in the context of this question - what is the
purpose of sending the root CA certificate?

Since the receiver of the certificate chain must validate the 2nd 
(1 level down from root) cert with the root's securely-configured
public key (i.e. not a putative root key received on-the-fly), what
is the benefit of *ever* sending the root cert as part of a chain?

In 1999 when the Verisign root expires, it's probably best to install
the new root cert using the same procedure the old one was installed
with in the first place (verifying fingerprints from a newspaper
ad, physical transport, or whatever).  Anything else is just
begging for trouble.

        dpk

From: <[email-masked]>
Date: 19 Nov 96 04:31:33 (-0500)
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked]
Message-Type: Delivery Report

	messsage id:	<[email-masked]>
	subject:	Re: X.509 V3
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

From: Stefan Kelm <[email-masked]>
Date: Tue, 19 Nov 1996 09:25:58 +0100 (MET)
To: [email-masked]
Subject: Re: X.509 V3
Reply-To: [email-masked]

Hi,

since Jochen is in Germany I'd recommend for him (and everyone else located
in Europe) to copy the files from our (german) mirror site:

	ftp://ftp.pca.dfn.de/pub/pca/documents/X509/

since the lines to bull.com are usually extremely slow.

Regards,

	Stefan.

______________________________________________________________________________
Stefan Kelm <[email-masked]>                WWW: http://www.pca.dfn.de/~kelm/
DFN-PCA,  University of Hamburg, Vogt-Koelln-Str. 30,  22527 Hamburg (Germany)
                                 Phone: +49-40-54942262 / Fax: +49-40-54942241
             ["finger [email-masked]" to get my PGP key]

[snip]

> Subject: X.509 V3
> From:    Jochen Keutel <[email-masked]> at AZ05-SMTP
> Date:    11/18/96  10:43
> 
> Hi,
>   could anybody please give me the description of a X.509 V3
> certificate and X.509 V3 revocation list? ASN.1 description would be
> sufficient; some explanation would be great.
>   Can I find this somewhere in the Web? I know that "normal" ISO/ITU
> standards are not available for free ...
> 
> Thanks,
>   Jochen.

Date: Mon, 18 Nov 1996 16:02:12 -0800
To: <[email-masked]>
From: Tim Dierks <[email-masked]>
Subject: Self-signed root transport and CA expiration
Status:   

There's been some discussion recently on whether it is appropriate to
include self-signed root CA certificates in a certificate chain being sent
to support a particular certificate. (I've seen this both with respect to
S/MIME and SSL.) One point in support of sending roots, which I haven't
seen mentioned, is the question of resolving CA keys.

Is it guaranteed that there is at most one key for a particular CA's
distinguished name? Given that key identifiers do not seem to be widely
used (for example, none of the Verisign root CAs have key identifiers),
this seems necessary. Given that fact, does this imply that when CA
certificates expire, the CA must choose to either generate the new CA with
a new distinguished name or to use the same key; there is no way to use the
same DN with a new key.

The solutions seem pretty clumsy: either construct some heuristic to
determine which key a certificate was issued with (based on validity times,
perhaps), or require that validating applications iterate across potential
issuers with identical names, attempting to verify the signature with each
key (which would be very expensive).

Of course, transporting root CAs with certificates would solve this
problem: it would provide a well-defined binding between the two
certificates (the fact that they were delivered together).

Given that the Verisign root CAs expire at the end of 1999, this problem
isn't indefinitely far away. You could have the same difficulties if a CA
key had to be replaced for some other reason (such as the private key being
destroyed in an accident).

 - Tim Dierks

[Please forgive my submitting this to ssl-talk, smime-dev, and ietf-pkix]

Tim Dierks - [email-masked] - www.consensus.com
     Software Haruspex - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

From: Jochen Keutel <[email-masked]>
Subject: X.509 V3
To: [email-masked]
Date: Mon, 18 Nov 1996 16:33:02 +0100 (MEZ)
Info: Evaluation version at ntdev.signet.org.au
Status:   

Hi,
  could anybody please give me the description of a X.509 V3
certificate and X.509 V3 revocation list? ASN.1 description would be
sufficient; some explanation would be great.
  Can I find this somewhere in the Web? I know that "normal" ISO/ITU
standards are not available for free ...

Thanks,
		Jochen.
------------

Dr. Jochen Keutel		currently at:	Deutsche Telekom	
duerr com-soft					IZ Darmstadt	

Phone: +49 6151 818 5525

e-mail: [email-masked]
	[email-masked]
X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
WWW   : http://www.geocities.com/WallStreet/3454/

From: <[email-masked]>
Date: Mon, 18 Nov 96 12:05:03 MST
Encoding: 35 Text
Original-Content-Type: text/plain
To: [email-masked]
Subject: Re: X.509 V3
Info: Evaluation version at ntdev.signet.org.au
Status:   

this is a work in progresss. i am building the 3rd edition text (incorporating
technical corrigenda and amendments at this very moment) for itu approval at
this moment. look online via anonymous ftp at nc-17.ma02.bull.com in /pub/
OSIdirectory. you will need to look at both the technical corrigenda and the
amendment text to get the definition of v3 and extensions. the base standard is
copyrighted so it is not availble electronically from me but can be acquired
from itu. however, in the 93 edition directory on the folder, you can find the
asn.1 (it is all of x.500 but you can find x.509 ans.1 within it)

   hoyt
_______________________________________________________________________________
Subject: X.509 V3
From:    Jochen Keutel <[email-masked]> at AZ05-SMTP
Date:    11/18/96  10:43

Hi,
  could anybody please give me the description of a X.509 V3
certificate and X.509 V3 revocation list? ASN.1 description would be
sufficient; some explanation would be great.
  Can I find this somewhere in the Web? I know that "normal" ISO/ITU
standards are not available for free ...

Thanks,
  Jochen.
------------

Dr. Jochen Keutel  currently at: Deutsche Telekom 
duerr com-soft     IZ Darmstadt 

Phone: +49 6151 818 5525

e-mail: [email-masked]
 [email-masked]
X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
WWW   : http://www.geocities.com/WallStreet/3454/

Date: Mon, 18 Nov 96 15:36:08 
From: "Housley, Russ" <[email-masked]>
Encoding: 522 Text
To: [email-masked]
Subject: PKIX Part 1 Plan
Status:   

All PKIX Participants:

The editors of Part 1 have been very busy since the last IETF meeting.  We 
simply have not had the time to make all of the updates that are needed.  
We are pushing to get them done before the next meeting in San Jose.  To 
make this happen, Tim Polk from NIST has offered his assistance.  However, 
we will probably miss the deadline for I-D distribution via the normal 
process.  So, we plan to e-mail the Part 1 text to this list about one week 
prior to the San Jose meeting.

Russ

From: <[email-masked]>
Date: Mon, 18 Nov 96 12:05:03 MST
Encoding: 35 Text
To: [email-masked]
Subject: Re: X.509 V3
Status:   

this is a work in progresss. i am building the 3rd edition text (incorporating
technical corrigenda and amendments at this very moment) for itu approval at
this moment. look online via anonymous ftp at nc-17.ma02.bull.com in /pub/
OSIdirectory. you will need to look at both the technical corrigenda and the
amendment text to get the definition of v3 and extensions. the base standard is
copyrighted so it is not availble electronically from me but can be acquired
from itu. however, in the 93 edition directory on the folder, you can find the
asn.1 (it is all of x.500 but you can find x.509 ans.1 within it)

   hoyt
_______________________________________________________________________________
Subject: X.509 V3
From:    Jochen Keutel <[email-masked]> at AZ05-SMTP
Date:    11/18/96  10:43

Hi,
  could anybody please give me the description of a X.509 V3
certificate and X.509 V3 revocation list? ASN.1 description would be
sufficient; some explanation would be great.
  Can I find this somewhere in the Web? I know that "normal" ISO/ITU
standards are not available for free ...

Thanks,
  Jochen.
------------

Dr. Jochen Keutel  currently at: Deutsche Telekom 
duerr com-soft     IZ Darmstadt 

Phone: +49 6151 818 5525

e-mail: [email-masked]
 [email-masked]
X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
WWW   : http://www.geocities.com/WallStreet/3454/

Date: Mon, 18 Nov 1996 16:02:12 -0800
To: <[email-masked]>
From: Tim Dierks <[email-masked]>
Subject: Self-signed root transport and CA expiration

There's been some discussion recently on whether it is appropriate to
include self-signed root CA certificates in a certificate chain being sent
to support a particular certificate. (I've seen this both with respect to
S/MIME and SSL.) One point in support of sending roots, which I haven't
seen mentioned, is the question of resolving CA keys.

Is it guaranteed that there is at most one key for a particular CA's
distinguished name? Given that key identifiers do not seem to be widely
used (for example, none of the Verisign root CAs have key identifiers),
this seems necessary. Given that fact, does this imply that when CA
certificates expire, the CA must choose to either generate the new CA with
a new distinguished name or to use the same key; there is no way to use the
same DN with a new key.

The solutions seem pretty clumsy: either construct some heuristic to
determine which key a certificate was issued with (based on validity times,
perhaps), or require that validating applications iterate across potential
issuers with identical names, attempting to verify the signature with each
key (which would be very expensive).

Of course, transporting root CAs with certificates would solve this
problem: it would provide a well-defined binding between the two
certificates (the fact that they were delivered together).

Given that the Verisign root CAs expire at the end of 1999, this problem
isn't indefinitely far away. You could have the same difficulties if a CA
key had to be replaced for some other reason (such as the private key being
destroyed in an accident).

 - Tim Dierks

[Please forgive my submitting this to ssl-talk, smime-dev, and ietf-pkix]

Tim Dierks - [email-masked] - www.consensus.com
     Software Haruspex - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

Date: Mon, 18 Nov 96 15:36:08 
From: "Housley, Russ" <[email-masked]>
Encoding: 522 Text
To: [email-masked]
Subject: PKIX Part 1 Plan

All PKIX Participants:

The editors of Part 1 have been very busy since the last IETF meeting.  We 
simply have not had the time to make all of the updates that are needed.  
We are pushing to get them done before the next meeting in San Jose.  To 
make this happen, Tim Polk from NIST has offered his assistance.  However, 
we will probably miss the deadline for I-D distribution via the normal 
process.  So, we plan to e-mail the Part 1 text to this list about one week 
prior to the San Jose meeting.

Russ

From: Jochen Keutel <[email-masked]>
Subject: X.509 V3
To: [email-masked]
Date: Mon, 18 Nov 1996 16:33:02 +0100 (MEZ)
Status:   

Hi,
  could anybody please give me the description of a X.509 V3
certificate and X.509 V3 revocation list? ASN.1 description would be
sufficient; some explanation would be great.
  Can I find this somewhere in the Web? I know that "normal" ISO/ITU
standards are not available for free ...

Thanks,
		Jochen.
------------

Dr. Jochen Keutel		currently at:	Deutsche Telekom	
duerr com-soft					IZ Darmstadt	

Phone: +49 6151 818 5525

e-mail: [email-masked]
	[email-masked]
X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
WWW   : http://www.geocities.com/WallStreet/3454/

From: [email-masked]
Date: Mon, 18 Nov 96 12:05:03 MST
Encoding: 35 Text
To: [email-masked]
Subject: Re: X.509 V3

this is a work in progresss. i am building the 3rd edition text (incorporating
technical corrigenda and amendments at this very moment) for itu approval at
this moment. look online via anonymous ftp at nc-17.ma02.bull.com in /pub/
OSIdirectory. you will need to look at both the technical corrigenda and the
amendment text to get the definition of v3 and extensions. the base standard is
copyrighted so it is not availble electronically from me but can be acquired
from itu. however, in the 93 edition directory on the folder, you can find the
asn.1 (it is all of x.500 but you can find x.509 ans.1 within it)

   hoyt
_______________________________________________________________________________
Subject: X.509 V3
From:    Jochen Keutel <[email-masked]> at AZ05-SMTP
Date:    11/18/96  10:43

Hi,
  could anybody please give me the description of a X.509 V3
certificate and X.509 V3 revocation list? ASN.1 description would be
sufficient; some explanation would be great.
  Can I find this somewhere in the Web? I know that "normal" ISO/ITU
standards are not available for free ...

Thanks,
  Jochen.
------------

Dr. Jochen Keutel  currently at: Deutsche Telekom 
duerr com-soft     IZ Darmstadt 

Phone: +49 6151 818 5525

e-mail: [email-masked]
 [email-masked]
X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
WWW   : http://www.geocities.com/WallStreet/3454/

To: IETF-Announce:;@tandem.com
cc: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-apki-00.txt
Date: Mon, 18 Nov 1996 09:51:51 -0500
Sender: [email-masked]

--NextPart

 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the Public-Key Infrastructure 
 (X.509) Working Group of the IETF.                                        

       Title     : Architecture for Public-Key Infrastructure              
       Author(s) : B. Blakley
       Filename  : draft-ietf-pkix-apki-00.txt
       Pages     : 43
       Date      : 11/15/1996

This document describes Requirements and an Architecture for Public-Key 
Infrastructure components, identifies which elements of the architecture 
should (in the opinion of the authors) be standardized, and identifies 
candidate interface and protocol specifications which might serve as base 
documents for the standardization effort.                                  

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-pkix-apki-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-apki-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-ietf-pkix-apki-00.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-apki-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-pkix-apki-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 18 Nov 1996 12:37:43 -0500 (EST)
To: Jochen Keutel <[email-masked]>
From: "Robert W. Shirey" <[email-masked]>
Subject: Re: X.509 V3
Cc: [email-masked]

At 4:33 PM +0100 11/18/96, Jochen Keutel wrote:
>Hi,
>  could anybody please give me the description of a X.509 V3
>certificate and X.509 V3 revocation list? ASN.1 description would be
>sufficient; some explanation would be great.
>  Can I find this somewhere in the Web? I know that "normal" ISO/ITU
>standards are not available for free ...
>
>Thanks,
>		Jochen.
>------------
>
>Dr. Jochen Keutel		currently at:	Deutsche Telekom
>duerr com-soft					IZ Darmstadt
>
>Phone: +49 6151 818 5525
>
>e-mail: [email-masked]
>	[email-masked]
>X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
>WWW   : http://www.geocities.com/WallStreet/3454/

Jochem,

I have the following in my files: I believe it  came from Peter Williams.

Regards, -Rob-

[email-masked],   Tel 703-284-4641,  Sec 284-4600,  Fax 284-4777
Robert W. Shirey,  BBN Corporation,  Mail Stop 30/4C, Suite 1200,
1300 North Seventeenth Street, Arlington, Virginia 22209-3801 USA

>For those that keep asking, here is X.509 v3 info pointers (again), and
>some related
>pointers about making good use of the spec.
>
>Migrate to ftp://ftp.bull.com/pub/OSIdirectory/ for v3 cert format,
>and the proposed ISO generic standard extensions to the Directory
>Authentication
>Framework.
>
>Perhaps consult the Certificates link for the TC1 to X.509 (which
>introduces v3 format and v2 format for CRLs) and the AM final text which
>introduces
>a collection of std extensions and related objects.
>
>For those who are implementing X.509, which assumes objects declared in
>other X.500 modules (which will not normally be seeking to implement, per se),
>ftp://ftp.bull.com/pub/OSIdirectory/93specification/93ASN.1/ contains
>a compilation source for all X.500 modules.
>
>There are at http://www.docs.uu.se/~hansh/Tau/offerings offerings for
>courses in ASN.1, pointers to products, and other network and system
>independent object-related IT products such as COM, CORBA, etc. with
>whicht construct ceritifcate-based security systems. There are also
>ready-made toolkits available from http://www.rsa.com for those
>who wish to simply add value to standard profiles implemented by
>a binary toolkit embracing IETF 1422 certs, and IETF 1421 compatible
>signed/encrypted objects. Im sure there are lots more vendors of such
>component ware....
>
>There is also ftp://ftp.bull.com/pub/OSIdirectory/93specification/ISP/
>link which shows how designers and integrators can formulate a
>context-specific profile
>of an ISO standard (such a X.509) and select the options and features
>one wants without changing the ASN.1 of the abstract syntaxes specifying
>the message formats many vendors use.
>
>This ISP documenting style is a path Ive sought to have several protocol
>users of
>X.509 take, instead of "basing" their work on X.509, and forcing vendors
>to support
>multiple encoders and decoders of all of the varieties. ASN.1 (as a
>specification tool, and as an implementation tool) is perfect for this
>purpose of overriding common syntaxes with environment-specific
>rules suitable for each real-world, profiled, environment. The synatxes
>are implmented once in a DLL, and the application then enforces
>aggregate rules concerning constraint checking (and any other rules)
>
>Id like to see the SET internet payment initiative perhaps *document* its
>use of X.509 is
>such a manner according to the ISP proforma, so that SSL & other vendors
>can maintain one code base for the syntax handling, yet for each URL
>protocol (https,
>https-set: etc), the profiling rules specific to the value handling can be
>enforced
>independently.
>
>There is probably still to much anti-ISO antagonism in the IETF & DARPA
>hierarchy to produce and adopt such a formal ISO format for documentation,
>but the
>essence of the style of the std profile might be used for the
>internet-centric *profile* of X.509
>being now (infact) documented by the PKIX WG (along with other workitems)
>
>However, for the secure message protocol MSP, one might wish to consult
>DOD-issued std profile documents which demosntrate how to accurately
>specify constraints and handling rules particular to a specified ASN.1
>security
>syntax and related facilites. perhaps consult
>http://www.xerox.com/xsis/dms/  and
>http://www.dms.loral.com/.
>
>Peter.
>
>
>----------
>From:
>Sent: 	Monday, August 19, 1996 6:32 PM
>To:
>Subject: 	Where is X.509v3?
>
>Can anyone point me to an on-line version of the version 3
>recommendations for X.509?
>
>Thanks!
>Content-Type: application/octet-stream; name="OSIDIR~1.URL"
>
>Attachment converted: Shirey's HD:OSIDIR~1.URL (????/----) (00008923)

From: <[email-masked]>
Date: Sat, 16 Nov 1996 17:41:10 -0500
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: More Euro Key Escrow

take me off this list

Date: Sat, 16 Nov 1996 20:59:14 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Apache Mailing List <[email-masked]>
Subject: Re: More Euro Key Escrow

> I've looked more closely at the "Royal Holloway" protocol, supposedly
> under consideration by the EC for key escrow in Europe, though I must say that
> anyone who deploys it will get what they deserve.

I've taken a personal look at this,  and it's awful.  I'd like to make a
formal submission from Thawte to the EC committee in charge.  Even better,
I'd like to muster industry support against escrow schemes in general in
the EC. If any organisations following this thread would like to join us
in that submission,  please contact me directly.

Thanks,
Mark

--
Mark Shuttleworth
Thawte Consulting

Subject: More Euro Key Escrow
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Apache Mailing List <[email-masked]>
Date: Sat, 16 Nov 1996 17:25:09 +0000 (GMT)
From: Ben Laurie <[email-masked]>
Reply-To: [email-masked]
Content-Length: 669       

I've looked more closely at the "Royal Holloway" protocol, supposedly
under consideration by the EC for key escrow in Europe, though I must say that
anyone who deploys it will get what they deserve.

I have discovered some further weaknesses in the protocol, documented
at:

http://www.algroup.co.uk/crypto/rh.html

Comments are welcome.

Cheers,

Ben.

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

From: Charles Moore <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: name stuff
Date: Sat, 16 Nov 1996 07:43:48 +1000

----------
From: 	Peter Williams[SMTP:[email-masked]]
Sent: 	Saturday, November 16, 1996 6:09 AM
To: 	'Charles Moore'
Cc: 	[email-masked]
Subject: 	RE: name stuff

Charles

We have been following actual practice in NSA's (MISSI's) DOD DMS
IOC activity, whereby separate DOD authorities - from those charged=20
with a duty to reliably issue and manage certs - are used for approving =
names,
which the DISA. emerging CPS-like certification system reliably binds to =
keying
material and other controls, having also performed authentication =
management. In that twisted
sentence lies the strict separation of NAs and CAs, and the
distinction between name registration, and authentication management - =
performed
by two entirely separate entities.

Have a look at their entity called the ORA and its functions, also the =
functional spec for the CAW.

But anyway, the authority for naming as per my last message, comes from =
a particular delegation (at least for DNs) the authority for =
certification comes from a particular set of delegations as well and =
these can be different as you suggest.=20

But the two MUST merge at the time of certification! i.e both =
delegations must be part of the CA policy even if in your example the =
two may be done seperately. The CA must NOT sign a certificate that does =
NOT have a registered DN NAME!

Within the Aus case the name registration will be requirement of the CA =
this being through Stanadards Australia; the responsibility to the CA as =
part of their registration, just as we have done with Object Identifiers =
(see our policy OIDs).

=20

If a corporate X.500/LDAP server already exists, and is considered =
robust
(and enforces some naming schema based on corporate objectives for =
naming,
which may or may not adopt the schema of any "global directory") then =
that DIT is
an adequate source of naming information to be used a CA; as,
the DIT, by definition, reflects the name assignments of whatever Naming =
authority(s)
constructed that DIT in the first place. An alternative scalable =
hierarchical name
form for PKI names is the non-textual OID system, which can
be both nationally organized, and/or internationally organized, =
according
to naming & privacy & interworking objectives.

A Directory can assist with name registration, but naming rules are =
required independent of any Directory implementations (they come first). =
Also registration of DNs can be done without a X.500 directory. The rule =
for DN and OIDs are covered under the same standards I mentioned, my =
perference is to have a DN rather than an OID for my identification.

-deleted
Where (and if) an organization needs to perform
both public and private name management and directory interworking, the
X.500 distributed service and replication protocol, and DIT aliasing =
facilites, provide
all the mapping features one wishes for that small set of
named entities in a corporation who conventionally  require both public =
and
private PKI names. The index navigation system seen by the public may
be quite different to that used authoiratively to organize the private =
domain's directory,
so as to maintain name domain privacy. (I dont want my entire empoyee =
listing
on the open network; Ill soon lose all my staff to my competitors!!)

Most X.500 naming rules cover these requirements; ref MP59.

This is no different to the IP layer in which IP address within the =
firewall

IP has a fixed set of global rules (i.e addr class structures) X.500 =
needs the same, the means of achieving them is via a system of =
delegation rather than a single global set.

-deleted
A std & conforming CA is one which implements the features of a ratified =
std
(e.g. X.509). A propreitary CA is one which bases is core features on =
some
local feature set which is perhaps only "based" on a standards. This =
distinction
does not mean that a std CA cannot offer additional features, =
optionally,
over and above std services.
X.509 is not a standard for CAs, there are may standards that a =
"conforming" CA will need to address, this is the issue that most people =
are working on finalising, with its dependence on the "legal and social" =
requirements.

Unless someone can indicate how, VeriSign's use of the technology is=20
(or at least seeks to be) entirely conformant to the std X.509 (**), and =
thus

As above; this alone does not make you a conforming CA, you will also =
need to address things like stds for DN name registration ( at least in =
Aus, I am not sure of the USA requirements, but believe they follow the =
International ageements in this area). The PKIX needs to support =
International Certification as well as the US.

-deleted

From: Peter Williams <[email-masked]>
To: "'Charles Moore'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: name stuff
Date: Fri, 15 Nov 1996 13:26:49 -0800

It may not have been clear from my last mail, but we are
in violent disagreement. there is no technical std requirement that
a DN  "follow whatever international and national registration =
requirements to
support uniqueness".=20

A profile of a techncial std for a given environment and purpose, may
well impose such additional rules. Each management domains can
decide which profiles it chooses to support/enforce according to need. =
Each private
management domain can choose whether it (privately) connects to other
PMDMDs supporting compatible profiles, else an ADDMD=20
which mandates some particular DN profile in a shared "public" space.
There is no reason to believe there be just one ADDMD schema
in the world.

A competent piece of technology implementing DNs and naming
policy and management domains will be able to enforce multiple profiles
selected by the operating organization. There is very rarely one "right =
way"
in the Internet environment.

This *absolute* DN uniqueness things is a red herring, like
the recent absolute validity matter. Non-ambiguity is the only=20
requirement, IMHO, enforced within the certification domain delimited by
the prevailing CPS disclosure statement for that domain.

----------
From: 	Charles Moore
Sent: 	Friday, November 15, 1996 5:04 AM
To: 	'Peter Williams'
Cc: 	[email-masked]
Subject: 	name stuff

 >Those DNs which are used in certs are not technically
required to conform to any given global schema, or any
schema at all, in fact.

Cert DNs are just DNs and are required to follow whatever international =
and national registration requirements to support uniqueness (refer to =
ISO 9834 series). The normal means of achieving this is to specify =
structure rules, that effectively define the=20
DIT structure. Examples are given within MP59.

From: Peter Williams <[email-masked]>
To: "'Charles Moore'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: name stuff
Date: Fri, 15 Nov 1996 12:09:15 -0800

Charles

We have been following actual practice in NSA's (MISSI's) DOD DMS
IOC activity, whereby separate DOD authorities - from those charged=20
with a duty to reliably issue and manage certs - are used for approving =
names,
which the DISA. emerging CPS-like certification system reliably binds to =
keying
material and other controls, having also performed authentication =
management. In that twisted
sentence lies the strict separation of NAs and CAs, and the
distinction between name registration, and authentication management - =
performed
by two entirely separate entities.

If a corporate X.500/LDAP server already exists, and is considered =
robust
(and enforces some naming schema based on corporate objectives for =
naming,
which may or may not adopt the schema of any "global directory") then =
that DIT is
an adequate source of naming information to be used a CA; as,
the DIT, by definition, reflects the name assignments of whatever Naming =
authority(s)
constructed that DIT in the first place. An alternative scalable =
hierarchical name
form for PKI names is the non-textual OID system, which can
be both nationally organized, and/or internationally organized, =
according
to naming & privacy & interworking objectives.

In X.500, it is perfectly reasonable to run disconnected DITs in
private management domains, where the scope of name use is limited to =
the
corporate network, and is used to protect information within that =
security enclosure
and enforce seperation of knowledge of names.=20

Where (and if) an organization needs to perform
both public and private name management and directory interworking, the
X.500 distributed service and replication protocol, and DIT aliasing =
facilites, provide
all the mapping features one wishes for that small set of
named entities in a corporation who conventionally  require both public =
and
private PKI names. The index navigation system seen by the public may
be quite different to that used authoiratively to organize the private =
domain's directory,
so as to maintain name domain privacy. (I dont want my entire empoyee =
listing
on the open network; Ill soon lose all my staff to my competitors!!)

This is no different to the IP layer in which IP address within the =
firewall
can use non-internic registered domains and DNS names, which in
fact may well collide with global registered names. Given
a separation between public networking and private networking
by a conventional firewall packet-level security policy this is entirely
harmless (except if you are using not-so-trustworthy java applets!....) =
in terms
of management coordination. It furthermore ensures naming privacy, and =
ensure that=20
registration activities or dynamics are not necessarily made public for =
analysis by
commercial and marketeering intelligence gatherers.

A std & conforming CA is one which implements the features of a ratified =
std
(e.g. X.509). A propreitary CA is one which bases is core features on =
some
local feature set which is perhaps only "based" on a standards. This =
distinction
does not mean that a std CA cannot offer additional features, =
optionally,
over and above std services.

Unless someone can indicate how, VeriSign's use of the technology is=20
(or at least seeks to be) entirely conformant to the std X.509 (**), and =
thus
facilitates the use of its services in any
of the modes and models and manners described by the std. It
is not restricted to any one model/mode/manner, and hopefully
benefits no vendor or propretiary sytems over those who
produce conformant std systems.. This is the benefit of a policy of
conformance to all users.

I like the PKIX documents as they are, as they do not interfere
with the oriignal modes/models/manners options of X.500. I=20
see a tendency for particular modes/manners/models solutions being =
pushed as
the "std", when they are actually merely profiles. I just
dont expect an internet CA to function as a ntional CA, or as a public =
CA, or
as a EDI CA. EAch of these need the flexilbiy of models in X.500
naming, nad PKIX based profile, to ensure they
can model the particular environments. Insisting *all* names
begin with c=3DFoo is just not on.

(**) Warwick Ford suggests that the X.509 AM *Is* now ratified (by ISO) =
and
thus confoming systems should be using it. Im worried still, that
we need the formal ITU- ratification. I know its a rubber stamp,
but I still like to see it stamped before making a formal
cliam of conformance (having ensure we are using all the latest =
definitions!)

If there is a sense that collectively we can
all take the risk  of an ITU yes response, and move up actual
products and service to the
AM now, then perhaps lets do it. Any opinions? This
is entirely a community issue, not a competitive issue.

=20
----------
From: 	Charles Moore
Sent: 	Friday, November 15, 1996 5:04 AM
To: 	'Peter Williams'
Cc: 	[email-masked]
Subject: 	name stuff

----------
From: 	Peter Williams[SMTP:[email-masked]]
Sent: 	Friday, November 15, 1996 10:29 AM
To: 	'Bob Jueneman'
Cc: 	[email-masked]
Subject: 	RE: Storage of X.509 certificates in X.500 -Reply

Bob,

A std CA does not enforce a naming schema; it merely performs
          ^^^
authentication management, and reliably issues and manages certs.

Naming and the associated name registration procedures, should be apart =
of a "std" CA policy.

In public services, VeriSign uses public naming authorities
from both the internet realm (NICs, and ISP mailbox registration
services), regulated sources of consumer credit data, and
official sources (including, but no limited to, business
licensing and registration agencies).

The naming rules for DNs within Australia are covered by a Standards =
Australia Publication MP59, I would expect that NIST
would have a simular publication for DNs within the USA?

>Those DNs which are used in certs are not technically
required to conform to any given global schema, or any
schema at all, in fact.

Cert DNs are just DNs and are required to follow whatever international =
and national registration requirements to support uniqueness (refer to =
ISO 9834 series). The normal means of achieving this is to specify =
structure rules, that effectively define the=20
DIT structure. Examples are given within MP59.

True enough, and despite requests to you and Michael Baum of
VeriSign, (and to GTE CyberTrust as well) I haven't even been=20
able to find out what schemas CAs such as yourselves
in fact support or plan to support. That of course makes it=20
more difficult for software vendors to determine how to display
in information contained within the certificate. Assuming that
you put information into a certificate in order to inform the potential=20
users, it would be helpful  if you would publish that information.

I am not aware of how the above use DNs, but would assume they are aware =
of the above requirements, which should meet your needs in part. It=20

From: Charles Moore <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: name stuff
Date: Fri, 15 Nov 1996 23:04:30 +1000

----------
From: 	Peter Williams[SMTP:[email-masked]]
Sent: 	Friday, November 15, 1996 10:29 AM
To: 	'Bob Jueneman'
Cc: 	[email-masked]
Subject: 	RE: Storage of X.509 certificates in X.500 -Reply

Bob,

A std CA does not enforce a naming schema; it merely performs
          ^^^
authentication management, and reliably issues and manages certs.

Naming and the associated name registration procedures, should be apart =
of a "std" CA policy.

In public services, VeriSign uses public naming authorities
from both the internet realm (NICs, and ISP mailbox registration
services), regulated sources of consumer credit data, and
official sources (including, but no limited to, business
licensing and registration agencies).

The naming rules for DNs within Australia are covered by a Standards =
Australia Publication MP59, I would expect that NIST
would have a simular publication for DNs within the USA?

>Those DNs which are used in certs are not technically
required to conform to any given global schema, or any
schema at all, in fact.

Cert DNs are just DNs and are required to follow whatever international =
and national registration requirements to support uniqueness (refer to =
ISO 9834 series). The normal means of achieving this is to specify =
structure rules, that effectively define the=20
DIT structure. Examples are given within MP59.

True enough, and despite requests to you and Michael Baum of
VeriSign, (and to GTE CyberTrust as well) I haven't even been=20
able to find out what schemas CAs such as yourselves
in fact support or plan to support. That of course makes it=20
more difficult for software vendors to determine how to display
in information contained within the certificate. Assuming that
you put information into a certificate in order to inform the potential=20
users, it would be helpful  if you would publish that information.

I am not aware of how the above use DNs, but would assume they are aware =
of the above requirements, which should meet your needs in part. It =

From: Peter Williams <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Storage of X.509 certificates in X.500 -Reply
Date: Thu, 14 Nov 1996 16:29:38 -0800

Bob,

A std CA does not enforce a naming schema; it merely performs
authentication management, and reliably issues and manages certs.
A cert is identified by the concatenation of issuer name, and
serial number.

It can pass certs to a cert distribution service on behalf
of the subscriber as a value-added service. 

In public services, VeriSign uses public naming authorities
from both the internet realm (NICs, and ISP mailbox registration
services), regulated sources of consumer credit data, and
official sources (including, but no limited to, business
licensing and registration agencies).

Private services....are private, as a name tend to be sensitive
information.

I wouldnt look to CA to sort out your Directory naming problem.
The global directory has not emerged without cert attributes;
addition of certs is not technically going to help solve
whatever is has been holding the global directory back.
Its interesting to note that the SET protocol
makes no use of a directory.

IN terms of PKIX documents, I cannot see any basis
that this line of directory and naming  comment should induce
change in the contents of the specs.

 Peter.

>Those DNs which are used in certs are not technically
required to conform to any given global schema, or any
schema at all, in fact.

True enough, and despite requests to you and Michael Baum of
VeriSign, (and to GTE CyberTrust as well) I haven't even been 
able to find out what schemas CAs such as yourselves
in fact support or plan to support. That of course makes it 
more difficult for software vendors to determine how to display
in information contained within the certificate. Assuming that
you put information into a certificate in order to inform the potential 
users, it would be helpful  if you would publish that information.

Date: Wed, 13 Nov 1996 12:59:25 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Storage of X.509 certificates in X.500 -Reply -Reply
Status:   

David, somehow my rules processor filed a number of messages before 
I had a chance to open them, so I'm just catching up with some from 
several days ago.

>> When I was involved in the NADF, there was one fundamental
> principle that came out -- regardless of the niceties of what 
> someone thinks a name ought to mean or imply, you list 
> information in a directory where users will tend to look for
> it. So if you are the Hotel View Zahrzeiten in Munich, and you
> wish to attract tourists from the US and Japan, in addition to Europe,
> you will probably want to list in the New York, Washington, Miami,
> Los Angeles, Tokyo, etc., directories, in addition to listing in
> Germany/Deutschland.

>Sorry Bob,
I just dont buy into your listing model if there is a global 
directory service. If there is a global directory, and I want to find 
details of hotels in Munich, then I would search the Munich part of 
the directory, not my local directory. Your (or should I say the defunct
 NADF) model leads to far too much 
data duplication - where and when do you stop adding listings for 
Munich hotels? Do you put them in every locality of the world? And 
imagine if every hotel in the world wanted to do the same thing! The 
data size would grow exponentially.
However, I do accept that if there are disconnected directories, then 
a hotel may want to have a listing in each directory. But your 
original premise was for a global directory. (I believe that in 
practice there are going to be hundreds of disconnected private 
directories with perhaps only  a handful of public global 
directories, so that a hotel may want a single listing in each 
disconnected directory )
David

I may have overstated the case, in trying to provide a general rule.
My example was better suited to a yellow pages application than
a traditional white pages directory. And I probably overstated the 
case with respect to the Utah repository -- it will presumably
be global in the sense that any subscriber in the world can access it,
and/or have his certificate posted into it (but probably for a fee, which
is a subject that X.500 doesn't adequately address.) But I didn't mean to 
infer that their repository will be directly interconnected with every other
X.500 directory -- certainly not yet. Where we (and the industry, I believe)
are at the moment is the archipelago model of the world. Individual islands
of directory services are popping up, and (to use a Novell NDS term), will
soon begin to federate on a bilateral agreement basis. Ultimately, whole
contents may arise from the see -- hopefully it won't require geological time
to accomplish this.

But the major point that I was trying to make was that if you 
expect your certificate to be found using your traditional geopolitical
DN (c=US, o=Novell, ou="Internet Infrastructure Division", cn="Robert
R. Jueneman"), then that is where you should file your certificate.

And if you expect users to be able to find your certificate knowing only
your e-mail address ([email-masked]), you had best file at least
a pointer to your certificate at that address as well. In X.500 terminology
that second address is still a distinguished name, although the anti-X.500
folks might not recognize it as such.

> If this principle is followed, certificates and other information may 
> be listed in many different locations, perhaps as alias or seeAlsos,
> or maybe just duplicate entries.
Bob
We need to get a more precise understanding of the term listing, 
because in my opinion alias and seeAlsos are not listings but 
pointers to listings. The Entries being pointed to, holding the 
attributes you want, are the listings.
David

It seems to me that it is up to the individual directory administrator
to decide whether to replicate an entry to permit accessing it
via a second name form, or whether to use an alias or seeAlso.
The pros and cons certainly aren't clear to me in the abstract, but
particular implementations may lend themselves better to one form 
than another.  Of course the rub comes when individual directories 
start to be hooked together, and these kinds of decisions have to 
be made in concert with all other directory administrators. Whether
such decisions will be implementable in the absence of a national
monopoly administration is TBD.

> 
> So in general, the relationship between directory entries and 
> certificates is probably many to many. That is, the same 
> certificate may be listed under quite a few different names,
Bob,
It depends upon what your are calling a name here. The name (or 
names) to public key binding held in the certificate is static. You 
cannot dynamically alter these names without invalidating the signature 
on the certificate. But the names of the locations in which the 
certificates are held can be changed dynamically. I presume that 
these are the names you are referring to. But, if we have a global 
directory, with good search capabilities, again the certificate need 
only be held in one place in order for it to be found. Alias pointers 
etc can also help in the search (except that early Paradise 
experiments recommended that aliased are NOT searched). Furthermore, data 
consistency suggests that you do not duplicate a corticate in the 
directory.

I agree, at least in part.  It is perhaps unfortunate that the field in a v1
certificate was called the Distinguished Name, since in fact there 
was no mechanism to ensure that it was distinguished, or had 
any correspondence to an entry in a directory.

So what I meant to say was that a given directory entry may contain 
multiple certificates, some having the same certificate entity name (AKA
certificate DN and/or subjectAlternateName) and differing only in the 
keyUsage, algorithm, or other fields. It isn't as clear, but I might have 
other certificates filed under a common directory DN for convenience, 
one having a traditional DN, one having my e-mail address, another having 
a DN plus a role name or title, etc. It just isn't clear to me what the best way
of organizing these different pieces of data is.  Should we collect together
everything that represents or has something to do with "me", or should
every different instance of "me" have a different name?  (I would assume
that certificates which have the same entity name but differ in the technical 
contents would be lumped together, but someone else might decide that 
they should put all of the DMS certificates in one place, all of the SET 
certificates in another, etc. Who can predict which organization will be "best",
without defining what the measurement criteria should be? I wouldn't
even attempt it, much less offer dogmatic statements to the effect that 
God intended that directories should be organized according to the 
author's specifications. (I'm not throwing rocks at you, but some people
have offered suggestions that seem overly simplistic -- In My Humble 
(but correct :-) Opinion, of course.)

>What we are suggesting in the ICE-TEL project is that a certificate 
can be retrieved by a variety of mechanisms e.g. FTP, email, WWW or 
X.500, but I would not recommend that a certificate be duplicated 
within a given X.500 service (other than by standard replication).
David

Well, that should provide a useful and interesting data point as to the
ease of use vs. administrative inconvenience. People I have talked
to who are more knowledgeable than I have suggested that storage 
is relatively cheap, but directory maintenance is relatively expensive.
So it isn't obvious whether certificate duplication under different names
would be better or worse than maintaining aliases and seeAlso lists.
What does seem obvious, given all of the sometimes rancorous discussion
of DNs vs. e-mail addresses, is that imposing a Procrustean solution of
one-entity, one entity-name, one-certificate is probably not going to 
satisfy the user community which wants to use the directory to find things
quickly and easily.

> in order to increase the probably that a user will find it. On the 
> other hand, a single entry may contain multiple certificates,
> including different algorithms, different key usages, and different
> roles or names, including multiple e-mail names or machine names.
> 
> Regardless of the virtues or lack thereof of a Distinguished Name
> for unambiguous identification, including the subject's DN in a 
> certificate at least provides one obvious way to find that certificate, 
> and to associate it with other information about the subject if you 
> don't have any other.
> 
> But this is almost surely not going to be sufficient, especially if as 
> expected the community makes extensive use of the 
> alternateSubjectName attribute.  If all you know about someone is their
> e-mail address, then that is where you should expect to find his 
> certificate, whether it is an RFC822 or X.400 address, or perhaps
> a proprietary format. Likewise, if all you know is someone's EDI number,
> that's where you should look in the directory.

>No I disagree with this. The alternate names suggest an alternative 
mechanism (i.e. application) to be used to retrieve the certificate 
i.e. you send email to the RFC822 address to get the certificate. It 
does not mean that there is a entry in X.500 with that RFC 822 
address as its DN.

Well, that's what makes horse races so interesting. I'm not inclined to 
reinvent X.500 every time someone comes up with a new application 
or naming strategy, but I won't get in your way if you choose to. It 
does seem to me, however, that once you get past the e-mail address 
paradigm and start worrying about health claim IDs, DUNS numbers, 
etc., that you may want to reconsider.
> 
> So as a minimum I would expect to find a primary entry under the 
> subject's DN as listed in the certificate, and at least an alias under
> each of the various alternate names.  Then you have to consider 
> how the user might expect to be found, and put additional entries there
> as well, whether the DN of the entry agrees with the DN in the
> subject's certificate or not.
> 
I'll stick to my original suggestion, but will look with interest at other forms
of directory services that might be proposed. .Exactly what we will do 
regarding a recommended schema within the Utah repository is not yet 
clear, nor is the best approach to use within Novell's own Novell 
Directory Service entirely obvious.

(BTW, some people might be interested to learn that Novell recently 
signed a deal with Sun which cross-licenses Sun's Java technology
and Novell's NDS technology. Beginning in 1997, Sun will include a copy
of NDS with every copy of Solaris. Novell will also be shipping a version 
of NDS which runs on Windows NT, and deals are pending but not yet 
announced with other major hardware and software manufacturers.
Things are going to start to get more and more interesting!)

Bob

From: <[email-masked]>
Date: 13 Nov 96 14:14
To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: unsubscribe
Encoding: 1 TEXT
Info: Evaluation version at ntdev.signet.org.au
Original-Content-Type: text/plain
Status:   

unsubscribe

Date: Wed, 13 Nov 1996 14:35:26 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: Storage of X.509 certificates in X.500 -Reply

>>> Peter Williams <[email-masked]> 11/11/96 12:56pm >>>
>Both Novell and Entrust seem to be hinging the
future of a Internet PKI on a high-quality global directory, and are
engineering things to make such a directory possible
in practice. This seems a very dubious thing to do,
unless you are a manufacturer or provider of directories
with a vested interest!

Peter, I'm occasionally bemused by your ability to prognosticate 
about other company's plans and directions, and then comment
adversely on the wisdom of the approach which you have just
attributed to them.

I wouldn't dare speculate on Nortel's plans in this area 
(at least as far as I know, Entrust is the name of a product,
not an organization), but I do know something of Novell's plans.

<Advertisement On>
Of course, as the world's largest provider of directory services,
with some 17 million users of Novell Directory Services at present,
we certainly have a vested interest in directories. By 1997,
when Sun starts shipping copies of NDS with every copy of 
Solaris, when Windows NT users start making use of NDS, and 
when other as yet unannounced deals with major hardware and 
software vendors come to fruition, I'm quite sure that those numbers
will become even more substantial. 
<Advertisement Off>

Novell is also one of the world's largest users of public key 
technology, with on the order of 55 million users of NetWare
using RSA public keys to authenticate their access every day. To
date, that public key technology has not made use of X.509 
certificates but rather used a proprietary format, in part
because of the now well-recognized deficiencies in X.509 v1.

But that is now changing, and we certainly expect that directories
will play a very substantial role in the dissemination of X.509 v3 
certificates and CRLs (as well as other elements of a PKI) in the 
very near future.

But I would disagree with your conclusion that we are 
"hinging" the development of a PKI on the use of directories,
whether high-quality or global or not. Even if we wanted to, 
I'm not sure that we or even the federal government could
make the deployment of a PKI contingent on the use of a 
directory. If it happens, all the better from our point of view,
but we are not so arrogant as to assume that if directories 
are not involved, a PKI cannot be deployed successfully.

>PKI itself is not pre-conditioned on a global directory.

I would agree, although I'm not quite sure where the tablets 
of stone are located that define precisely what the "PKI"
is at any given moment. 

>PKI names furthermore need not be X.500 DNs.

If by "PKI names" you mean the Distinguished Name that is
contained in an X.509 certificate I would agree with you,
although that of course is NOT the way that they are defined
within X.509 itself. If you are talking about names contained in
alternateSubjectNames I would agree with fewer reservations,
except when the alternatesubjectName is defined to be a DN!

>Those DNs which are used in certs are not technically
required to conform to any given global schema, or any
schema at all, in fact.

True enough, and despite requests to you and Michael Baum of
VeriSign, (and to GTE CyberTrust as well) I haven't even been 
able to find out what schemas CAs such as yourselves
in fact support or plan to support. That of course makes it 
more difficult for software vendors to determine how to display
in information contained within the certificate. Assuming that
you put information into a certificate in order to inform the potential 
users, it would be helpful  if you would publish that information.

My original point, however, which was contained in a reply to a 
gentleman who asked how to file a certificate in a directory,
was that when it comes time to store a certificate in a database of 
almost any kind, and especially in a directory that is more or less
like X.500, there must and will be agreement on the schema that is used
to provide an index into that database, or you will have chaos (or
almost unlimited search times, which are just as bad.)

So although the IETF consistently ducked this issue during the 
development of PEM, and although there is not yet a consensus or 
even published information regarding their de facto schema(s)
available from the major CAs, it will be the directory administrators
that will be forced to decide what schemas will be supported
in their directories. The directory vendors will follow their (customer's)
lead, of course, although we may be forced to make some interim
decisions as to what kind of basic capabilities to provide.

This is not intended to be viewed as a threat, nor am I trying to
suggest that people would be unreasonable. But if you want to 
include a JPEG image of you and your dog within the 
alternateSubjectName attribute, even though that is not prohibited by
any existing technical rules, you shouldn't be surprised if you
don't get much sympathy from your corporate directory administrator,
much less from some kind of a global directory management structure.

>IN an Internet environment which we are
here involved in (versus a private UTAH environment say)
the management system control of names to instrument
a global directory is fraught with problems. Use
of directory service from bottom up (WWW, LDAP, etc) is a very good thing
however, and over time, one can expect harmonization of
actual schemas for entries, and possibly the contents
of names of certs (where Internet certs use X.500 name forms)

Well, now I'm confused. I thought that you were saying that 
a high-quality global directory was a very dubious idea, unless 
you were one of the co-conspirators with those nasty vested 
interests. Is it the notion of a high-quality directory you are 
objecting to, or a global directory per se (of the type the EMA is 
trying to demonstrate, and to which the Internet White pages effort is
also aligned), or a X.500 DUA/DSA access mechanism as 
opposed to WWW or LDAP, or just what?

If all that you are saying is that getting agreement on a common 
schema will be quite difficult if organizations such as the IETF-PKIX 
group fail to grasp this nettle, and/or if the major CAs refuse to
cooperate, then that was essentially my original point.

And if anyone has an effective alternative to something approaching 
X.500 that is scalable to hundreds of millions of users in a world-wide
environment that must support non-Latin alphabets, etc., then I'd 
like to hear about it. Throwing all of the certificates into a jumble
of disorganized WWW home pages is certainly not the answer, and
neither is the exclusive use of in-band certificate distribution via 
mechanisms such as S/MIME, although either of those approaches 
may be appropriate for particular applications.

Regards,

Bob

 

From: <[email-masked]>
Date: 13 Nov 96 14:14
To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: unsubscribe
Encoding: 1 TEXT
Status:   

unsubscribe

Date: Wed, 13 Nov 1996 12:59:25 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Storage of X.509 certificates in X.500 -Reply -Reply

David, somehow my rules processor filed a number of messages before 
I had a chance to open them, so I'm just catching up with some from 
several days ago.

>> When I was involved in the NADF, there was one fundamental
> principle that came out -- regardless of the niceties of what 
> someone thinks a name ought to mean or imply, you list 
> information in a directory where users will tend to look for
> it. So if you are the Hotel View Zahrzeiten in Munich, and you
> wish to attract tourists from the US and Japan, in addition to Europe,
> you will probably want to list in the New York, Washington, Miami,
> Los Angeles, Tokyo, etc., directories, in addition to listing in
> Germany/Deutschland.

>Sorry Bob,
I just dont buy into your listing model if there is a global 
directory service. If there is a global directory, and I want to find 
details of hotels in Munich, then I would search the Munich part of 
the directory, not my local directory. Your (or should I say the defunct
 NADF) model leads to far too much 
data duplication - where and when do you stop adding listings for 
Munich hotels? Do you put them in every locality of the world? And 
imagine if every hotel in the world wanted to do the same thing! The 
data size would grow exponentially.
However, I do accept that if there are disconnected directories, then 
a hotel may want to have a listing in each directory. But your 
original premise was for a global directory. (I believe that in 
practice there are going to be hundreds of disconnected private 
directories with perhaps only  a handful of public global 
directories, so that a hotel may want a single listing in each 
disconnected directory )
David

I may have overstated the case, in trying to provide a general rule.
My example was better suited to a yellow pages application than
a traditional white pages directory. And I probably overstated the 
case with respect to the Utah repository -- it will presumably
be global in the sense that any subscriber in the world can access it,
and/or have his certificate posted into it (but probably for a fee, which
is a subject that X.500 doesn't adequately address.) But I didn't mean to 
infer that their repository will be directly interconnected with every other
X.500 directory -- certainly not yet. Where we (and the industry, I believe)
are at the moment is the archipelago model of the world. Individual islands
of directory services are popping up, and (to use a Novell NDS term), will
soon begin to federate on a bilateral agreement basis. Ultimately, whole
contents may arise from the see -- hopefully it won't require geological time
to accomplish this.

But the major point that I was trying to make was that if you 
expect your certificate to be found using your traditional geopolitical
DN (c=US, o=Novell, ou="Internet Infrastructure Division", cn="Robert
R. Jueneman"), then that is where you should file your certificate.

And if you expect users to be able to find your certificate knowing only
your e-mail address ([email-masked]), you had best file at least
a pointer to your certificate at that address as well. In X.500 terminology
that second address is still a distinguished name, although the anti-X.500
folks might not recognize it as such.

> If this principle is followed, certificates and other information may 
> be listed in many different locations, perhaps as alias or seeAlsos,
> or maybe just duplicate entries.
Bob
We need to get a more precise understanding of the term listing, 
because in my opinion alias and seeAlsos are not listings but 
pointers to listings. The Entries being pointed to, holding the 
attributes you want, are the listings.
David

It seems to me that it is up to the individual directory administrator
to decide whether to replicate an entry to permit accessing it
via a second name form, or whether to use an alias or seeAlso.
The pros and cons certainly aren't clear to me in the abstract, but
particular implementations may lend themselves better to one form 
than another.  Of course the rub comes when individual directories 
start to be hooked together, and these kinds of decisions have to 
be made in concert with all other directory administrators. Whether
such decisions will be implementable in the absence of a national
monopoly administration is TBD.

> 
> So in general, the relationship between directory entries and 
> certificates is probably many to many. That is, the same 
> certificate may be listed under quite a few different names,
Bob,
It depends upon what your are calling a name here. The name (or 
names) to public key binding held in the certificate is static. You 
cannot dynamically alter these names without invalidating the signature 
on the certificate. But the names of the locations in which the 
certificates are held can be changed dynamically. I presume that 
these are the names you are referring to. But, if we have a global 
directory, with good search capabilities, again the certificate need 
only be held in one place in order for it to be found. Alias pointers 
etc can also help in the search (except that early Paradise 
experiments recommended that aliased are NOT searched). Furthermore, data 
consistency suggests that you do not duplicate a corticate in the 
directory.

I agree, at least in part.  It is perhaps unfortunate that the field in a v1
certificate was called the Distinguished Name, since in fact there 
was no mechanism to ensure that it was distinguished, or had 
any correspondence to an entry in a directory.

So what I meant to say was that a given directory entry may contain 
multiple certificates, some having the same certificate entity name (AKA
certificate DN and/or subjectAlternateName) and differing only in the 
keyUsage, algorithm, or other fields. It isn't as clear, but I might have 
other certificates filed under a common directory DN for convenience, 
one having a traditional DN, one having my e-mail address, another having 
a DN plus a role name or title, etc. It just isn't clear to me what the best way
of organizing these different pieces of data is.  Should we collect together
everything that represents or has something to do with "me", or should
every different instance of "me" have a different name?  (I would assume
that certificates which have the same entity name but differ in the technical 
contents would be lumped together, but someone else might decide that 
they should put all of the DMS certificates in one place, all of the SET 
certificates in another, etc. Who can predict which organization will be "best",
without defining what the measurement criteria should be? I wouldn't
even attempt it, much less offer dogmatic statements to the effect that 
God intended that directories should be organized according to the 
author's specifications. (I'm not throwing rocks at you, but some people
have offered suggestions that seem overly simplistic -- In My Humble 
(but correct :-) Opinion, of course.)

>What we are suggesting in the ICE-TEL project is that a certificate 
can be retrieved by a variety of mechanisms e.g. FTP, email, WWW or 
X.500, but I would not recommend that a certificate be duplicated 
within a given X.500 service (other than by standard replication).
David

Well, that should provide a useful and interesting data point as to the
ease of use vs. administrative inconvenience. People I have talked
to who are more knowledgeable than I have suggested that storage 
is relatively cheap, but directory maintenance is relatively expensive.
So it isn't obvious whether certificate duplication under different names
would be better or worse than maintaining aliases and seeAlso lists.
What does seem obvious, given all of the sometimes rancorous discussion
of DNs vs. e-mail addresses, is that imposing a Procrustean solution of
one-entity, one entity-name, one-certificate is probably not going to 
satisfy the user community which wants to use the directory to find things
quickly and easily.

> in order to increase the probably that a user will find it. On the 
> other hand, a single entry may contain multiple certificates,
> including different algorithms, different key usages, and different
> roles or names, including multiple e-mail names or machine names.
> 
> Regardless of the virtues or lack thereof of a Distinguished Name
> for unambiguous identification, including the subject's DN in a 
> certificate at least provides one obvious way to find that certificate, 
> and to associate it with other information about the subject if you 
> don't have any other.
> 
> But this is almost surely not going to be sufficient, especially if as 
> expected the community makes extensive use of the 
> alternateSubjectName attribute.  If all you know about someone is their
> e-mail address, then that is where you should expect to find his 
> certificate, whether it is an RFC822 or X.400 address, or perhaps
> a proprietary format. Likewise, if all you know is someone's EDI number,
> that's where you should look in the directory.

>No I disagree with this. The alternate names suggest an alternative 
mechanism (i.e. application) to be used to retrieve the certificate 
i.e. you send email to the RFC822 address to get the certificate. It 
does not mean that there is a entry in X.500 with that RFC 822 
address as its DN.

Well, that's what makes horse races so interesting. I'm not inclined to 
reinvent X.500 every time someone comes up with a new application 
or naming strategy, but I won't get in your way if you choose to. It 
does seem to me, however, that once you get past the e-mail address 
paradigm and start worrying about health claim IDs, DUNS numbers, 
etc., that you may want to reconsider.
> 
> So as a minimum I would expect to find a primary entry under the 
> subject's DN as listed in the certificate, and at least an alias under
> each of the various alternate names.  Then you have to consider 
> how the user might expect to be found, and put additional entries there
> as well, whether the DN of the entry agrees with the DN in the
> subject's certificate or not.
> 
I'll stick to my original suggestion, but will look with interest at other forms
of directory services that might be proposed. .Exactly what we will do 
regarding a recommended schema within the Utah repository is not yet 
clear, nor is the best approach to use within Novell's own Novell 
Directory Service entirely obvious.

(BTW, some people might be interested to learn that Novell recently 
signed a deal with Sun which cross-licenses Sun's Java technology
and Novell's NDS technology. Beginning in 1997, Sun will include a copy
of NDS with every copy of Solaris. Novell will also be shipping a version 
of NDS which runs on Windows NT, and deals are pending but not yet 
announced with other major hardware and software manufacturers.
Things are going to start to get more and more interesting!)

Bob

From: <[email-masked]>
Date: 13 Nov 96 14:14
To: [email-masked]
Cc: [email-masked]
Cc: [email-masked]
Subject: unsubscribe
Encoding: 1 TEXT

unsubscribe

From: "Marc Duplessis" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: unsubscribe
Date: Tue, 12 Nov 1996 19:07:58 -0500
Status:   

unsubscribe

Marc Duplessis, B.Ing., M.Sc.A.
Les Consultants Marc Duplessis Inc.
4205 Morisset
Laval, Quebec, Canada, H7R 1P7
Tel.: 514-962-8983
Pagette: 514-921-3147
email: [email-masked], [email-masked]

X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 12 Nov 1996 10:20:10 -0500 
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 12 Nov 1996 09:56:25 -0500 
X400-Received: by /PRMD=BNR/ADMD= /C=GB/; Relayed; Tue, 12 Nov 1996 09:54:27 -0500 
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 12 Nov 1996 09:51:29 -0500 
X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 12 Nov 1996 09:51:25 -0500 
Date: Tue, 12 Nov 1996 09:51:25 -0500 
X400-Originator: /dd.id=1660747/g=peter/i=pw/s=whittaker/@bnr.ca 
X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;<c=CA%a=_%p=NorTel_Secure_Ne%l=G] 
X400-Content-Type: P2-1984 (2) 
Content-Identifier: RE: Storage o... 
From: "peter (p.w.) whittaker" <[email-masked]>
To: "'ietf-pkix%tandem.com@bnr400'" <[email-masked]>
Subject: RE: Storage of X.509 certificates in X.500 
Encoding: 110 TEXT 
Status:   

>From: 	Peter Whittaker
>As for userCertificates, "holding someone else's certificate" doesn't
>seem useful or sensible at all:  how would someone know to look there?
>
>Its a very sensible place to put the cert of the parties with whom
>one often interworks. That working set is then
>available for other to know and use, in a manner
>similar to WWW folk publishing their "collection of links".

That's an interesting approach.  I take it that the desire is to share
those certificates with other users, i.e., to make the community with
whom one interworks available to others with whom one interworks?

If not, then local storage would probably be more efficient/effective.

Pursuing the efficient/effective idea for a moment, if one wishes one's
frequent contacts to be aware of each other, wouldn't it make more
sense to populate one's directory entry with a list of DN's of entries
that contain those certificates, perhaps in an attribute called
myFrequentContacts?  Since the assumption is made that one's
contacts can access one's own entry, it may well be that they can
access each others.

The problem with storing certificates of one's frequent contacts in
one's own entry quickly becomes obvious when one considers that
the frequent contacts will also do this:  if I have 100 frequent
contacts,
and we all do this, and we all use the same directory server, then
that server contain 10000 certificates for 100 users, assuming that
one's own certificate is also in one's entry.

With version 3 certificates, that's a lot of wasted space.  Better to
maintain a list of URL's or DN's in one's entry that allows others to
obtain the certificates of one's frequent contacts.

Not to mention the fact that a read or search of the userCertificate
attribute of one's entry returns all values of that attribute, i.e.,
your
certificate and the certificates of each of your 100 contacts.

At least until directory vendors implement certificate matching rules,
at which time the problem becomes the directory server's, and it
has to slog through 100+ certificates to find the one of interest.
Nasty.
>
>There is absolutely no technical correspndance between the name
>of my LDAP entry, and the names in my user certs in
>the std userCert attribute! in fact, LDAP and DAS ttreats them (correctly) as
>opaque blobs when performing modify or compare operations.

Very true.  But there is a certain sense in having the values of
attributes
in one's own entry be one's own values, i.e., values that unabiguously
associated with the real world object represented by that entry.

>A recipient can make no assumption in an untrusted directory
>than a there is any relation between a cert found in
>an entry, and then name of the entry. The fact that
>a DSA might sign the result PDU (of the LDAP
>server provides SSL server-auth), also, provides
>NO information-level reliability service,
>or makes any assertion of management
>model schema conformance.

True again.  But if one is considering using a directory to store
certificates,
I'd argue that it the most sensible thing to do is to store the
subject's certificate
in the subject's entry.

It's worth reiterating the point about the untrusted directory.  The
certificate
user should make use of only the information contained in the
certificate to
validate the certificate.  For example, if one is searching on email
address to
obtain a certificate from the directory, the certificate should contain
that
email address (and any other search criteria used).  Note that this does
not
have to be via the DN of the subject:  it could be via an alternative
subject
name, or via an arbitrary attribute in a certificate extension.
>
>PKI itself is not pre-conditioned on a global directory.

But a scalable, robust PKI requires a sensibly engineered method
of disseminating certificates to the PKI user community.  One of the
methods of doing this is the use of directory, preferably a connected
directory.  Over time, I think we will see such a beast evolve, possibly
primarily to support PKI.

Admittedly, there are other ways of obtaining the certificates of users
with whom one will communicate, i.e., a company might publish its
user's certificates on its web page.  The problem is knowing that you
have to go there to get them....

The nice thing about a connected directory is that if I want to obtain
your certificate, I ask the directory (via my home DSA/other type of
server) to search for your entry in your company.
>
>PKI names furthermore need not be X.500 DNs.

True.  As noted, the important thing is that the certificate contain
the identification important to the end-user, i.e., if I'm using the
certificate to secure mail for you, I'll want the certificate to include
your email address.

pww

From: "Marc Duplessis" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: unsubscribe
Date: Tue, 12 Nov 1996 19:07:58 -0500

unsubscribe

Marc Duplessis, B.Ing., M.Sc.A.
Les Consultants Marc Duplessis Inc.
4205 Morisset
Laval, Quebec, Canada, H7R 1P7
Tel.: 514-962-8983
Pagette: 514-921-3147
email: [email-masked], [email-masked]

X400-Received:   by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 12 Nov 1996 10:20:10 -0500 
X400-Received:   by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 12 Nov 1996 09:56:25 -0500 
X400-Received:   by /PRMD=BNR/ADMD= /C=GB/; Relayed; Tue, 12 Nov 1996 09:54:27 -0500 
X400-Received:   by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 12 Nov 1996 09:51:29 -0500 
X400-Received:   by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 12 Nov 1996 09:51:25 -0500 
Date:  Tue, 12 Nov 1996 09:51:25 -0500 
X400-Originator:  /dd.id=1660747/g=peter/i=pw/s=whittaker/@bnr.ca 
X400-MTS-Identifier:   [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;<c=CA%a=_%p=NorTel_Secure_Ne%l=G] 
X400-Content-Type:  P2-1984 (2) 
Content-Identifier:  RE: Storage o... 
From: "peter (p.w.) whittaker" <[email-masked]>
To: "'ietf-pkix%tandem.com@bnr400'" <[email-masked]>
Subject:  RE: Storage of X.509 certificates in X.500 
Encoding: 110 TEXT

>From: 	Peter Whittaker
>As for userCertificates, "holding someone else's certificate" doesn't
>seem useful or sensible at all:  how would someone know to look there?
>
>Its a very sensible place to put the cert of the parties with whom
>one often interworks. That working set is then
>available for other to know and use, in a manner
>similar to WWW folk publishing their "collection of links".

That's an interesting approach.  I take it that the desire is to share
those certificates with other users, i.e., to make the community with
whom one interworks available to others with whom one interworks?

If not, then local storage would probably be more efficient/effective.

Pursuing the efficient/effective idea for a moment, if one wishes one's
frequent contacts to be aware of each other, wouldn't it make more
sense to populate one's directory entry with a list of DN's of entries
that contain those certificates, perhaps in an attribute called
myFrequentContacts?  Since the assumption is made that one's
contacts can access one's own entry, it may well be that they can
access each others.

The problem with storing certificates of one's frequent contacts in
one's own entry quickly becomes obvious when one considers that
the frequent contacts will also do this:  if I have 100 frequent
contacts,
and we all do this, and we all use the same directory server, then
that server contain 10000 certificates for 100 users, assuming that
one's own certificate is also in one's entry.

With version 3 certificates, that's a lot of wasted space.  Better to
maintain a list of URL's or DN's in one's entry that allows others to
obtain the certificates of one's frequent contacts.

Not to mention the fact that a read or search of the userCertificate
attribute of one's entry returns all values of that attribute, i.e.,
your
certificate and the certificates of each of your 100 contacts.

At least until directory vendors implement certificate matching rules,
at which time the problem becomes the directory server's, and it
has to slog through 100+ certificates to find the one of interest.
Nasty.
>
>There is absolutely no technical correspndance between the name
>of my LDAP entry, and the names in my user certs in
>the std userCert attribute! in fact, LDAP and DAS ttreats them (correctly) as
>opaque blobs when performing modify or compare operations.

Very true.  But there is a certain sense in having the values of
attributes
in one's own entry be one's own values, i.e., values that unabiguously
associated with the real world object represented by that entry.

>A recipient can make no assumption in an untrusted directory
>than a there is any relation between a cert found in
>an entry, and then name of the entry. The fact that
>a DSA might sign the result PDU (of the LDAP
>server provides SSL server-auth), also, provides
>NO information-level reliability service,
>or makes any assertion of management
>model schema conformance.

True again.  But if one is considering using a directory to store
certificates,
I'd argue that it the most sensible thing to do is to store the
subject's certificate
in the subject's entry.

It's worth reiterating the point about the untrusted directory.  The
certificate
user should make use of only the information contained in the
certificate to
validate the certificate.  For example, if one is searching on email
address to
obtain a certificate from the directory, the certificate should contain
that
email address (and any other search criteria used).  Note that this does
not
have to be via the DN of the subject:  it could be via an alternative
subject
name, or via an arbitrary attribute in a certificate extension.
>
>PKI itself is not pre-conditioned on a global directory.

But a scalable, robust PKI requires a sensibly engineered method
of disseminating certificates to the PKI user community.  One of the
methods of doing this is the use of directory, preferably a connected
directory.  Over time, I think we will see such a beast evolve, possibly
primarily to support PKI.

Admittedly, there are other ways of obtaining the certificates of users
with whom one will communicate, i.e., a company might publish its
user's certificates on its web page.  The problem is knowing that you
have to go there to get them....

The nice thing about a connected directory is that if I want to obtain
your certificate, I ask the directory (via my home DSA/other type of
server) to search for your entry in your company.
>
>PKI names furthermore need not be X.500 DNs.

True.  As noted, the important thing is that the certificate contain
the identification important to the end-user, i.e., if I'm using the
certificate to secure mail for you, I'll want the certificate to include
your email address.

pww

Date: Tue, 12 Nov 1996 00:06:54 -0800
From: [email-masked] (Jeff Weinstein)
Reply-To: [email-masked]
Organization: Netscape Communications Corp.
To: Robert Jueneman <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: >>> Blake Ramsdell <[email-masked]> 11/07/96 06:44pm >>>

Robert Jueneman wrote:
> 
>> Blake Ramsdell <[email-masked]> 11/07/96 06:44pm >>>
>> Two cents from the S/MIME camp here -- symmetric capabilities are
>> relayed on a message by message basis, not in the certificate (there is
>> a SET OF authenticatedAttributes that are signed by the sender, and one
>> of these is symmetricCapbilities).  The determination of the algorithm
>> is based on the last-transmitted algorithm capabilities (which reflects
>> preference order as well as capabilities.)
> 
> I haven't tracked S/MIME recently. What happens if you haven't
> communicated with someone yet? Are the current S/MIME
> implementations dependent on a previous message to get
> the destination user's certificate?
> 
> Can you assess the willingness of the S/MIME vendors to
> make use of a symmetricCapabilities in the certificate?

  The way that S/MIME users will typically exchange certificates
is via a signed message, which will include the symmetric
capabilities and their cert.

  The reason that the symmetric capabilities was not included
with the cert is that it is really a user preference, not under
CA control.  It is also likely to change (at the whim of the
user), and the user should not be required to get a new cert
in this case.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
[email-masked] - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

Date: Fri, 08 Nov 1996 08:13:06 -0700
From: Robert Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: >>> Blake Ramsdell <[email-masked]> 11/07/96 06:44pm >>>

>>> Blake Ramsdell <[email-masked]> 11/07/96 06:44pm >>>
Two cents from the S/MIME camp here -- symmetric capabilities are
relayed on a message by message basis, not in the certificate (there is
a SET OF authenticatedAttributes that are signed by the sender, and one
of these is symmetricCapbilities).  The determination of the algorithm
is based on the last-transmitted algorithm capabilities (which reflects
preference order as well as capabilities.)

I haven't tracked S/MIME recently. What happens if you haven't 
communicated with someone yet? Are the current S/MIME 
implementations dependent on a previous message to get
the destination user's certificate?

Can you assess the willingness of the S/MIME vendors to
make use of a symmetricCapabilities in the certificate?

Bob

Date: Mon, 11 Nov 96 14:15:39 
From: "Housley, Russ" <[email-masked]>
Encoding: 720 Text
To: [email-masked], Bob Jueneman <[email-masked]>
Subject: Re: proposal for X.509 validity period -Reply
Status:   

Bob:

>There might be another alternative.
>
>Because I don't like the way that the DER encoding of generalizedTime 
>imposes an unnecessary restriction on the basic definition by not 
>supporting the local time format which is otherwise valid format, making 
>it difficult to determine the validity of the syntax at compile time,
>I would suggest that instead of using generalizedTime we adopt 
>some brand new type, say compromiseTime, WHOSE DER 
>ENCODING WOULD BE IDENTICAL TO UTCTime UNTIL 2087, 
>and identical to generalizedTime after that time.

I do not understand why the use of GMT within all certificates is a 
problem.  It is trivial to adjust GMT to local time for display to users.

Russ

Date: Mon, 11 Nov 96 14:15:39 
From: "Housley, Russ" <[email-masked]>
Encoding: 720 Text
To: [email-masked], Bob Jueneman <[email-masked]>
Subject: Re: proposal for X.509 validity period -Reply

Bob:

>There might be another alternative.
>
>Because I don't like the way that the DER encoding of generalizedTime 
>imposes an unnecessary restriction on the basic definition by not 
>supporting the local time format which is otherwise valid format, making 
>it difficult to determine the validity of the syntax at compile time,
>I would suggest that instead of using generalizedTime we adopt 
>some brand new type, say compromiseTime, WHOSE DER 
>ENCODING WOULD BE IDENTICAL TO UTCTime UNTIL 2087, 
>and identical to generalizedTime after that time.

I do not understand why the use of GMT within all certificates is a 
problem.  It is trivial to adjust GMT to local time for display to users.

Russ

From: Peter Williams <[email-masked]>
To: "'ITS024%thebe.salford.ac.uk@bnr400'" <[email-masked]>, "'Peter Whittaker'" <[email-masked]>
Cc: "'ietf-pkix%tandem.com'" <[email-masked]>
Subject: RE: Storage of X.509 certificates in X.500
Date: Mon, 11 Nov 1996 11:56:21 -0800

----------
From: 	Peter Whittaker
Sent: 	Monday, November 11, 1996 5:38 AM
To: 	'pww%entrust.com@bnr400'; 'ITS024%thebe.salford.ac.uk@bnr400'
Cc: 	'ietf-pkix%tandem.com'
Subject: 	RE: Storage of X.509 certificates in X.500

 As for userCertificates, "holding someone else's certificate" doesn't
seem
useful or sensible at all:  how would someone know to look there?

Its a very sensible place to put the cert of the parties with whom
one often interworks. That working set is then
available for other to know and use, in a manner
similar to WWW folk publishing their "collection of links".

There is absolutely no technical correspndance between the name
of my LDAP entry, and the names in my user certs in
the std userCert attribute! in fact, LDAP and DAS ttreats them (correctly) as
opaque blobs when performing modify or compare operations.

A recipient can make no assumption in an untrusted directory
than a there is any relation between a cert found in
an entry, and then name of the entry. The fact that
a DSA might sign the result PDU (of the LDAP
server provides SSL server-auth), also, provides
NO information-level reliability service,
or makes any assertion of management
model schema conformance.

Both Novell and Entrust seem to be hinging the
future of a internet PKI on a high-quality global directory, and are
engineering things to make such a dirctory possible
in practice. This seems a very dubious thing to do,
unless you are a manufacturer or provider of directories
with a vested interest!

PKI itself is not pre-conditioned on a global directory.

PKI names furthermore need not be X.500 DNs.

Those DNs which are used in certs are not techncially
required to conform to any given global schema, or any
schema at all, in fact.

IN an internet enviornment which we are
here involved in (versus a private UTAH enviornment say)
the management system control of names to intrument
a global directory is fraught with problems. Use
of directory service from bottom up (WWWW, LDAP, etc) is a very good thing
however, and over time, one can expect harmonization of
actual schemas for entries, and possibly the contents
of names of certs (where internet certs use X.500 name forms)

 

From: Peter Whittaker <[email-masked]>
To: "'pww%entrust.com@bnr400'" <[email-masked]>, "'ITS024%thebe.salford.ac.uk@bnr400'" <[email-masked]>
Cc: "'ietf-pkix%tandem.com'" <[email-masked]>
Subject: RE: Storage of X.509 certificates in X.500
Date: Mon, 11 Nov 1996 08:38:28 -0500
Encoding: 40 TEXT

>> >1. Storage of a X.509 certificate in a X.500 server
>> >
>> >- Is it common practice to use the "subject" field of the
>> >  certificate as distinguished name of the entry which holds
>> >  the certificate as an attribute?
>> 
>> If the subject name is a DN, then it is generally the case that the
>> certificate will be stored in the
>> entry with that DN (I'm not sure that it makes any sense to store it
>> elsewhere).  What does it mean
>> if the DN of the entry references one person, but the DN on the
>> certificate references someone else?
>
>Nothing really. It simply means that entry A is holding entry B's 
>certficate. This will be perfectly normal for example for CA cross 
>certificates. 

A cross certificate is a different beast, what with its being held in a
cross-certificate pair.  Also, I took the original question as applying
to
end-user certificates.

I can imagine a CA holding in its entry cACertificates that it has
issued,
on the off chance that an application would find this useful, i.e., if
an application
environment required that all users be able to determine, in the
abscence
of the use of certificate matching rules.  It would only be a sensible
thing
to do while the numbers were small (at least until the use of
certificate
matching rules becomes common).

As for userCertificates, "holding someone else's certificate" doesn't
seem
useful or sensible at all:  how would someone know to look there?

pww

Date: Sun, 10 Nov 1996 22:23:43 -0800 (PST)
From: "Patrick C. Richard" <[email-masked]>
To: David Chadwick <[email-masked]>
cc: [email-masked], [email-masked], Bob Jueneman <[email-masked]>, [email-masked]
Subject: Re: Storage of X.509 certificates in X.500 -Reply

On Sat, 9 Nov 1996, David Chadwick wrote:

> Date: Sat, 9 Nov 1996 22:38:11 +0000
> From: David Chadwick <[email-masked]>
> To: [email-masked], [email-masked],
>     Bob Jueneman <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Storage of X.509 certificates in X.500 -Reply
> 
> > Date:          Thu, 07 Nov 1996 16:21:02 -0700
> > From:          Bob Jueneman <[email-masked]>
> > To:            [email-masked], [email-masked]
> > Cc:            [email-masked]
> > Subject:       Storage of X.509 certificates in X.500 -Reply
> 
> > An excellent question, and this is as good a place as 
> > any to discuss it.
> > 

Well, we have been storing certificates in LDAP-based DBs for quite
some time now, and have also extended it to store them in SSL-LDAP DBs,
with access to certain DN attributes restricted on the basis of the
connecting SSL-LDAP client.

The beauty is that you end up with a secure DB, and client-sensitive
views of the namespace, with the whole namespace being authenticated and
signed.

This forms the basis of our PKI, and it allows us to store certs in not
only X.500 back ends but anything else that will interoperate with
LDAP.

Comments: Authenticated sender is <[email-masked]>
From: David Chadwick <[email-masked]>
To: [email-masked], [email-masked], Bob Jueneman <[email-masked]>
Date: Sat, 9 Nov 1996 22:38:11 +0000
Subject: Re: Storage of X.509 certificates in X.500 -Reply
Cc: [email-masked]
Priority: normal
Status:   

> Date:          Thu, 07 Nov 1996 16:21:02 -0700
> From:          Bob Jueneman <[email-masked]>
> To:            [email-masked], [email-masked]
> Cc:            [email-masked]
> Subject:       Storage of X.509 certificates in X.500 -Reply

> An excellent question, and this is as good a place as 
> any to discuss it.
> 
> [I'm personally very interested, as Novell is a member of the 
> team (consisting of CertCo, Novell, Omnimark, and Zion Bank)
> which will be implementing the certification authority and repository
> infrastructure for the State of Utah in the US. Since Utah was the 
> first governmental entity anywhere in the world to pass a 
> digital signature law, they are probably going to be the first to 
> have to wrestle with these issues across multiple CAs
> and multiple user organizations. And that tends to imply a
> more or less global directory, perhaps for  the first time.]
> 
> When I was involved in the NADF, there was one fundamental
> principle that came out -- regardless of the niceties of what 
> someone thinks a name ought to mean or imply, you list 
> information in a directory where users will tend to look for
> it. So if you are the Hotel View Zahrzeiten in Munich, and you
> wish to attract tourists from the US and Japan, in addition to Europe,
> you will probably want to list in the New York, Washington, Miami,
> Los Angeles, Tokyo, etc., directories, in addition to listing in
> Germany/Deutschland.

Sorry Bob,
I just dont buy into your listing model if there is a global 
directory service. If there is a global directory, and I want to find 
details of hotels in Munich, then I would search the Munich part of 
the directory, not my local directory. Your (or should I say the defunct
 NADF) model leads to far too much 
data duplication - where and when do you stop adding listings for 
Munich hotels? Do you put them in every locality of the world? And 
imagine if every hotel in the world wanted to do the same thing! The 
data size would grow exponentially.
However, I do accept that if there are disconnected directories, then 
a hotel may want to have a listing in each directory. But your 
original premise was for a global directory. (I believe that in 
practice there are going to be hundreds of disconnected private 
directories with perhaps only  a handful of public global 
directories, so that a hotel may want a single listing in each 
disconnected directory )
David

> If this principle is followed, certificates and other information may 
> be listed in many different locations, perhaps as alias or seeAlsos,
> or maybe just duplicate entries.
Bob
We need to get a more precise understanding of the term listing, 
because in my opinion alias and seeAlsos are not listings but 
pointers to listings. The Entries being pointed to, holding the 
attributes you want, are the listings.
David
> 
> So in general, the relationship between directory entries and 
> certificates is probably many to many. That is, the same 
> certificate may be listed under quite a few different names,
Bob,
It depends upon what your are calling a name here. The name (or 
names) to public key binding held in the certficate is static. You 
cannot dynamically alter these names without invalidating the signature 
on the certificate. But the names of the locations in which the 
certificates are held can be changed dynamically. I presume that 
these are the names you are referring to. But, if we have a global 
directory, with good search capabilities, again the certificate need 
only be held in one place in order for it to be found. Alias pointers 
etc can also help in the search (except that early Paradise 
experiments recommended that aliased are NOT searched). Furthermore, data 
consistency suggests that you do not duplicate a certicate in the 
directory.
What we are suggesting in the ICE-TEL project is that a certificate 
can be retreived by a variety of mechanisms eg. FTP, email, WWW or 
X.500, but I would not recommend that a certificate be duplicated 
within a given X.500 service (other than by standard replication).
David

> in order to increase the probably that a user will find it. On the 
> other hand, a single entry may contain multiple certificates,
> including different algorithms, different key usages, and different
> roles or names, including multiple e-mail names or machine names.
> 
> Regardless of the virtues or lack thereof of a Distinguished Name
> for unambiguous identification, including the subject's DN in a 
> certificate at least provides one obvious way to find that certificate, 
> and to associate it with other information about the subject if you 
> don't have any other.
> 
> But this is almost surely not going to be sufficient, especially if as 
> expected the community makes extensive use of the 
> alternateSubjectName attribute.  If all you know about someone is their
> e-mail address, then that is where you should expect to find his 
> certificate, whether it is an RFC822 or X.400 address, or perhaps
> a proprietary format. Likewise, if all you know is someone's EDI number,
> that's where you should look in the directory.

No I disagree with this. The alternate names suggest an alternative 
mechanism (i.e. application) to be used to retreive the certificate 
i.e. you send email to the RFC822 address to get the certificate. It 
does not mean that there is a entry in X.500 with that RFC 822 
address as its DN.
> 
> So as a minimum I would expect to find a primary entry under the 
> subject's DN as listed in the certificate, and at least an alias under
> each of the various alternate names.  Then you have to consider 
> how the user might expect to be found, and put additional entries there
> as well, whether the DN of the entry agrees with the DN in the
> subject's certificate or not.
> 
> 
***********************************
David W Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 745 5351  Fax +44 161 745 8169
*****************************

Comments: Authenticated sender is <[email-masked]>
From: David Chadwick <[email-masked]>
To: [email-masked], [email-masked], Bob Jueneman <[email-masked]>
Date: Sat, 9 Nov 1996 22:38:11 +0000
Subject: Re: Storage of X.509 certificates in X.500 -Reply
CC: [email-masked]
Priority: normal

> Date:          Thu, 07 Nov 1996 16:21:02 -0700
> From:          Bob Jueneman <[email-masked]>
> To:            [email-masked], [email-masked]
> Cc:            [email-masked]
> Subject:       Storage of X.509 certificates in X.500 -Reply

> An excellent question, and this is as good a place as 
> any to discuss it.
> 
> [I'm personally very interested, as Novell is a member of the 
> team (consisting of CertCo, Novell, Omnimark, and Zion Bank)
> which will be implementing the certification authority and repository
> infrastructure for the State of Utah in the US. Since Utah was the 
> first governmental entity anywhere in the world to pass a 
> digital signature law, they are probably going to be the first to 
> have to wrestle with these issues across multiple CAs
> and multiple user organizations. And that tends to imply a
> more or less global directory, perhaps for  the first time.]
> 
> When I was involved in the NADF, there was one fundamental
> principle that came out -- regardless of the niceties of what 
> someone thinks a name ought to mean or imply, you list 
> information in a directory where users will tend to look for
> it. So if you are the Hotel View Zahrzeiten in Munich, and you
> wish to attract tourists from the US and Japan, in addition to Europe,
> you will probably want to list in the New York, Washington, Miami,
> Los Angeles, Tokyo, etc., directories, in addition to listing in
> Germany/Deutschland.

Sorry Bob,
I just dont buy into your listing model if there is a global 
directory service. If there is a global directory, and I want to find 
details of hotels in Munich, then I would search the Munich part of 
the directory, not my local directory. Your (or should I say the defunct
 NADF) model leads to far too much 
data duplication - where and when do you stop adding listings for 
Munich hotels? Do you put them in every locality of the world? And 
imagine if every hotel in the world wanted to do the same thing! The 
data size would grow exponentially.
However, I do accept that if there are disconnected directories, then 
a hotel may want to have a listing in each directory. But your 
original premise was for a global directory. (I believe that in 
practice there are going to be hundreds of disconnected private 
directories with perhaps only  a handful of public global 
directories, so that a hotel may want a single listing in each 
disconnected directory )
David

> If this principle is followed, certificates and other information may 
> be listed in many different locations, perhaps as alias or seeAlsos,
> or maybe just duplicate entries.
Bob
We need to get a more precise understanding of the term listing, 
because in my opinion alias and seeAlsos are not listings but 
pointers to listings. The Entries being pointed to, holding the 
attributes you want, are the listings.
David
> 
> So in general, the relationship between directory entries and 
> certificates is probably many to many. That is, the same 
> certificate may be listed under quite a few different names,
Bob,
It depends upon what your are calling a name here. The name (or 
names) to public key binding held in the certficate is static. You 
cannot dynamically alter these names without invalidating the signature 
on the certificate. But the names of the locations in which the 
certificates are held can be changed dynamically. I presume that 
these are the names you are referring to. But, if we have a global 
directory, with good search capabilities, again the certificate need 
only be held in one place in order for it to be found. Alias pointers 
etc can also help in the search (except that early Paradise 
experiments recommended that aliased are NOT searched). Furthermore, data 
consistency suggests that you do not duplicate a certicate in the 
directory.
What we are suggesting in the ICE-TEL project is that a certificate 
can be retreived by a variety of mechanisms eg. FTP, email, WWW or 
X.500, but I would not recommend that a certificate be duplicated 
within a given X.500 service (other than by standard replication).
David

> in order to increase the probably that a user will find it. On the 
> other hand, a single entry may contain multiple certificates,
> including different algorithms, different key usages, and different
> roles or names, including multiple e-mail names or machine names.
> 
> Regardless of the virtues or lack thereof of a Distinguished Name
> for unambiguous identification, including the subject's DN in a 
> certificate at least provides one obvious way to find that certificate, 
> and to associate it with other information about the subject if you 
> don't have any other.
> 
> But this is almost surely not going to be sufficient, especially if as 
> expected the community makes extensive use of the 
> alternateSubjectName attribute.  If all you know about someone is their
> e-mail address, then that is where you should expect to find his 
> certificate, whether it is an RFC822 or X.400 address, or perhaps
> a proprietary format. Likewise, if all you know is someone's EDI number,
> that's where you should look in the directory.

No I disagree with this. The alternate names suggest an alternative 
mechanism (i.e. application) to be used to retreive the certificate 
i.e. you send email to the RFC822 address to get the certificate. It 
does not mean that there is a entry in X.500 with that RFC 822 
address as its DN.
> 
> So as a minimum I would expect to find a primary entry under the 
> subject's DN as listed in the certificate, and at least an alias under
> each of the various alternate names.  Then you have to consider 
> how the user might expect to be found, and put additional entries there
> as well, whether the DN of the entry agrees with the DN in the
> subject's certificate or not.
> 
> 
***********************************
David W Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 745 5351  Fax +44 161 745 8169
*****************************

Comments: Authenticated sender is <[email-masked]>
From: David Chadwick <[email-masked]>
To: Peter Whittaker <[email-masked]>
Date: Sat, 9 Nov 1996 22:38:11 +0000
Subject: RE: Storage of X.509 certificates in X.500
CC: "[email-masked]'" <[email-masked]>
Priority: normal

> From:          Peter Whittaker <[email-masked]>
> To:            "[email-masked]'" <[email-masked]>
> Cc:            "[email-masked]'" <[email-masked]>
> Subject:       RE: Storage of X.509 certificates in X.500
> Date:          Thu, 7 Nov 1996 12:35:05 -0500

> >1. Storage of a X.509 certificate in a X.500 server
> >
> >- Is it common practice to use the "subject" field of the
> >  certificate as distinguished name of the entry which holds
> >  the certificate as an attribute?
> 
> If the subject name is a DN, then it is generally the case that the
> certificate will be stored in the
> entry with that DN (I'm not sure that it makes any sense to store it
> elsewhere).  What does it mean
> if the DN of the entry references one person, but the DN on the
> certificate references someone else?

Nothing really. It simply means that entry A is holding entry B's 
certficate. This will be perfectly normal for example for CA cross 
certificates. 
David
 
***********************************
David W Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 745 5351  Fax +44 161 745 8169
*****************************

From: "DAVE RITTEN" <[email-masked]>
Organization: Consultancy in Advanced Tech.
To: [email-masked]
Date: Fri, 8 Nov 1996 09:44:51 +0200
Subject: Subscribe
Priority: normal
Status:   

Subscribe

Date: Fri, 08 Nov 1996 09:08:11 -0500
To: Bob Jueneman <[email-masked]>, [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: Symmetric algorithm OIDs and back to DSA Algorithm OIDs-Reply

Bob:

The Supported Algorithms attribute provides for its own parameters.  They
are within the AlgorithmIdentifier structure.  I do not think there is any
defect requiring correction.

Warwick

>Regarding Ron Rivest's observation, we may be stuck, since the 
>subjectDirectoryAttributes extension doesn't provide for any parameters.
>
>I suppose we could try to fix that via the ISO defect mechanism, if we 
>hurry, as it is unlikely that anyone has implemented that extension yet.
>
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

From: "DAVE RITTEN" <[email-masked]>
Organization: Consultancy in Advanced Tech.
To: [email-masked]
Date: Fri, 8 Nov 1996 09:44:51 +0200
Subject: Subscribe
Priority: normal

Subscribe

Date: Thu, 07 Nov 1996 16:21:02 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Storage of X.509 certificates in X.500 -Reply
Status:   

An excellent question, and this is as good a place as 
any to discuss it.

[I'm personally very interested, as Novell is a member of the 
team (consisting of CertCo, Novell, Omnimark, and Zion Bank)
which will be implementing the certification authority and repository
infrastructure for the State of Utah in the US. Since Utah was the 
first governmental entity anywhere in the world to pass a 
digital signature law, they are probably going to be the first to 
have to wrestle with these issues across multiple CAs
and multiple user organizations. And that tends to imply a
more or less global directory, perhaps for  the first time.]

[I'm not sure that there is any "common practice" as yet. The few
public CAs I am aware of do not make their certificates available 
in X.500 as yet, and those products such as Nortel's Entrust that 
do interface to X.500 are typically used in a closed environment 
within one organization, where these issues are more tractable.]

When I was involved in the NADF, there was one fundamental
principle that came out -- regardless of the niceties of what 
someone thinks a name ought to mean or imply, you list 
information in a directory where users will tend to look for
it. So if you are the Hotel View Zahrzeiten in Munich, and you
wish to attract tourists from the US and Japan, in addition to Europe,
you will probably want to list in the New York, Washington, Miami,
Los Angeles, Tokyo, etc., directories, in addition to listing in
Germany/Deutschland.

If this principle is followed, certificates and other information may 
be listed in many different locations, perhaps as alias or seeAlsos,
or maybe just duplicate entries.

So in general, the relationship between directory entries and 
certificates is probably many to many. That is, the same 
certificate may be listed under quite a few different names,
in order to increase the probably that a user will find it. On the 
other hand, a single entry may contain multiple certificates,
including different algorithms, different key usages, and different
roles or names, including multiple e-mail names or machine names.

Regardless of the virtues or lack thereof of a Distinguished Name
for unambiguous identification, including the subject's DN in a 
certificate at least provides one obvious way to find that certificate, 
and to associate it with other information about the subject if you 
don't have any other.

But this is almost surely not going to be sufficient, especially if as 
expected the community makes extensive use of the 
alternateSubjectName attribute.  If all you know about someone is their
e-mail address, then that is where you should expect to find his 
certificate, whether it is an RFC822 or X.400 address, or perhaps
a proprietary format. Likewise, if all you know is someone's EDI number,
that's where you should look in the directory.

So as a minimum I would expect to find a primary entry under the 
subject's DN as listed in the certificate, and at least an alias under
each of the various alternate names.  Then you have to consider 
how the user might expect to be found, and put additional entries there
as well, whether the DN of the entry agrees with the DN in the
subject's certificate or not.

Have I made your life hard enough yet? Too bad, it's going to get
worse before it gets better.  We now have to discuss the awkward 
issue of the directory schema.

So long as Certification Authorities and directory administrators don't
talk to each other, they can independently choose whatever schema
for their DNs they would like. If one organization prefers to use commonName
with last name first, and the other first name first, that is fine, so long 
as they don't have to interoperate.

Unfortunately, perhaps, X.500 directories are generally not relational 
databases. Most directory implementations can efficiently look up a 
telephone number given a name, or a name given a telephone 
number, or a street address using either, but only if the appropriate
filters (search criteria) were predefined. Otherwise, the search 
ends up sweeping through the entire directory.

Now if one directory doesn't contain the desired information and you 
have to go through a referral mechanism, the two directory administrators
had better have defined a common schema, or the search will be very 
inefficient.

Although we tried to deal with this problem back in the PEM days 
(when there was only a single DN, and no alternate names), we never 
really nailed down the problem. So now the problem is even worse.

I would claim that there is virtually no common understanding as to 
what the allowable syntax and semantics are for the content of a
DN, even from among the set defined in X.521, much less any private
attributes. Worse yet, although there is a clear need to be able to distinguish
between two organizationalPersons who have the same name within
an organization (or two residentialPersons), there is no consensus
as to whether a multi-valued RDN is allowed.

So what we are probably going to have to do for Utah is to poll as many
of the various CAs as we can identify and ask them what their practices 
are, or more importantly, will be. So far, my attempts to gather this kind
of information have not met with a huge success -- some people seem 
to feel that the information is sort of proprietary, others aren't quite willing
to say because it might change, etc. So we may have to arbitrarily define
a directory schema, and let CAs and CA vendors object if their certificates 
can't be stored or retrieved.

We would probably be willing to publish the syntax and semantics of 
registered attributes, both quasi-standard and private attributes, but 
collecting the information seems a very daunting task.

I'm sorry if I have failed to brighten your day, but I see this as the tiny tip of
an enormous iceberg.

Bob

>>> Jochen Keutel <[email-masked]> 11/07/96 08:38am >>>
Hello,
  I'm not sure whether this is the right place to ask these
questions - if it's not the right place please direct me
to a more appropriate mailing list.

My Questions:

1. Storage of a X.509 certificate in a X.500 server

- Is it common practice to use the "subject" field of the
  certificate as distinguished name of the entry which holds
  the certificate as an attribute?
- If not - how does the client loading the certificates (CA, ...)
  find the right entry which has to be modified?

This becomes definitely difficult for large corporate directories
(100000 entries) which hold also a lot of other
attributes (phone number, ...).

2. Storage of Revocation lists in a X.500 server

- A person reads a certificate from a X.500 server; now the person wants
  to check if the certificate is still valid. So the person reads
  the revocation list and checks whether the serial number of the
  certificate is in the revocation list or not.
  This seems good until the revocation list becomes huge - every client
  would have to read a list of 10000 serial numbers of revoked certificates.
  Has anybody experiences with splitting revocation lists? What could be a
  "reasonable" size of a revocation list?

Thanks,
		Jochen.
------------

Dr. Jochen Keutel		currently at:	Deutsche Telekom	
duerr com-soft					IZ Darmstadt	

Phone: +49 6151 818 5525

e-mail: [email-masked]
	[email-masked]
X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
WWW   : http://www.geocities.com/WallStreet/3454/

From: Blake Ramsdell <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Symmetric algorithm OIDs (was: Re: DSA Algorithm Ids) -Reply
Date: Thu, 7 Nov 1996 17:44:54 -0800

>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Thursday, November 07, 1996 9:38 AM
>To: 	[email-masked]; [email-masked]
>Subject: 	Re: Symmetric algorithm OIDs (was: Re: DSA Algorithm Ids) -Reply
>
>Aren't we confusing two separate cases here?  It seems to me that one would
>put algorithms in a certificate primarily to support email confidentiality.
>Before I can send you an encrypted email message I need to know what you can
>handle, I think.  So there it makes sense to me to put supported algorithms
>in a key management type certificate.  Of course, if there is a really good
>directory service, there may not be a need to put this information in a
>certificate, but just to include it in the directory as a separate
>attribute.  I don't see much reason have to have a CA actually certify the
>supported algorithms; it's a question of giving the encrypted message
>originator all the information hem may need in one package.  

Two cents from the S/MIME camp here -- symmetric capabilities are
relayed on a message by message basis, not in the certificate (there is
a SET OF authenticatedAttributes that are signed by the sender, and one
of these is symmetricCapbilities).  The determination of the algorithm
is based on the last-transmitted algorithm capabilities (which reflects
preference order as well as capabilities.)

Blake

Date: Thu, 7 Nov 1996 19:32:29 -0500
To: Bob Jueneman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Symmetric algorithm OIDs (was: Re: DSA Algorithm Ids)    -Reply -Reply
Cc: [email-masked], [email-masked]

Bob,

	"SA" = Security Association.  That's what the SA stands for in ISAKMP.

Steve

Date: Thu, 07 Nov 1996 16:33:25 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Symmetric algorithm OIDs (was: Re: DSA Algorithm Ids)   -Reply -Reply

Interesting law, and perhaps valid.  But I'll bite -- what is "SA 
establishment"?

You do bring up a good point -- what happens to a certificate that 
becomes obsolete because a new algorithm was added? Clearly
it doesn't need or deserve to be revoked. It could be replaced or
simply deleted in a directory or database, and deleted from the list 
of certificates which an e-mail user distributes. Otherwise, do we care?

Bob

>>> Stephen Kent <[email-masked]> 11/07/96 03:08pm >>>
Bob,

	It's not clear that the algorithm OIDs need to be in the
certificate, vs. having them as additional SA parameters passed during SA
establishment. Remember Steve's Rule of Revocation (still to be
expermentially verified)

"The effective lifetime of a certificate is inversely proportional to the
square of the number of attributes contained in the certificate."

Steve

Date: Thu, 07 Nov 1996 16:21:02 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Storage of X.509 certificates in X.500 -Reply

An excellent question, and this is as good a place as 
any to discuss it.

[I'm personally very interested, as Novell is a member of the 
team (consisting of CertCo, Novell, Omnimark, and Zion Bank)
which will be implementing the certification authority and repository
infrastructure for the State of Utah in the US. Since Utah was the 
first governmental entity anywhere in the world to pass a 
digital signature law, they are probably going to be the first to 
have to wrestle with these issues across multiple CAs
and multiple user organizations. And that tends to imply a
more or less global directory, perhaps for  the first time.]

[I'm not sure that there is any "common practice" as yet. The few
public CAs I am aware of do not make their certificates available 
in X.500 as yet, and those products such as Nortel's Entrust that 
do interface to X.500 are typically used in a closed environment 
within one organization, where these issues are more tractable.]

When I was involved in the NADF, there was one fundamental
principle that came out -- regardless of the niceties of what 
someone thinks a name ought to mean or imply, you list 
information in a directory where users will tend to look for
it. So if you are the Hotel View Zahrzeiten in Munich, and you
wish to attract tourists from the US and Japan, in addition to Europe,
you will probably want to list in the New York, Washington, Miami,
Los Angeles, Tokyo, etc., directories, in addition to listing in
Germany/Deutschland.

If this principle is followed, certificates and other information may 
be listed in many different locations, perhaps as alias or seeAlsos,
or maybe just duplicate entries.

So in general, the relationship between directory entries and 
certificates is probably many to many. That is, the same 
certificate may be listed under quite a few different names,
in order to increase the probably that a user will find it. On the 
other hand, a single entry may contain multiple certificates,
including different algorithms, different key usages, and different
roles or names, including multiple e-mail names or machine names.

Regardless of the virtues or lack thereof of a Distinguished Name
for unambiguous identification, including the subject's DN in a 
certificate at least provides one obvious way to find that certificate, 
and to associate it with other information about the subject if you 
don't have any other.

But this is almost surely not going to be sufficient, especially if as 
expected the community makes extensive use of the 
alternateSubjectName attribute.  If all you know about someone is their
e-mail address, then that is where you should expect to find his 
certificate, whether it is an RFC822 or X.400 address, or perhaps
a proprietary format. Likewise, if all you know is someone's EDI number,
that's where you should look in the directory.

So as a minimum I would expect to find a primary entry under the 
subject's DN as listed in the certificate, and at least an alias under
each of the various alternate names.  Then you have to consider 
how the user might expect to be found, and put additional entries there
as well, whether the DN of the entry agrees with the DN in the
subject's certificate or not.

Have I made your life hard enough yet? Too bad, it's going to get
worse before it gets better.  We now have to discuss the awkward 
issue of the directory schema.

So long as Certification Authorities and directory administrators don't
talk to each other, they can independently choose whatever schema
for their DNs they would like. If one organization prefers to use commonName
with last name first, and the other first name first, that is fine, so long 
as they don't have to interoperate.

Unfortunately, perhaps, X.500 directories are generally not relational 
databases. Most directory implementations can efficiently look up a 
telephone number given a name, or a name given a telephone 
number, or a street address using either, but only if the appropriate
filters (search criteria) were predefined. Otherwise, the search 
ends up sweeping through the entire directory.

Now if one directory doesn't contain the desired information and you 
have to go through a referral mechanism, the two directory administrators
had better have defined a common schema, or the search will be very 
inefficient.

Although we tried to deal with this problem back in the PEM days 
(when there was only a single DN, and no alternate names), we never 
really nailed down the problem. So now the problem is even worse.

I would claim that there is virtually no common understanding as to 
what the allowable syntax and semantics are for the content of a
DN, even from among the set defined in X.521, much less any private
attributes. Worse yet, although there is a clear need to be able to distinguish
between two organizationalPersons who have the same name within
an organization (or two residentialPersons), there is no consensus
as to whether a multi-valued RDN is allowed.

So what we are probably going to have to do for Utah is to poll as many
of the various CAs as we can identify and ask them what their practices 
are, or more importantly, will be. So far, my attempts to gather this kind
of information have not met with a huge success -- some people seem 
to feel that the information is sort of proprietary, others aren't quite willing
to say because it might change, etc. So we may have to arbitrarily define
a directory schema, and let CAs and CA vendors object if their certificates 
can't be stored or retrieved.

We would probably be willing to publish the syntax and semantics of 
registered attributes, both quasi-standard and private attributes, but 
collecting the information seems a very daunting task.

I'm sorry if I have failed to brighten your day, but I see this as the tiny tip of
an enormous iceberg.

Bob

>>> Jochen Keutel <[email-masked]> 11/07/96 08:38am >>>
Hello,
  I'm not sure whether this is the right place to ask these
questions - if it's not the right place please direct me
to a more appropriate mailing list.

My Questions:

1. Storage of a X.509 certificate in a X.500 server

- Is it common practice to use the "subject" field of the
  certificate as distinguished name of the entry which holds
  the certificate as an attribute?
- If not - how does the client loading the certificates (CA, ...)
  find the right entry which has to be modified?

This becomes definitely difficult for large corporate directories
(100000 entries) which hold also a lot of other
attributes (phone number, ...).

2. Storage of Revocation lists in a X.500 server

- A person reads a certificate from a X.500 server; now the person wants
  to check if the certificate is still valid. So the person reads
  the revocation list and checks whether the serial number of the
  certificate is in the revocation list or not.
  This seems good until the revocation list becomes huge - every client
  would have to read a list of 10000 serial numbers of revoked certificates.
  Has anybody experiences with splitting revocation lists? What could be a
  "reasonable" size of a revocation list?

Thanks,
		Jochen.
------------

Dr. Jochen Keutel		currently at:	Deutsche Telekom	
duerr com-soft					IZ Darmstadt	

Phone: +49 6151 818 5525

e-mail: [email-masked]
	[email-masked]
X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
WWW   : http://www.geocities.com/WallStreet/3454/

Date: Thu, 7 Nov 1996 17:08:57 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Symmetric algorithm OIDs (was: Re: DSA Algorithm Ids)   -Reply
Cc: [email-masked]

Bob,

	It's not clear that the algorithm OIDs need to be in the
certificate, vs. having them as additional SA parameters passed during SA
establishment. Remember Steve's Rule of Revocation (still to be
expermentially verified)

"The effective lifetime of a certificate is inversely proportional to the
square of the number of attributes contained in the certificate."

Steve

Date: Thu, 07 Nov 1996 14:55:38 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Symmetric algorithm OIDs (was: Re: DSA Algorithm Ids) -Reply -Reply

The comments from David Kemp, Bill Burr, and Robert Moskowitz are 
enlightening, looking at the subject from different perspectives. Let me 
see if I can summarize them:

1.  There is relatively little question that if a ubiquitous directory were 
that could contain a list of supported algorithms, it might be quite useful.
However, some significant issues might arise as to what name should
be used to look up a given capability -- the user's DN or e-mail name,
the name of his web server, or his secure (IP) gateway. [We may face all
of those issues if we add the symmetric algorithm OID to the certificate,
as well, but presumably the certificates may6 have already been 
protocol.]

2.  In the absence of a global directory, but with some source of certificates
being available (even if received in band), including the symmetric algorithms 
available at the destination user's site in the certificate seems desirable in 
the case of e-mail, and apparently for IPsec as well (I'm not as up on 
IPsec as I ought to be, but I'll take Robert Moskowitz's word for it.)

3. In the case of a medium to higher-layer protocol, in particular SSL, 
negotiation of the desired algorithms is certainly easier, and therefore
inclusion in the certificate may not be a strong requirement. On the other
hand, having to request the available algorithms will either add additional 
messages flowing back and forth, or it will result in some considerable
additional complexity in the key exchange. Multiple keys, tagged with
their algorithm IDs, could be offered, all encrypted in the appropriate public
key. But since the choice of which public key algorithm to use had to be 
driven by the certificate(s) available, why not go ahead and use the 
available information to make an appropriate decision about the symmetric 
key? If I am encrypting something sensitive, I want to make the decision about
what algorithm to use, and not leave it to the recipient.

4. The potential issue of having the CA "certify" the available algorithms does
not seem particularly vital -- the CA certifies the public key algorithm, the
user's name, and other information provided as a representation of the user.
It's hard to imagine how the CA could be liable for any possible 
misrepresentation, but the attribute extension could be tagged as
NonVerified Subscriber Information, if necessary.

5. I confess that I don't understand David Kemp's point below:

>It seems like a bad idea to me for two reasons: supported algorithms
could change quite frequently (on a session-by-session basis), and
it muddies the trust relationships involved in the usage of certificates.

>1) As a Netscape user, I could be browsing the Internet at large with
either no or 40 bit crypto.  When I get to a particular location, I may
wish to use only 80 or 128 bits, even though that server may support
everything.  I just click the "supported algorithms" boxes to disable
whatever I don't want to use.  There is no reason for a CA to get
involved in that dynamic selection mechanism.

But what happens if that server does NOT support everything? I'm 
not suggesting that the CA get involved in the dynamic selection 
process, only that the algorithms available at the server be displayed 
for my choice. I can then choose what algorithm I will use to communicate
with the server, and presumably the server will use the same algorithm to 
communicate with me.

Or suppose that I don't care -- I'm just making a non-sensitive inquiry,
so I could use no encryption or 40 bit encryption.  But if the server
does care (perhaps it is a sensitive company database, or information
that is being sold), then the server might choose the strongest algorithm 
I had listed as available.

>Supporting symmetric algorithms and parameters in certificates doesn't
do any particular harm.  It just adds epsilon's worth of complexity
and provides (in my opinion) no benefit. To my mind, that's an ROI of
zero.

It appears that in at least some of the scenarios, including the symmetric 
algorithms available in the certificate would considerably simplify the
selection of an appropriate algorithm. Since it would appear that the 
number of algorithms may proliferate substantially in the coming years, 
especially if and as the controls on exportable cryptography may be 
loosened (while the controls on what cryptography may be imported or
used within other countries may be tightening), this would appear to 
be quite helpful.

Since the attribute is an extension, its use is optional, and so the impact on 
applications which choose to ignore it is nearly zero.

We haven't heard from any vendors of CA code (at least to my knowledge), 
but it wouldn't seem to me that including this attribute would be terribly difficult,
especially if there is any significant demand from the user community.

My bottom line conclusion is that since the attribute has already been defined
within the X.509 amendment, we ought to profile it as a desirable extension 
within the PKIX community.

Bob

From: [email-masked]
Sender: Post Master <[email-masked]>
To: Jochen Keutel <[email-masked]>
CC: [email-masked]
Date: Thu, 7 Nov 1996 21:31:00 +0000
Subject: Re: Storage of X.509 certificates in X.500
Priority: normal

Hi Jochen,

Here are some answers to your questions:

1. Yes; the subject name in a certificate is the DN of the
X.500 entry. So given a Directory Name, the certificate associated
with that name can be obtained from the Directory.

2. The possible size of CRLs is a known problem.

PKIs need to be carefully designed to ensure that the period of 
validity of certificates is matched with the likelyhood of revocation. 
For example, if on average, users in an organization leave or change 
positions every year, it would be unwise to have certificates which
have lifetimes >1 year. Note that it is possible to issue a new 
certificate without changing a user's key-pair.

In addition, the latest versions of CRLs (V2:1996) allow for "delta 
CRLs" in which only "updates" need to be distributed.

David
 
> From:          Jochen Keutel <[email-masked]>
> Subject:       Storage of X.509 certificates in X.500
> To:            [email-masked]
> Date:          Thu, 7 Nov 1996 16:38:10 +0100 (MEZ)
> Cc:            Alexander Groll <[email-masked]>

> Hello,
>   I'm not sure whether this is the right place to ask these
> questions - if it's not the right place please direct me
> to a more appropriate mailing list.
> 
> My Questions:
> 
> 1. Storage of a X.509 certificate in a X.500 server
> 
> - Is it common practice to use the "subject" field of the
>   certificate as distinguished name of the entry which holds
>   the certificate as an attribute?
> - If not - how does the client loading the certificates (CA, ...)
>   find the right entry which has to be modified?
> 
> This becomes definitely difficult for large corporate directories
> (100000 entries) which hold also a lot of other
> attributes (phone number, ...).
> 
> 2. Storage of Revocation lists in a X.500 server
> 
> - A person reads a certificate from a X.500 server; now the person wants
>   to check if the certificate is still valid. So the person reads
>   the revocation list and checks whether the serial number of the
>   certificate is in the revocation list or not.
>   This seems good until the revocation list becomes huge - every client
>   would have to read a list of 10000 serial numbers of revoked certificates.
>   Has anybody experiences with splitting revocation lists? What could be a
>   "reasonable" size of a revocation list?
> 
> Thanks,
> 		Jochen.
> ------------
> 
> Dr. Jochen Keutel		currently at:	Deutsche Telekom	
> duerr com-soft					IZ Darmstadt	
> 
> Phone: +49 6151 818 5525
> 
> e-mail: [email-masked]
> 	[email-masked]
> X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
> WWW   : http://www.geocities.com/WallStreet/3454/
> 

.......................................................
David Gray                      e-mail: [email-masked]
Formal Systems                http://www.iol.ie/~formal
4 Roebuck Castle
Roebuck Road
Clonskeagh
Dublin 14
Ireland
.......................................................

Date: Thu, 7 Nov 1996 09:37:52 -0500 (EST)
From: Bancroft Scott <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: DER Encodings of UTCTime
Status:   

On Thu, 6 Nov 1996, David Gray wrote:

> I notice that in Part 1 of the PKIX documents, it is recommended that
> UTCTime be encoded as YYMMDDHHMMZ and that 00 seconds should never be
> encoded.
> 
> The current version of DMS uses the YYMMDDHHMMZ format but the newest
> DMS documents (SDN.706) require a YYMMDDHHMMSSZ format even if the 
> seconds field is 00. In particular, SDN.706 states that this is 
> consistent with proposed corrections to DER.
> 
> I cannot find any requirements for SET. Are there any?
> 
> I have not seen the proposed corrections to DER, but would it not 
> make sense for PKIX, SET and DMS to use the same format, i.e.,
> YYMMDDHHMMSSZ?

A proposed corrigendum to correct this deficiency in the DER documentation
was approved at the last ISO/IEC SC21 ASN.1 meeting.  You will shortly be
able to obtain the formal corrigendum from ISO and ITUT-T.  Attached is a
copy of the draft technical corrigendum.

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Fax          :1-908-249-4636

                INFORMATION TECHNOLOGY - ASN.1 ENCODING RULES:
        SPECIFICATION OF BASIC ENCODING RULES (BER), CANONICAL ENCODING
              RULES (CER) AND DISTINGUISHED ENCODING RULES (DER)

                        DRAFT TECHNICAL CORRIGENDUM 2

1)  In 11.7.1 change "CCITT X.208-1" to "ITU-T Rec. X.680".

2)  Insert a new subclause 11.8 as shown below:

11.8  UTCTime

11.8.1  The encoding shall terminate with "Z", as described in the
ITU-T X.680 | ISO/IEC 8824-1 clause on UTCTime.

11.8.2  The seconds element shall always be present.

11.8.3  Midnight (GMT) shall be represented in the form:

       "YYMMDD000000Z"

where "YYMMDD" represents the day following the midnight in question.

11.8.4  Examples of valid representations:

        "920521000000Z"

        "920622123421Z"

        "920722132100Z"

11.8.5  Examples of invalid representations:

        "920520240000Z"      (midnight represented incorrectly)

        "9207221321Z"        (seconds of 00 omitted)

From: Jochen Keutel <[email-masked]>
Subject: Storage of X.509 certificates in X.500
To: [email-masked]
Date: Thu, 7 Nov 1996 16:38:10 +0100 (MEZ)
Cc: [email-masked] (Alexander Groll)
Status:   

Hello,
  I'm not sure whether this is the right place to ask these
questions - if it's not the right place please direct me
to a more appropriate mailing list.

My Questions:

1. Storage of a X.509 certificate in a X.500 server

- Is it common practice to use the "subject" field of the
  certificate as distinguished name of the entry which holds
  the certificate as an attribute?
- If not - how does the client loading the certificates (CA, ...)
  find the right entry which has to be modified?

This becomes definitely difficult for large corporate directories
(100000 entries) which hold also a lot of other
attributes (phone number, ...).

2. Storage of Revocation lists in a X.500 server

- A person reads a certificate from a X.500 server; now the person wants
  to check if the certificate is still valid. So the person reads
  the revocation list and checks whether the serial number of the
  certificate is in the revocation list or not.
  This seems good until the revocation list becomes huge - every client
  would have to read a list of 10000 serial numbers of revoked certificates.
  Has anybody experiences with splitting revocation lists? What could be a
  "reasonable" size of a revocation list?

Thanks,
		Jochen.
------------

Dr. Jochen Keutel		currently at:	Deutsche Telekom	
duerr com-soft					IZ Darmstadt	

Phone: +49 6151 818 5525

e-mail: [email-masked]
	[email-masked]
X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
WWW   : http://www.geocities.com/WallStreet/3454/

Date: Thu, 7 Nov 1996 09:00:18 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Symmetric algorithm OIDs (was: Re: DSA Algorithm Ids) -Reply
Status:   

> From: Bob Jueneman <[email-masked]>
>
> But why do you believe that it would be an "especially bad idea" to have the
> CA convey the availability of particular algorithms in a certificate? If
> necessary, a CA's Certification Practice Statement could identity
> that extension as representing NonVerified Subscriber Information.
> 
> And in some other cases, e.g., in a corporate setting where the Chief
> Information Officer wishes to ensure a minimum level of security, it
> might be important for the CA to limit the choices that might be available 
> for use by users.
> 
> In any case is doesn't seem to do any particular harm, and might be 
> pretty helpful.

It seems like a bad idea to me for two reasons: supported algorithms
could change quite frequently (on a session-by-session basis), and
it muddys the trust relationships involved in the usage of certificates.

1) As a Netscape user, I could be browsing the Internet at large with
either no or 40 bit crypto.  When I get to a particular location, I may
wish to use only 80 or 128 bits, even though that server may support
everything.  I just click the "supported algorithms" boxes to disable
whatever I don't want to use.  There is no reason for a CA to get
involved in that dynamic selection mechanism.

2) I see certificates as an enabler of capabilities based on trust.
I believe they are much less useful as a disabler (i.e. a mechanism
to enforce mandatory restrictions).  If the CIO at company A wants to
prevent users at company A from using less than the minimum required
algorithms, he needs to install company-configured software that
enforces the policy, and also institute administrative policies that
prohibit users from installing their own software or modifying the
company-provided capability.  It's possible that certificates could
be involved in the configuration database, but involving a CA in the
process adds zero value, so why bother?

Supporting symmetric algorithms and parameters in certificates doesn't
do any particular harm.  It just adds epsilon's worth of complexity
and provides (in my opinion) no benefit. To my mind, that's an ROI of
zero.

From: <[email-masked]>
Sender: Post Master <[email-masked]>
To: [email-masked]
Date: Wed, 6 Nov 1996 21:19:21 +0000
Subject: DER Encoding of UTCTime
Priority: normal
Info: Evaluation version at ntdev.signet.org.au
Original-Content-Type: text/plain
Info: Evaluation version at ntdev.signet.org.au
Original-Content-Type: text/plain
Status:   

I notice that in Part 1 of the PKIX documents, it is recommended that
UTCTime be encoded as YYMMDDHHMMZ and that 00 seconds should never be
encoded.

The current version of DMS uses the YYMMDDHHMMZ format but the newest
DMS documents (SDN.706) require a YYMMDDHHMMSSZ format even if the
seconds field is 00. In particular, SDN.706 states that this is
consistent with proposed corrections to DER.

I cannot find any requirements for SET. Are there any?

I have not seen the proposed corrections to DER, but would it not make
sense for PKIX, SET and DMS to use the same format, i.e.,
YYMMDDHHMMSSZ?

GeneralizedTime is another days work!

David

.......................................................
David Gray                      e-mail: [email-masked]
Formal Systems                http://www.iol.ie/~formal
4 Roebuck Castle
Roebuck Road
Clonskeagh
Dublin 14
Ireland
.......................................................

From: Sri Vidya Rajagopal <[email-masked]>
Subject: unsubscribe
To: [email-masked]
Date: Wed, 06 Nov 1996 14:37:14 PST
Info: Evaluation version at ntdev.signet.org.au
Original-Content-Type: text/plain
Info: Evaluation version at ntdev.signet.org.au
Original-Content-Type: text/plain
Status:   

unsubscribe [email-masked]

From: "Robin Garner" <[email-masked]>
To: <[email-masked]>
Subject: unsubscribe
Date: Thu, 7 Nov 1996 22:55:49 +1100
Status:   

unsubscribe

Reply-To: [email-masked]
Date: Thu, 07 Nov 1996 14:20:44 -0500
To: [email-masked] (Bill Burr), [email-masked] (David P. Kemp), [email-masked]
From: Robert Moskowitz <[email-masked]>
Subject: Re: Symmetric algorithm OIDs (was: Re: DSA Algorithm Ids) -Reply

At 12:38 PM 11/7/96 -0500, Bill Burr wrote:
>Aren't we confusing two separate cases here?  It seems to me that one would
>put algorithms in a certificate primarily to support email confidentiality.
>Before I can send you an encrypted email message I need to know what you can
>handle, I think.  So there it makes sense to me to put supported algorithms
>in a key management type certificate.  Of course, if there is a really good
>directory service, there may not be a need to put this information in a
>certificate, but just to include it in the directory as a separate
>attribute.  I don't see much reason have to have a CA actually certify the
>supported algorithms; it's a question of giving the encrypted message
>originator all the information hem may need in one package.  
>
>But for an on-line secure session, i.e. SSL, a direct negotiation may be
>preferable, and there's no particular benifit to having the supported
>algorithms in the certificate.  

But if we are talking about IPsec using Oakley/ISAKMP and needing to
negotiate the crypto for the session, having the valid algorithms (note
plural) in the cert would be of emmense aid.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

From: Peter Whittaker <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Storage of X.509 certificates in X.500
Date: Thu, 7 Nov 1996 12:35:05 -0500
Encoding: 54 TEXT

>1. Storage of a X.509 certificate in a X.500 server
>
>- Is it common practice to use the "subject" field of the
>  certificate as distinguished name of the entry which holds
>  the certificate as an attribute?

If the subject name is a DN, then it is generally the case that the
certificate will be stored in the
entry with that DN (I'm not sure that it makes any sense to store it
elsewhere).  What does it mean
if the DN of the entry references one person, but the DN on the
certificate references someone else?

>- If not - how does the client loading the certificates (CA, ...)
>  find the right entry which has to be modified?

If the subject name is something else, i.e., one of the alternate names
allowed by V3 certificates,
then presumably one would populate the entry that held the certificate
with a corresponding attribute
to hold the alternate name, i.e., an email address, etc.
>
>2. Storage of Revocation lists in a X.500 server
>
>- A person reads a certificate from a X.500 server; now the person wants
>  to check if the certificate is still valid. So the person reads
>  the revocation list and checks whether the serial number of the
>  certificate is in the revocation list or not.
>  This seems good until the revocation list becomes huge - every client
>  would have to read a list of 10000 serial numbers of revoked certificates.
>  Has anybody experiences with splitting revocation lists? What could be a
  "reasonable" size of a revocation list?

This is the problem with V[12] certificates:  there is one and only one
cRL, and it is held in the CA's
entry.  V3 certificates allow the use of cRLDistributionPoint entries:
when the certificate is created,
the CA writes into the certificate the DN of the entry that would
contain the cRL on which that certificate's
serial number would be listed were that certificate to be revoked.  The
CA then chooses a reasonable
certificates to cRL mapping based on expected certificate revocation
numbers, e.g., based on the
tradeoff between length of validity period and expected rates of
compromise or user removal from the
system.  The CA creates entries of object class cRLDistributionPoint as
needed to implement this
strategy.

In other words, you'll have to experiment and decide what's right for
your installation.

pww

Date: Thu, 07 Nov 1996 12:38:12 -0500
To: [email-masked] (David P. Kemp), [email-masked]
From: [email-masked] (Bill Burr)
Subject: Re: Symmetric algorithm OIDs (was: Re: DSA Algorithm Ids) -Reply

Aren't we confusing two separate cases here?  It seems to me that one would
put algorithms in a certificate primarily to support email confidentiality.
Before I can send you an encrypted email message I need to know what you can
handle, I think.  So there it makes sense to me to put supported algorithms
in a key management type certificate.  Of course, if there is a really good
directory service, there may not be a need to put this information in a
certificate, but just to include it in the directory as a separate
attribute.  I don't see much reason have to have a CA actually certify the
supported algorithms; it's a question of giving the encrypted message
originator all the information hem may need in one package.  

But for an on-line secure session, i.e. SSL, a direct negotiation may be
preferable, and there's no particular benifit to having the supported
algorithms in the certificate.  

>> From: Bob Jueneman <[email-masked]>
>>
>> But why do you believe that it would be an "especially bad idea" to have the
>> CA convey the availability of particular algorithms in a certificate? If
>> necessary, a CA's Certification Practice Statement could identity
>> that extension as representing NonVerified Subscriber Information.
>> 
>> And in some other cases, e.g., in a corporate setting where the Chief
>> Information Officer wishes to ensure a minimum level of security, it
>> might be important for the CA to limit the choices that might be available 
>> for use by users.
>> 
>> In any case is doesn't seem to do any particular harm, and might be 
>> pretty helpful.
>
>
>It seems like a bad idea to me for two reasons: supported algorithms
>could change quite frequently (on a session-by-session basis), and
>it muddys the trust relationships involved in the usage of certificates.
>
>1) As a Netscape user, I could be browsing the Internet at large with
>either no or 40 bit crypto.  When I get to a particular location, I may
>wish to use only 80 or 128 bits, even though that server may support
>everything.  I just click the "supported algorithms" boxes to disable
>whatever I don't want to use.  There is no reason for a CA to get
>involved in that dynamic selection mechanism.
>
>2) I see certificates as an enabler of capabilities based on trust.
>I believe they are much less useful as a disabler (i.e. a mechanism
>to enforce mandatory restrictions).  If the CIO at company A wants to
>prevent users at company A from using less than the minimum required
>algorithms, he needs to install company-configured software that
>enforces the policy, and also institute administrative policies that
>prohibit users from installing their own software or modifying the
>company-provided capability.  It's possible that certificates could
>be involved in the configuration database, but involving a CA in the
>process adds zero value, so why bother?
>
>
>Supporting symmetric algorithms and parameters in certificates doesn't
>do any particular harm.  It just adds epsilon's worth of complexity
>and provides (in my opinion) no benefit. To my mind, that's an ROI of
>zero.
>
>

Regards,

Bill Burr
301-975-2914
http://www.nist.gov/itl/div877/staff/burr/

From: Jochen Keutel <[email-masked]>
Subject: Storage of X.509 certificates in X.500
To: [email-masked]
Date: Thu, 7 Nov 1996 16:38:10 +0100 (MEZ)
Cc: [email-masked] (Alexander Groll)
Content-Length: 1532

Hello,
  I'm not sure whether this is the right place to ask these
questions - if it's not the right place please direct me
to a more appropriate mailing list.

My Questions:

1. Storage of a X.509 certificate in a X.500 server

- Is it common practice to use the "subject" field of the
  certificate as distinguished name of the entry which holds
  the certificate as an attribute?
- If not - how does the client loading the certificates (CA, ...)
  find the right entry which has to be modified?

This becomes definitely difficult for large corporate directories
(100000 entries) which hold also a lot of other
attributes (phone number, ...).

2. Storage of Revocation lists in a X.500 server

- A person reads a certificate from a X.500 server; now the person wants
  to check if the certificate is still valid. So the person reads
  the revocation list and checks whether the serial number of the
  certificate is in the revocation list or not.
  This seems good until the revocation list becomes huge - every client
  would have to read a list of 10000 serial numbers of revoked certificates.
  Has anybody experiences with splitting revocation lists? What could be a
  "reasonable" size of a revocation list?

Thanks,
		Jochen.
------------

Dr. Jochen Keutel		currently at:	Deutsche Telekom	
duerr com-soft					IZ Darmstadt	

Phone: +49 6151 818 5525

e-mail: [email-masked]
	[email-masked]
X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
WWW   : http://www.geocities.com/WallStreet/3454/

Date: Thu, 7 Nov 1996 09:37:52 -0500 (EST)
From: Bancroft Scott <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: DER Encodings of UTCTime
Content-Length: 2231

On Thu, 6 Nov 1996, David Gray wrote:

> I notice that in Part 1 of the PKIX documents, it is recommended that
> UTCTime be encoded as YYMMDDHHMMZ and that 00 seconds should never be
> encoded.
> 
> The current version of DMS uses the YYMMDDHHMMZ format but the newest
> DMS documents (SDN.706) require a YYMMDDHHMMSSZ format even if the 
> seconds field is 00. In particular, SDN.706 states that this is 
> consistent with proposed corrections to DER.
> 
> I cannot find any requirements for SET. Are there any?
> 
> I have not seen the proposed corrections to DER, but would it not 
> make sense for PKIX, SET and DMS to use the same format, i.e.,
> YYMMDDHHMMSSZ?

A proposed corrigendum to correct this deficiency in the DER documentation
was approved at the last ISO/IEC SC21 ASN.1 meeting.  You will shortly be
able to obtain the formal corrigendum from ISO and ITUT-T.  Attached is a
copy of the draft technical corrigendum.

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Fax          :1-908-249-4636

                INFORMATION TECHNOLOGY - ASN.1 ENCODING RULES:
        SPECIFICATION OF BASIC ENCODING RULES (BER), CANONICAL ENCODING
              RULES (CER) AND DISTINGUISHED ENCODING RULES (DER)

                        DRAFT TECHNICAL CORRIGENDUM 2

1)  In 11.7.1 change "CCITT X.208-1" to "ITU-T Rec. X.680".

2)  Insert a new subclause 11.8 as shown below:

11.8  UTCTime

11.8.1  The encoding shall terminate with "Z", as described in the
ITU-T X.680 | ISO/IEC 8824-1 clause on UTCTime.

11.8.2  The seconds element shall always be present.

11.8.3  Midnight (GMT) shall be represented in the form:

       "YYMMDD000000Z"

where "YYMMDD" represents the day following the midnight in question.

11.8.4  Examples of valid representations:

        "920521000000Z"

        "920622123421Z"

        "920722132100Z"

11.8.5  Examples of invalid representations:

        "920520240000Z"      (midnight represented incorrectly)

        "9207221321Z"        (seconds of 00 omitted)

Date: Thu, 7 Nov 1996 09:00:18 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Symmetric algorithm OIDs (was: Re: DSA Algorithm Ids) -Reply

> From: Bob Jueneman <[email-masked]>
>
> But why do you believe that it would be an "especially bad idea" to have the
> CA convey the availability of particular algorithms in a certificate? If
> necessary, a CA's Certification Practice Statement could identity
> that extension as representing NonVerified Subscriber Information.
> 
> And in some other cases, e.g., in a corporate setting where the Chief
> Information Officer wishes to ensure a minimum level of security, it
> might be important for the CA to limit the choices that might be available 
> for use by users.
> 
> In any case is doesn't seem to do any particular harm, and might be 
> pretty helpful.

It seems like a bad idea to me for two reasons: supported algorithms
could change quite frequently (on a session-by-session basis), and
it muddys the trust relationships involved in the usage of certificates.

1) As a Netscape user, I could be browsing the Internet at large with
either no or 40 bit crypto.  When I get to a particular location, I may
wish to use only 80 or 128 bits, even though that server may support
everything.  I just click the "supported algorithms" boxes to disable
whatever I don't want to use.  There is no reason for a CA to get
involved in that dynamic selection mechanism.

2) I see certificates as an enabler of capabilities based on trust.
I believe they are much less useful as a disabler (i.e. a mechanism
to enforce mandatory restrictions).  If the CIO at company A wants to
prevent users at company A from using less than the minimum required
algorithms, he needs to install company-configured software that
enforces the policy, and also institute administrative policies that
prohibit users from installing their own software or modifying the
company-provided capability.  It's possible that certificates could
be involved in the configuration database, but involving a CA in the
process adds zero value, so why bother?

Supporting symmetric algorithms and parameters in certificates doesn't
do any particular harm.  It just adds epsilon's worth of complexity
and provides (in my opinion) no benefit. To my mind, that's an ROI of
zero.

Subject: Re: Euro Key Escrow
To: [email-masked]
Date: Thu, 7 Nov 1996 13:42:16 +0100 (NFT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: [email-masked] (Ulf =?ISO-8859-1?Q?M=F6ller?=)
Content-Length: 1286

> It is, apparently, true that the EC is considering schemes for key escrow, by
> "trusted third parties"

There is an extensive survey at the European Cryptography Resources page,
http://www.modeemi.cs.tut.fi/~avs/eu-crypto.html

The EU commission's group DG XIII has been discussing key escrow for quite
some time, but they have not yet been able to agree on a position.
Jerome Thorel has posted some rather scaring interviews with EU official
David Herson who is in favor of a key esrow scheme. Victor Mayer-Schoenfelder
reports that crpyo regulation is likely to be delegated to the more liberal
DG XV.

A number of member states, such as Denmark, very unlikely to accept key
escrow.

> ftp://ftp.dcs.rhbnc.ac.uk/pub/Chris.Mitchell/istr_a2.ps

Ross Anderson has analyzed Mitchell's scheme, drawing the conclusion that
"The GCHQ protocal is very poorly engineered." See
ftp://ftp.cl.cam.ac.uk/users/rja14/euroclipper.ps.Z

> I'm informed that this is likely to be introduced into EC legislation, though
> my understanding is that members are not required to actually incorporate the
> legislation. No doubt France will embrace it with happy shouts.

The final decision will almost certainly with the member states, because
cryptography is considered essential for national security.

From: "Robin Garner" <[email-masked]>
To: <[email-masked]>
Subject: unsubscribe
Date: Thu, 7 Nov 1996 22:55:49 +1100

unsubscribe

Subject: Euro Key Escrow
To: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Thu, 7 Nov 1996 09:21:55 +0000 (GMT)
From: Ben Laurie <[email-masked]>
Cc: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at heap.ben.algroup.co.uk
Reply-To: [email-masked]
Content-Length: 1601      

Someone, somewhere, posted a rumour that Europe was about to go for a key
escrow scheme known as "Royal Holloway".

I have done a little research and gleaned the following:

It is, apparently, true that the EC is considering schemes for key escrow, by
"trusted third parties" (trusted by who, I'd like to know?). "Royal Holloway"
is one of these schemes. It is named after the college of origin, if anyone
cares. It essentially revolves around each pair of TTPs sharing two out of
three parts of a key, and generating the third part for each of their users.
The idea is that either of the TTPs who generated keys for an encrypted
message exchange can decode it (by using the private key of their "client" and
the public key of the other TTP's "client").

Full details can be found at:

ftp://ftp.dcs.rhbnc.ac.uk/pub/Chris.Mitchell/istr_a2.ps

This is in PostScript. I'm not aware of any plain text versions.

I'm informed that this is likely to be introduced into EC legislation, though
my understanding is that members are not required to actually incorporate the
legislation. No doubt France will embrace it with happy shouts.

Of course, it is our duty as netizens to resist this kind of rubbish, and I
encourage you to write to your MP/EuroMP (or local equivalent).

Cheers,

Ben.

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

Date: Wed, 06 Nov 1996 09:29:54 -0500
To: [email-masked]
From: [email-masked] (Bill Burr)
Subject: Re: Symmetric algorithm OIDs and back to DSA Algorithm OIDs
Info: Evaluation version at ntdev.signet.org.au
Info: Evaluation version at ntdev.signet.org.au
Status:   

My understanding of what Warwick proposed for  supported symmetric key
algorithms  is that the subJectDirectoryAttributes certificate extension,
which I believe allows any directory attribute to be included in
certificates, be used to carry OIDs for supported symmetric key algorithms.
This would then include the supported algorithms in the ecertificate itself,
and, if you had the certificate, you would have the supported algorithms.

Also, if we're discusing symmetric key algorithm OIDs, we must remember Ron
Rivest's earlier comment about parameters for symmetric key algorithms.
Several of the more recent algorithms (i.e., RC5 and Blowfish) have at least
three parameters: key size, word size and number of rounds.  We either will
need separate OIDs for various common combinations of these, or a mechanism
for stating the parameter range supported (I assume that all implementations
may not support any arbitrary parameter range), and the parameters actually
used.

All this is a digression, however, from Warwick's initial question about DSS
OIDs.  I believe that Warwick's question was prompted by a discussion in the
Federal PKI Working Group about the best OIDs to use in Federal DSS
certificates.  We are trying to pick the DSS OIDs for Federal use, and want
to know who might be impacted if we pick the X9.57 DSS OIDs, because thay
are already using the OIDs defined for by the OIW.  So I would like to
repeat Warwick's question that started this thread, since nearly all the
responses have been about OIDs for symmetric keys, a worthy but different
subject.

> From: Warwick Ford: [email-masked]
>
>We need (1) an OID for dsaWithSha-1, with no parameters, for use in the
>certificate signature and the SIGNED macro fields; and (2) an OID for dsa,
>with optional parameters, for use in subjectPublicKeyInfo.  Both X9 and the
>OIW have algorithms defined.
>
>For (1), the obvious candidate is X9.57 OID { x9algorithm 3 }, since no OIW
>algorithm is defined with the parameter done right.
>
>For (2), we could either use X9.57's { x9algorithm 1 } or the OIW's {
>algorithm 12 }.  Both are the same.  For consistency we should maybe use the
>X9 one.  Do any implementors have a serious preference for one or the other
>(because of use in existing product).
>
>Warwick

>
>> From: Bob Jueneman <[email-masked]>
>> 
>> The problem is even worse than Jan describes. In addition to the DES 
>> flavor of the month, there is RC2 and RC4, maybe RC5, IDEA, and
>> probably some proprietary (per country) algorithms as well.
>> 
>> Over and above that, there will soon be the issue of what e-mail, SSL, etc.,
>> protocols a given site can support.
>> 
>> Sooner or later, people are going to recognize that a directory would 
>> be an awfully handy way to solve these problems. But until that
>> happens, I would support including a suite of supported hash and 
>> symmetric key encryption algorithms within a certificate as a PKIX
>> defined extension attribute.
>
>For email, using a directory to identify the symmetric algorithm(s)
>supported by the recipient is useful.  However, for online protocols
>(IPSEC, SSL, etc) the peer's capabilities can be discovered at
>connection establishment time, and it's probably a bad idea to
>rely on setting up a connection to a third party just to determine
>what algorithms are supported by the first two.   It sounds like an
>especially bad idea to have CAs vouch for the availability of
>particular algorithms at a particular party, which is what embedding
>symmetric algorithm IDs into extension attributes would accomplish.
>
>In any case, Jan's question wasn't about how to transfer the algorithm
>information, it was about how to represent it.  Assigning OIDs capable
>of representing symmetric key sizes and other parameters/options is useful
>in and of itself, regardless of the data structures containing the OIDs
>or the methods used to transmit them.
>
>

Regards,

Bill Burr
301-975-2914
http://www.nist.gov/itl/div877/staff/burr/

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Bill Burr'" <[email-masked]>
Subject: RE: Symmetric algorithm OIDs and back to DSA Algorithm OIDs
Date: Wed, 6 Nov 1996 15:18:19 -0800
Info: Evaluation version at ntdev.signet.org.au
Status:   

Where a DSA key is used as input to either a signing or a key agreement
algoirhtm, should the subectPublicKey oid  indicate which mechanism/algoirhtm is intended,
if not both, or should it merely indicate the format/encoding of said field?

If the mechanism is to be constrained, this suggests at least three DSA oids.

Where there are multiple key agreement algorithms which use  a DSA key as input,
should said oid should be different, per algoirhtm?

V3 extensions facilitate specification of mechanism, which a DSA key may
be purposed for. v3 std extensions do not seem to faciliate spec of which
algorithm a DSA key is constrained to, unless constrained by
the subjectPublicKey Oid.

 
----------
From: 	Bill Burr
Sent: 	Wednesday, November 06, 1996 6:29 AM
To: 	[email-masked]
Subject: 	Re: Symmetric algorithm OIDs and back to DSA Algorithm OIDs

My understanding of what Warwick proposed for  supported symmetric key
algorithms  is that the subJectDirectoryAttributes certificate extension,
which I believe allows any directory attribute to be included in
certificates, be used to carry OIDs for supported symmetric key algorithms.
This would then include the supported algorithms in the ecertificate itself,
and, if you had the certificate, you would have the supported algorithms.

Also, if we're discusing symmetric key algorithm OIDs, we must remember Ron
Rivest's earlier comment about parameters for symmetric key algorithms.
Several of the more recent algorithms (i.e., RC5 and Blowfish) have at least
three parameters: key size, word size and number of rounds.  We either will
need separate OIDs for various common combinations of these, or a mechanism
for stating the parameter range supported (I assume that all implementations
may not support any arbitrary parameter range), and the parameters actually
used.

All this is a digression, however, from Warwick's initial question about DSS
OIDs.  I believe that Warwick's question was prompted by a discussion in the
Federal PKI Working Group about the best OIDs to use in Federal DSS
certificates.  We are trying to pick the DSS OIDs for Federal use, and want
to know who might be impacted if we pick the X9.57 DSS OIDs, because thay
are already using the OIDs defined for by the OIW.  So I would like to
repeat Warwick's question that started this thread, since nearly all the
responses have been about OIDs for symmetric keys, a worthy but different
subject.

> From: Warwick Ford: [email-masked]
>
>We need (1) an OID for dsaWithSha-1, with no parameters, for use in the
>certificate signature and the SIGNED macro fields; and (2) an OID for dsa,
>with optional parameters, for use in subjectPublicKeyInfo.  Both X9 and the
>OIW have algorithms defined.
>
>For (1), the obvious candidate is X9.57 OID { x9algorithm 3 }, since no OIW
>algorithm is defined with the parameter done right.
>
>For (2), we could either use X9.57's { x9algorithm 1 } or the OIW's {
>algorithm 12 }.  Both are the same.  For consistency we should maybe use the
>X9 one.  Do any implementors have a serious preference for one or the other
>(because of use in existing product).
>
>Warwick

>
>> From: Bob Jueneman <[email-masked]>
>> 
>> The problem is even worse than Jan describes. In addition to the DES 
>> flavor of the month, there is RC2 and RC4, maybe RC5, IDEA, and
>> probably some proprietary (per country) algorithms as well.
>> 
>> Over and above that, there will soon be the issue of what e-mail, SSL, etc.,
>> protocols a given site can support.
>> 
>> Sooner or later, people are going to recognize that a directory would 
>> be an awfully handy way to solve these problems. But until that
>> happens, I would support including a suite of supported hash and 
>> symmetric key encryption algorithms within a certificate as a PKIX
>> defined extension attribute.
>
>For email, using a directory to identify the symmetric algorithm(s)
>supported by the recipient is useful.  However, for online protocols
>(IPSEC, SSL, etc) the peer's capabilities can be discovered at
>connection establishment time, and it's probably a bad idea to
>rely on setting up a connection to a third party just to determine
>what algorithms are supported by the first two.   It sounds like an
>especially bad idea to have CAs vouch for the availability of
>particular algorithms at a particular party, which is what embedding
>symmetric algorithm IDs into extension attributes would accomplish.
>
>In any case, Jan's question wasn't about how to transfer the algorithm
>information, it was about how to represent it.  Assigning OIDs capable
>of representing symmetric key sizes and other parameters/options is useful
>in and of itself, regardless of the data structures containing the OIDs
>or the methods used to transmit them.
>
>

Regards,

Bill Burr
301-975-2914
http://www.nist.gov/itl/div877/staff/burr/

From: Sri Vidya Rajagopal <[email-masked]>
Subject: unsubscribe
To: [email-masked]
Date: Wed, 06 Nov 1996 14:37:14 PST
Info: Evaluation version at ntdev.signet.org.au
Original-Content-Type: text/plain
Status:   

unsubscribe [email-masked]

From: <[email-masked]>
Sender: Post Master <[email-masked]>
To: [email-masked]
Date: Wed, 6 Nov 1996 21:19:21 +0000
Subject: DER Encoding of UTCTime
Priority: normal
Info: Evaluation version at ntdev.signet.org.au
Original-Content-Type: text/plain
Status:   

I notice that in Part 1 of the PKIX documents, it is recommended that
UTCTime be encoded as YYMMDDHHMMZ and that 00 seconds should never be
encoded.

The current version of DMS uses the YYMMDDHHMMZ format but the newest
DMS documents (SDN.706) require a YYMMDDHHMMSSZ format even if the
seconds field is 00. In particular, SDN.706 states that this is
consistent with proposed corrections to DER.

I cannot find any requirements for SET. Are there any?

I have not seen the proposed corrections to DER, but would it not make
sense for PKIX, SET and DMS to use the same format, i.e.,
YYMMDDHHMMSSZ?

GeneralizedTime is another days work!

David

.......................................................
David Gray                      e-mail: [email-masked]
Formal Systems                http://www.iol.ie/~formal
4 Roebuck Castle
Roebuck Road
Clonskeagh
Dublin 14
Ireland
.......................................................

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Bill Burr'" <[email-masked]>
Subject: RE: Symmetric algorithm OIDs and back to DSA Algorithm OIDs
Date: Wed, 6 Nov 1996 15:18:19 -0800
Status:   

Where a DSA key is used as input to either a signing or a key agreement
algoirhtm, should the subectPublicKey oid  indicate which mechanism/algoirhtm is intended,
if not both, or should it merely indicate the format/encoding of said field?

If the mechanism is to be constrained, this suggests at least three DSA oids.

Where there are multiple key agreement algorithms which use  a DSA key as input,
should said oid should be different, per algoirhtm?

V3 extensions facilitate specification of mechanism, which a DSA key may
be purposed for. v3 std extensions do not seem to faciliate spec of which
algorithm a DSA key is constrained to, unless constrained by
the subjectPublicKey Oid.

 
----------
From: 	Bill Burr
Sent: 	Wednesday, November 06, 1996 6:29 AM
To: 	[email-masked]
Subject: 	Re: Symmetric algorithm OIDs and back to DSA Algorithm OIDs

My understanding of what Warwick proposed for  supported symmetric key
algorithms  is that the subJectDirectoryAttributes certificate extension,
which I believe allows any directory attribute to be included in
certificates, be used to carry OIDs for supported symmetric key algorithms.
This would then include the supported algorithms in the ecertificate itself,
and, if you had the certificate, you would have the supported algorithms.

Also, if we're discusing symmetric key algorithm OIDs, we must remember Ron
Rivest's earlier comment about parameters for symmetric key algorithms.
Several of the more recent algorithms (i.e., RC5 and Blowfish) have at least
three parameters: key size, word size and number of rounds.  We either will
need separate OIDs for various common combinations of these, or a mechanism
for stating the parameter range supported (I assume that all implementations
may not support any arbitrary parameter range), and the parameters actually
used.

All this is a digression, however, from Warwick's initial question about DSS
OIDs.  I believe that Warwick's question was prompted by a discussion in the
Federal PKI Working Group about the best OIDs to use in Federal DSS
certificates.  We are trying to pick the DSS OIDs for Federal use, and want
to know who might be impacted if we pick the X9.57 DSS OIDs, because thay
are already using the OIDs defined for by the OIW.  So I would like to
repeat Warwick's question that started this thread, since nearly all the
responses have been about OIDs for symmetric keys, a worthy but different
subject.

> From: Warwick Ford: [email-masked]
>
>We need (1) an OID for dsaWithSha-1, with no parameters, for use in the
>certificate signature and the SIGNED macro fields; and (2) an OID for dsa,
>with optional parameters, for use in subjectPublicKeyInfo.  Both X9 and the
>OIW have algorithms defined.
>
>For (1), the obvious candidate is X9.57 OID { x9algorithm 3 }, since no OIW
>algorithm is defined with the parameter done right.
>
>For (2), we could either use X9.57's { x9algorithm 1 } or the OIW's {
>algorithm 12 }.  Both are the same.  For consistency we should maybe use the
>X9 one.  Do any implementors have a serious preference for one or the other
>(because of use in existing product).
>
>Warwick

>
>> From: Bob Jueneman <[email-masked]>
>> 
>> The problem is even worse than Jan describes. In addition to the DES 
>> flavor of the month, there is RC2 and RC4, maybe RC5, IDEA, and
>> probably some proprietary (per country) algorithms as well.
>> 
>> Over and above that, there will soon be the issue of what e-mail, SSL, etc.,
>> protocols a given site can support.
>> 
>> Sooner or later, people are going to recognize that a directory would 
>> be an awfully handy way to solve these problems. But until that
>> happens, I would support including a suite of supported hash and 
>> symmetric key encryption algorithms within a certificate as a PKIX
>> defined extension attribute.
>
>For email, using a directory to identify the symmetric algorithm(s)
>supported by the recipient is useful.  However, for online protocols
>(IPSEC, SSL, etc) the peer's capabilities can be discovered at
>connection establishment time, and it's probably a bad idea to
>rely on setting up a connection to a third party just to determine
>what algorithms are supported by the first two.   It sounds like an
>especially bad idea to have CAs vouch for the availability of
>particular algorithms at a particular party, which is what embedding
>symmetric algorithm IDs into extension attributes would accomplish.
>
>In any case, Jan's question wasn't about how to transfer the algorithm
>information, it was about how to represent it.  Assigning OIDs capable
>of representing symmetric key sizes and other parameters/options is useful
>in and of itself, regardless of the data structures containing the OIDs
>or the methods used to transmit them.
>
>

Regards,

Bill Burr
301-975-2914
http://www.nist.gov/itl/div877/staff/burr/

From: Sri Vidya Rajagopal <[email-masked]>
Subject: unsubscribe
To: [email-masked]
Date: Wed, 06 Nov 1996 14:37:14 PST
Status:   

unsubscribe [email-masked]

Date: Wed, 06 Nov 1996 09:29:54 -0500
To: [email-masked]
From: [email-masked] (Bill Burr)
Subject: Re: Symmetric algorithm OIDs and back to DSA Algorithm OIDs
Info: Evaluation version at ntdev.signet.org.au
Status:   

My understanding of what Warwick proposed for  supported symmetric key
algorithms  is that the subJectDirectoryAttributes certificate extension,
which I believe allows any directory attribute to be included in
certificates, be used to carry OIDs for supported symmetric key algorithms.
This would then include the supported algorithms in the ecertificate itself,
and, if you had the certificate, you would have the supported algorithms.

Also, if we're discusing symmetric key algorithm OIDs, we must remember Ron
Rivest's earlier comment about parameters for symmetric key algorithms.
Several of the more recent algorithms (i.e., RC5 and Blowfish) have at least
three parameters: key size, word size and number of rounds.  We either will
need separate OIDs for various common combinations of these, or a mechanism
for stating the parameter range supported (I assume that all implementations
may not support any arbitrary parameter range), and the parameters actually
used.

All this is a digression, however, from Warwick's initial question about DSS
OIDs.  I believe that Warwick's question was prompted by a discussion in the
Federal PKI Working Group about the best OIDs to use in Federal DSS
certificates.  We are trying to pick the DSS OIDs for Federal use, and want
to know who might be impacted if we pick the X9.57 DSS OIDs, because thay
are already using the OIDs defined for by the OIW.  So I would like to
repeat Warwick's question that started this thread, since nearly all the
responses have been about OIDs for symmetric keys, a worthy but different
subject.

> From: Warwick Ford: [email-masked]
>
>We need (1) an OID for dsaWithSha-1, with no parameters, for use in the
>certificate signature and the SIGNED macro fields; and (2) an OID for dsa,
>with optional parameters, for use in subjectPublicKeyInfo.  Both X9 and the
>OIW have algorithms defined.
>
>For (1), the obvious candidate is X9.57 OID { x9algorithm 3 }, since no OIW
>algorithm is defined with the parameter done right.
>
>For (2), we could either use X9.57's { x9algorithm 1 } or the OIW's {
>algorithm 12 }.  Both are the same.  For consistency we should maybe use the
>X9 one.  Do any implementors have a serious preference for one or the other
>(because of use in existing product).
>
>Warwick

>
>> From: Bob Jueneman <[email-masked]>
>> 
>> The problem is even worse than Jan describes. In addition to the DES 
>> flavor of the month, there is RC2 and RC4, maybe RC5, IDEA, and
>> probably some proprietary (per country) algorithms as well.
>> 
>> Over and above that, there will soon be the issue of what e-mail, SSL, etc.,
>> protocols a given site can support.
>> 
>> Sooner or later, people are going to recognize that a directory would 
>> be an awfully handy way to solve these problems. But until that
>> happens, I would support including a suite of supported hash and 
>> symmetric key encryption algorithms within a certificate as a PKIX
>> defined extension attribute.
>
>For email, using a directory to identify the symmetric algorithm(s)
>supported by the recipient is useful.  However, for online protocols
>(IPSEC, SSL, etc) the peer's capabilities can be discovered at
>connection establishment time, and it's probably a bad idea to
>rely on setting up a connection to a third party just to determine
>what algorithms are supported by the first two.   It sounds like an
>especially bad idea to have CAs vouch for the availability of
>particular algorithms at a particular party, which is what embedding
>symmetric algorithm IDs into extension attributes would accomplish.
>
>In any case, Jan's question wasn't about how to transfer the algorithm
>information, it was about how to represent it.  Assigning OIDs capable
>of representing symmetric key sizes and other parameters/options is useful
>in and of itself, regardless of the data structures containing the OIDs
>or the methods used to transmit them.
>
>

Regards,

Bill Burr
301-975-2914
http://www.nist.gov/itl/div877/staff/burr/

From: <[email-masked]>
Sender: Post Master <[email-masked]>
To: [email-masked]
Date: Wed, 6 Nov 1996 21:19:21 +0000
Subject: DER Encoding of UTCTime
Priority: normal
Status:   

I notice that in Part 1 of the PKIX documents, it is recommended that
UTCTime be encoded as YYMMDDHHMMZ and that 00 seconds should never be
encoded.

The current version of DMS uses the YYMMDDHHMMZ format but the newest
DMS documents (SDN.706) require a YYMMDDHHMMSSZ format even if the
seconds field is 00. In particular, SDN.706 states that this is
consistent with proposed corrections to DER.

I cannot find any requirements for SET. Are there any?

I have not seen the proposed corrections to DER, but would it not make
sense for PKIX, SET and DMS to use the same format, i.e.,
YYMMDDHHMMSSZ?

GeneralizedTime is another days work!

David

.......................................................
David Gray                      e-mail: [email-masked]
Formal Systems                http://www.iol.ie/~formal
4 Roebuck Castle
Roebuck Road
Clonskeagh
Dublin 14
Ireland
.......................................................

From: <[email-masked]>
Sender: Post Master <[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 6 Nov 1996 19:31:39 +0000
Subject: DER Encodings of UTCTime
Priority: normal
Status:   

I notice that in Part 1 of the PKIX documents, it is recommended that
UTCTime be encoded as YYMMDDHHMMZ and that 00 seconds should never be
encoded.

The current version of DMS uses the YYMMDDHHMMZ format but the newest
DMS documents (SDN.706) require a YYMMDDHHMMSSZ format even if the 
seconds field is 00. In particular, SDN.706 states that this is 
consistent with proposed corrections to DER.

I cannot find any requirements for SET. Are there any?

I have not seen the proposed corrections to DER, but would it not 
make sense for PKIX, SET and DMS to use the same format, i.e.,
YYMMDDHHMMSSZ?

GeneralizedTime is another days work!

David

.......................................................
David Gray                      e-mail: [email-masked]
Formal Systems                http://www.iol.ie/~formal
4 Roebuck Castle
Roebuck Road
Clonskeagh
Dublin 14
Ireland
.......................................................

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Bill Burr'" <[email-masked]>
Subject: RE: Symmetric algorithm OIDs and back to DSA Algorithm OIDs
Date: Wed, 6 Nov 1996 15:18:19 -0800

Where a DSA key is used as input to either a signing or a key agreement
algoirhtm, should the subectPublicKey oid  indicate which mechanism/algoirhtm is intended,
if not both, or should it merely indicate the format/encoding of said field?

If the mechanism is to be constrained, this suggests at least three DSA oids.

Where there are multiple key agreement algorithms which use  a DSA key as input,
should said oid should be different, per algoirhtm?

V3 extensions facilitate specification of mechanism, which a DSA key may
be purposed for. v3 std extensions do not seem to faciliate spec of which
algorithm a DSA key is constrained to, unless constrained by
the subjectPublicKey Oid.

 
----------
From: 	Bill Burr
Sent: 	Wednesday, November 06, 1996 6:29 AM
To: 	[email-masked]
Subject: 	Re: Symmetric algorithm OIDs and back to DSA Algorithm OIDs

My understanding of what Warwick proposed for  supported symmetric key
algorithms  is that the subJectDirectoryAttributes certificate extension,
which I believe allows any directory attribute to be included in
certificates, be used to carry OIDs for supported symmetric key algorithms.
This would then include the supported algorithms in the ecertificate itself,
and, if you had the certificate, you would have the supported algorithms.

Also, if we're discusing symmetric key algorithm OIDs, we must remember Ron
Rivest's earlier comment about parameters for symmetric key algorithms.
Several of the more recent algorithms (i.e., RC5 and Blowfish) have at least
three parameters: key size, word size and number of rounds.  We either will
need separate OIDs for various common combinations of these, or a mechanism
for stating the parameter range supported (I assume that all implementations
may not support any arbitrary parameter range), and the parameters actually
used.

All this is a digression, however, from Warwick's initial question about DSS
OIDs.  I believe that Warwick's question was prompted by a discussion in the
Federal PKI Working Group about the best OIDs to use in Federal DSS
certificates.  We are trying to pick the DSS OIDs for Federal use, and want
to know who might be impacted if we pick the X9.57 DSS OIDs, because thay
are already using the OIDs defined for by the OIW.  So I would like to
repeat Warwick's question that started this thread, since nearly all the
responses have been about OIDs for symmetric keys, a worthy but different
subject.

> From: Warwick Ford: [email-masked]
>
>We need (1) an OID for dsaWithSha-1, with no parameters, for use in the
>certificate signature and the SIGNED macro fields; and (2) an OID for dsa,
>with optional parameters, for use in subjectPublicKeyInfo.  Both X9 and the
>OIW have algorithms defined.
>
>For (1), the obvious candidate is X9.57 OID { x9algorithm 3 }, since no OIW
>algorithm is defined with the parameter done right.
>
>For (2), we could either use X9.57's { x9algorithm 1 } or the OIW's {
>algorithm 12 }.  Both are the same.  For consistency we should maybe use the
>X9 one.  Do any implementors have a serious preference for one or the other
>(because of use in existing product).
>
>Warwick

>
>> From: Bob Jueneman <[email-masked]>
>> 
>> The problem is even worse than Jan describes. In addition to the DES 
>> flavor of the month, there is RC2 and RC4, maybe RC5, IDEA, and
>> probably some proprietary (per country) algorithms as well.
>> 
>> Over and above that, there will soon be the issue of what e-mail, SSL, etc.,
>> protocols a given site can support.
>> 
>> Sooner or later, people are going to recognize that a directory would 
>> be an awfully handy way to solve these problems. But until that
>> happens, I would support including a suite of supported hash and 
>> symmetric key encryption algorithms within a certificate as a PKIX
>> defined extension attribute.
>
>For email, using a directory to identify the symmetric algorithm(s)
>supported by the recipient is useful.  However, for online protocols
>(IPSEC, SSL, etc) the peer's capabilities can be discovered at
>connection establishment time, and it's probably a bad idea to
>rely on setting up a connection to a third party just to determine
>what algorithms are supported by the first two.   It sounds like an
>especially bad idea to have CAs vouch for the availability of
>particular algorithms at a particular party, which is what embedding
>symmetric algorithm IDs into extension attributes would accomplish.
>
>In any case, Jan's question wasn't about how to transfer the algorithm
>information, it was about how to represent it.  Assigning OIDs capable
>of representing symmetric key sizes and other parameters/options is useful
>in and of itself, regardless of the data structures containing the OIDs
>or the methods used to transmit them.
>
>

Regards,

Bill Burr
301-975-2914
http://www.nist.gov/itl/div877/staff/burr/

From: Sri Vidya Rajagopal <[email-masked]>
Subject: unsubscribe
To: [email-masked]
Date: Wed, 06 Nov 1996 14:37:14 PST

unsubscribe [email-masked]

From: Brian Korver <[email-masked]>
Subject: Re: DER Encoding of UTCTime
To: [email-masked]
Date: Wed, 6 Nov 1996 14:44:36 -0800 (PST)
Cc: [email-masked]
Content-Length: 1367

[email-masked] writes:
> 
> I notice that in Part 1 of the PKIX documents, it is recommended that
> UTCTime be encoded as YYMMDDHHMMZ and that 00 seconds should never be
> encoded.
> 
> The current version of DMS uses the YYMMDDHHMMZ format but the newest
> DMS documents (SDN.706) require a YYMMDDHHMMSSZ format even if the
> seconds field is 00. In particular, SDN.706 states that this is
> consistent with proposed corrections to DER.
> 
> I cannot find any requirements for SET. Are there any?

Although SET doesn't specify the DER encoding of UTCTime, I expect that
current implementations will be consistent with the proposed standard
for the DER encoding of UTCTime.  All current SET implementations that
I am aware of do use the YYMMDDHHMMSSZ format.  (BTW, this is consistent
with GeneralizedTime [X.690])

> I have not seen the proposed corrections to DER, but would it not make
> sense for PKIX, SET and DMS to use the same format, i.e.,
> YYMMDDHHMMSSZ?
> 
> GeneralizedTime is another days work!
> 
> David
> 
> 
> 
> 
> .......................................................
> David Gray                      e-mail: [email-masked]
> Formal Systems                http://www.iol.ie/~formal
> 4 Roebuck Castle
> Roebuck Road
> Clonskeagh
> Dublin 14
> Ireland
> .......................................................
> 
> 

brian
[email-masked]

From: [email-masked]
Sender: Post Master <[email-masked]>
To: [email-masked]
Date: Wed, 6 Nov 1996 21:19:21 +0000
Subject: DER Encoding of UTCTime
Priority: normal

I notice that in Part 1 of the PKIX documents, it is recommended that
UTCTime be encoded as YYMMDDHHMMZ and that 00 seconds should never be
encoded.

The current version of DMS uses the YYMMDDHHMMZ format but the newest
DMS documents (SDN.706) require a YYMMDDHHMMSSZ format even if the
seconds field is 00. In particular, SDN.706 states that this is
consistent with proposed corrections to DER.

I cannot find any requirements for SET. Are there any?

I have not seen the proposed corrections to DER, but would it not make
sense for PKIX, SET and DMS to use the same format, i.e.,
YYMMDDHHMMSSZ?

GeneralizedTime is another days work!

David

.......................................................
David Gray                      e-mail: [email-masked]
Formal Systems                http://www.iol.ie/~formal
4 Roebuck Castle
Roebuck Road
Clonskeagh
Dublin 14
Ireland
.......................................................

Date: Wed, 06 Nov 1996 09:29:54 -0500
To: [email-masked]
From: [email-masked] (Bill Burr)
Subject: Re: Symmetric algorithm OIDs and back to DSA Algorithm OIDs
Status:   

My understanding of what Warwick proposed for  supported symmetric key
algorithms  is that the subJectDirectoryAttributes certificate extension,
which I believe allows any directory attribute to be included in
certificates, be used to carry OIDs for supported symmetric key algorithms.
This would then include the supported algorithms in the ecertificate itself,
and, if you had the certificate, you would have the supported algorithms.

Also, if we're discusing symmetric key algorithm OIDs, we must remember Ron
Rivest's earlier comment about parameters for symmetric key algorithms.
Several of the more recent algorithms (i.e., RC5 and Blowfish) have at least
three parameters: key size, word size and number of rounds.  We either will
need separate OIDs for various common combinations of these, or a mechanism
for stating the parameter range supported (I assume that all implementations
may not support any arbitrary parameter range), and the parameters actually
used.

All this is a digression, however, from Warwick's initial question about DSS
OIDs.  I believe that Warwick's question was prompted by a discussion in the
Federal PKI Working Group about the best OIDs to use in Federal DSS
certificates.  We are trying to pick the DSS OIDs for Federal use, and want
to know who might be impacted if we pick the X9.57 DSS OIDs, because thay
are already using the OIDs defined for by the OIW.  So I would like to
repeat Warwick's question that started this thread, since nearly all the
responses have been about OIDs for symmetric keys, a worthy but different
subject.

> From: Warwick Ford: [email-masked]
>
>We need (1) an OID for dsaWithSha-1, with no parameters, for use in the
>certificate signature and the SIGNED macro fields; and (2) an OID for dsa,
>with optional parameters, for use in subjectPublicKeyInfo.  Both X9 and the
>OIW have algorithms defined.
>
>For (1), the obvious candidate is X9.57 OID { x9algorithm 3 }, since no OIW
>algorithm is defined with the parameter done right.
>
>For (2), we could either use X9.57's { x9algorithm 1 } or the OIW's {
>algorithm 12 }.  Both are the same.  For consistency we should maybe use the
>X9 one.  Do any implementors have a serious preference for one or the other
>(because of use in existing product).
>
>Warwick

>
>> From: Bob Jueneman <[email-masked]>
>> 
>> The problem is even worse than Jan describes. In addition to the DES 
>> flavor of the month, there is RC2 and RC4, maybe RC5, IDEA, and
>> probably some proprietary (per country) algorithms as well.
>> 
>> Over and above that, there will soon be the issue of what e-mail, SSL, etc.,
>> protocols a given site can support.
>> 
>> Sooner or later, people are going to recognize that a directory would 
>> be an awfully handy way to solve these problems. But until that
>> happens, I would support including a suite of supported hash and 
>> symmetric key encryption algorithms within a certificate as a PKIX
>> defined extension attribute.
>
>For email, using a directory to identify the symmetric algorithm(s)
>supported by the recipient is useful.  However, for online protocols
>(IPSEC, SSL, etc) the peer's capabilities can be discovered at
>connection establishment time, and it's probably a bad idea to
>rely on setting up a connection to a third party just to determine
>what algorithms are supported by the first two.   It sounds like an
>especially bad idea to have CAs vouch for the availability of
>particular algorithms at a particular party, which is what embedding
>symmetric algorithm IDs into extension attributes would accomplish.
>
>In any case, Jan's question wasn't about how to transfer the algorithm
>information, it was about how to represent it.  Assigning OIDs capable
>of representing symmetric key sizes and other parameters/options is useful
>in and of itself, regardless of the data structures containing the OIDs
>or the methods used to transmit them.
>
>

Regards,

Bill Burr
301-975-2914
http://www.nist.gov/itl/div877/staff/burr/

From: [email-masked]
Sender: Post Master <[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 6 Nov 1996 19:31:39 +0000
Subject: DER Encodings of UTCTime
Priority: normal

I notice that in Part 1 of the PKIX documents, it is recommended that
UTCTime be encoded as YYMMDDHHMMZ and that 00 seconds should never be
encoded.

The current version of DMS uses the YYMMDDHHMMZ format but the newest
DMS documents (SDN.706) require a YYMMDDHHMMSSZ format even if the 
seconds field is 00. In particular, SDN.706 states that this is 
consistent with proposed corrections to DER.

I cannot find any requirements for SET. Are there any?

I have not seen the proposed corrections to DER, but would it not 
make sense for PKIX, SET and DMS to use the same format, i.e.,
YYMMDDHHMMSSZ?

GeneralizedTime is another days work!

David

.......................................................
David Gray                      e-mail: [email-masked]
Formal Systems                http://www.iol.ie/~formal
4 Roebuck Castle
Roebuck Road
Clonskeagh
Dublin 14
Ireland
.......................................................

Date: Wed, 06 Nov 1996 11:15:38 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Symmetric algorithm OIDs (was: Re: DSA Algorithm Ids) -Reply

>>> David P. Kemp <[email-masked]> 11/05/96 10:12am >>>
For email, using a directory to identify the symmetric algorithm(s)
supported by the recipient is useful.  However, for online protocols
(IPSEC, SSL, etc) the peer's capabilities can be discovered at
connection establishment time, and it's probably a bad idea to
rely on setting up a connection to a third party just to determine
what algorithms are supported by the first two.   It sounds like an
especially bad idea to have CAs vouch for the availability of
particular algorithms at a particular party, which is what embedding
symmetric algorithm IDs into extension attributes would accomplish.

I would agree that it shouldn't be necessary to contact a third party
in order to negotiate an approporatie algorithm, although some bind 
protocols have been doing that for a long time. I was really talking 
about the e-mail case, where I may not have previously communicated
someone and don't know his or her algorithm capabilities. (Maybe I
am the president of an organization, and I want to send out an encrypted
message to all employees.)

But why do you believe that it would be an "especially bad idea" to have the
CA convey the availability of particular algorithms in a certificate? If
necessary, a CA's Certification Practice Statement could identity
that extension as representing NonVerified Subscriber Information.

And in some other cases, e.g., in a corporate setting where the Chief
Information Officer wishes to ensure a minimum level of security, it
might be important for the CA to limit the choices that might be available 
for use by users.

In any case is doesn't seem to do any particular harm, and might be 
pretty helpful.

Bob

>In any case, Jan's question wasn't about how to transfer the algorithm
information, it was about how to represent it.  Assigning OIDs capable
of representing symmetric key sizes and other parameters/options is useful
in and of itself, regardless of the data structures containing the OIDs
or the methods used to transmit them.

Date: Wed, 06 Nov 1996 10:47:25 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Symmetric algorithm OIDs and back to DSA Algorithm OIDs -Reply

With respect to the DSS OIDs, we at Novell don't care. Somebody pick one --
Warwick's suggestion seemed reasonable.

Regarding Ron Rivest's observation, we may be stuck, since the 
subjectDirectoryAttributes extension doesn't provide for any parameters.

I suppose we could try to fix that via the ISO defect mechanism, if we 
hurry, as it is unlikely that anyone has implemented that extension yet.

Otherwise, we are going to have a real OID proliferation problem, if we 
need separate OIDs for all of the common choices for key size, word size, 
and number of rounds.  And I assume that the block ciphers, at least, can 
be used in ECB, CFB, CBC, and OFB modes, and perhaps others -- like
(God forbid, because it isn't secure) N-bit OFB, triple-DES with 40 bits in 
outer CBC, etc., etc. -- a Pandora's box of OIDs.

At an absolute minimum, the PKIX document needs to profile a well-chosen 
set of symmetric algorithm OIDs, taking into consideration the existing 
import/export laws in various countries and a "reasonable" selection of
the various parameters and modes.

Bob

>>> Bill Burr <[email-masked]> 11/06/96 07:29am >>>
My understanding of what Warwick proposed for  supported symmetric key
algorithms  is that the subJectDirectoryAttributes certificate extension,
which I believe allows any directory attribute to be included in
certificates, be used to carry OIDs for supported symmetric key algorithms.
This would then include the supported algorithms in the ecertificate itself,
and, if you had the certificate, you would have the supported algorithms.

Also, if we're discusing symmetric key algorithm OIDs, we must remember Ron
Rivest's earlier comment about parameters for symmetric key algorithms.
Several of the more recent algorithms (i.e., RC5 and Blowfish) have at least
three parameters: key size, word size and number of rounds.  We either will
need separate OIDs for various common combinations of these, or a mechanism
for stating the parameter range supported (I assume that all implementations
may not support any arbitrary parameter range), and the parameters actually
used.

All this is a digression, however, from Warwick's initial question about DSS
OIDs.  I believe that Warwick's question was prompted by a discussion in the
Federal PKI Working Group about the best OIDs to use in Federal DSS
certificates.  We are trying to pick the DSS OIDs for Federal use, and want
to know who might be impacted if we pick the X9.57 DSS OIDs, because thay
are already using the OIDs defined for by the OIW.  So I would like to
repeat Warwick's question that started this thread, since nearly all the
responses have been about OIDs for symmetric keys, a worthy but different
subject.

> From: Warwick Ford: [email-masked]
>
>We need (1) an OID for dsaWithSha-1, with no parameters, for use in the
>certificate signature and the SIGNED macro fields; and (2) an OID for dsa,
>with optional parameters, for use in subjectPublicKeyInfo.  Both X9 and the
>OIW have algorithms defined.
>
>For (1), the obvious candidate is X9.57 OID { x9algorithm 3 }, since no OIW
>algorithm is defined with the parameter done right.
>
>For (2), we could either use X9.57's { x9algorithm 1 } or the OIW's {
>algorithm 12 }.  Both are the same.  For consistency we should maybe use the
>X9 one.  Do any implementors have a serious preference for one or the other
>(because of use in existing product).
>
>Warwick

>
>> From: Bob Jueneman <[email-masked]>
>> 
>> The problem is even worse than Jan describes. In addition to the DES 
>> flavor of the month, there is RC2 and RC4, maybe RC5, IDEA, and
>> probably some proprietary (per country) algorithms as well.
>> 
>> Over and above that, there will soon be the issue of what e-mail, SSL, etc.,
>> protocols a given site can support.
>> 
>> Sooner or later, people are going to recognize that a directory would 
>> be an awfully handy way to solve these problems. But until that
>> happens, I would support including a suite of supported hash and 
>> symmetric key encryption algorithms within a certificate as a PKIX
>> defined extension attribute.
>
>For email, using a directory to identify the symmetric algorithm(s)
>supported by the recipient is useful.  However, for online protocols
>(IPSEC, SSL, etc) the peer's capabilities can be discovered at
>connection establishment time, and it's probably a bad idea to
>rely on setting up a connection to a third party just to determine
>what algorithms are supported by the first two.   It sounds like an
>especially bad idea to have CAs vouch for the availability of
>particular algorithms at a particular party, which is what embedding
>symmetric algorithm IDs into extension attributes would accomplish.
>
>In any case, Jan's question wasn't about how to transfer the algorithm
>information, it was about how to represent it.  Assigning OIDs capable
>of representing symmetric key sizes and other parameters/options is useful
>in and of itself, regardless of the data structures containing the OIDs
>or the methods used to transmit them.
>
>

Regards,

Bill Burr
301-975-2914
http://www.nist.gov/itl/div877/staff/burr/

Date: Wed, 06 Nov 1996 09:29:54 -0500
To: [email-masked]
From: [email-masked] (Bill Burr)
Subject: Re: Symmetric algorithm OIDs and back to DSA Algorithm OIDs

My understanding of what Warwick proposed for  supported symmetric key
algorithms  is that the subJectDirectoryAttributes certificate extension,
which I believe allows any directory attribute to be included in
certificates, be used to carry OIDs for supported symmetric key algorithms.
This would then include the supported algorithms in the ecertificate itself,
and, if you had the certificate, you would have the supported algorithms.

Also, if we're discusing symmetric key algorithm OIDs, we must remember Ron
Rivest's earlier comment about parameters for symmetric key algorithms.
Several of the more recent algorithms (i.e., RC5 and Blowfish) have at least
three parameters: key size, word size and number of rounds.  We either will
need separate OIDs for various common combinations of these, or a mechanism
for stating the parameter range supported (I assume that all implementations
may not support any arbitrary parameter range), and the parameters actually
used.

All this is a digression, however, from Warwick's initial question about DSS
OIDs.  I believe that Warwick's question was prompted by a discussion in the
Federal PKI Working Group about the best OIDs to use in Federal DSS
certificates.  We are trying to pick the DSS OIDs for Federal use, and want
to know who might be impacted if we pick the X9.57 DSS OIDs, because thay
are already using the OIDs defined for by the OIW.  So I would like to
repeat Warwick's question that started this thread, since nearly all the
responses have been about OIDs for symmetric keys, a worthy but different
subject.

> From: Warwick Ford: [email-masked]
>
>We need (1) an OID for dsaWithSha-1, with no parameters, for use in the
>certificate signature and the SIGNED macro fields; and (2) an OID for dsa,
>with optional parameters, for use in subjectPublicKeyInfo.  Both X9 and the
>OIW have algorithms defined.
>
>For (1), the obvious candidate is X9.57 OID { x9algorithm 3 }, since no OIW
>algorithm is defined with the parameter done right.
>
>For (2), we could either use X9.57's { x9algorithm 1 } or the OIW's {
>algorithm 12 }.  Both are the same.  For consistency we should maybe use the
>X9 one.  Do any implementors have a serious preference for one or the other
>(because of use in existing product).
>
>Warwick

>
>> From: Bob Jueneman <[email-masked]>
>> 
>> The problem is even worse than Jan describes. In addition to the DES 
>> flavor of the month, there is RC2 and RC4, maybe RC5, IDEA, and
>> probably some proprietary (per country) algorithms as well.
>> 
>> Over and above that, there will soon be the issue of what e-mail, SSL, etc.,
>> protocols a given site can support.
>> 
>> Sooner or later, people are going to recognize that a directory would 
>> be an awfully handy way to solve these problems. But until that
>> happens, I would support including a suite of supported hash and 
>> symmetric key encryption algorithms within a certificate as a PKIX
>> defined extension attribute.
>
>For email, using a directory to identify the symmetric algorithm(s)
>supported by the recipient is useful.  However, for online protocols
>(IPSEC, SSL, etc) the peer's capabilities can be discovered at
>connection establishment time, and it's probably a bad idea to
>rely on setting up a connection to a third party just to determine
>what algorithms are supported by the first two.   It sounds like an
>especially bad idea to have CAs vouch for the availability of
>particular algorithms at a particular party, which is what embedding
>symmetric algorithm IDs into extension attributes would accomplish.
>
>In any case, Jan's question wasn't about how to transfer the algorithm
>information, it was about how to represent it.  Assigning OIDs capable
>of representing symmetric key sizes and other parameters/options is useful
>in and of itself, regardless of the data structures containing the OIDs
>or the methods used to transmit them.
>
>

Regards,

Bill Burr
301-975-2914
http://www.nist.gov/itl/div877/staff/burr/

From: "Anil R. Gangolli" <[email-masked]>
Date: Tue, 5 Nov 1996 20:19:08 -0800
Reply-To: [email-masked]
To: [email-masked]
Subject: Authority Key Identifier and Subject Key Identifier
Cc: [email-masked]

I am trying to find current definitions of the
Authority Key Identifier and Subject Key Identifier
extensions.

I have what may be an old draft definition for the Authority
Key Identifier.

The Subject Key Identifier extension is mentioned in the
June 1996 draft-ietf-pkix-ipki-part1-02 Internet Draft
(Housley, Ford, Solo), but I cannot find a definition of it.

Thanks.
--a.

Date: Tue, 5 Nov 1996 12:12:43 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Symmetric algorithm OIDs (was: Re: DSA Algorithm Ids)

> From: Bob Jueneman <[email-masked]>
> 
> The problem is even worse than Jan describes. In addition to the DES 
> flavor of the month, there is RC2 and RC4, maybe RC5, IDEA, and
> probably some proprietary (per country) algorithms as well.
> 
> Over and above that, there will soon be the issue of what e-mail, SSL, etc.,
> protocols a given site can support.
> 
> Sooner or later, people are going to recognize that a directory would 
> be an awfully handy way to solve these problems. But until that
> happens, I would support including a suite of supported hash and 
> symmetric key encryption algorithms within a certificate as a PKIX
> defined extension attribute.

For email, using a directory to identify the symmetric algorithm(s)
supported by the recipient is useful.  However, for online protocols
(IPSEC, SSL, etc) the peer's capabilities can be discovered at
connection establishment time, and it's probably a bad idea to
rely on setting up a connection to a third party just to determine
what algorithms are supported by the first two.   It sounds like an
especially bad idea to have CAs vouch for the availability of
particular algorithms at a particular party, which is what embedding
symmetric algorithm IDs into extension attributes would accomplish.

In any case, Jan's question wasn't about how to transfer the algorithm
information, it was about how to represent it.  Assigning OIDs capable
of representing symmetric key sizes and other parameters/options is useful
in and of itself, regardless of the data structures containing the OIDs
or the methods used to transmit them.

Date: Tue, 05 Nov 1996 11:49:11 -0500
To: Bob Jueneman <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: Re: DSA Algorithm Ids -Reply -Reply
Cc: [email-masked]

It's in the X.509 Certificate Extensions Amendment - clause 12.2.2.7.

Warwick

At 09:01 AM 11/5/96 -0700, Bob Jueneman wrote:
>I thought I remembered something about a supported algorithms attribute, but 
>when I looked for it I couldn't find it. Can you give me a reference? It
sounds like 
>exactly what we need.
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

Date: Tue, 05 Nov 1996 09:01:48 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: DSA Algorithm Ids -Reply -Reply

I thought I remembered something about a supported algorithms attribute, but 
when I looked for it I couldn't find it. Can you give me a reference? It sounds like 
exactly what we need.

Bob

>>> Warwick Ford <[email-masked]> 11/04/96 01:30pm >>>
There is already a standard "Supported Algorithms" attribute, suitable for
conveyance in the Subject Directory Attributes certificate extension.
Sounds reasonable for us to profile use of that attribute in the PKIX
Profile, by listing some common OIDs to go in it.

Warwick

At 12:28 PM 11/4/96 -0700, Bob Jueneman wrote:
>The problem is even worse than Jan describes. In addition to the DES 
>flavor of the month, there is RC2 and RC4, maybe RC5, IDEA, and
>probably some proprietary (per country) algorithms as well.
>
>Over and above that, there will soon be the issue of what e-mail, SSL, etc.,
>protocols a given site can support.
>
>Sooner or later, people are going to recognize that a directory would 
>be an awfully handy way to solve these problems. But until that
>happens, I would support including a suite of supported hash and 
>symmetric key encryption algorithms within a certificate as a PKIX
>defined extension attribute.
>
>Bob
>
>>>> Jan Luehe <[email-masked]> 11/04/96 10:55am >>>
>----------
>X-Sun-Data-Type: text
>X-Sun-Data-Description: text
>X-Sun-Data-Name: text
>X-Sun-Charset: us-ascii
>X-Sun-Content-Lines: 83
>
>Hi Warwick:
>
>
>> We need (1) an OID for dsaWithSha-1, with no parameters, for use in the
>> certificate signature and the SIGNED macro fields; and (2) an OID for dsa,
>> with optional parameters, for use in subjectPublicKeyInfo.  Both X9 and the
>> OIW have algorithms defined.
>> 
>> For (1), the obvious candidate is X9.57 OID { x9algorithm 3 }, since no OIW
>> algorithm is defined with the parameter done right.
>> 
>> For (2), we could either use X9.57's { x9algorithm 1 } or the OIW's {
>> algorithm 12 }.  Both are the same.  For consistency we should maybe use the
>> X9 one.  Do any implementors have a serious preference for one or the other
>> (because of use in existing product).
>
>
>Would this be the right time to also assign an OID for an export version
>of DES (and triple-DES), in order to facilitate interoperability between
>export-restricted and full-strength implementations of DES?
>
>I remember two proposals for solving this problem:
>
>
>1. Assign a new OID for DES, where the effective key size is encoded as
>   a parameter.
>
>2. Assign a new OID for DES, where the effective key size is encoded
>   in the OID itself.
>
>
>I am in favor of the first proposal, because it would allow for more
>flexibility.
>
>(I have attached an earlier email which explains the problem in more 
>detail.)
>
>
>Thanks,
>
>
>Jan Luehe 
>Sun Microsystems
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>I would be in favor of the latter, becuase it will allow for more
>flexibility.
>
>
>Thanks,
>
>Jan Luehe
>Sun Microsystem
> 
>----------
>X-Sun-Data-Type: default
>X-Sun-Data-Description: default
>X-Sun-Data-Name: email
>X-Sun-Charset: us-ascii
>X-Sun-Content-Lines: 40
>
>>>> Jan Luehe <[email-masked]> 10/07/96 04:30pm >>>
>Hi there:
>
>
>Does anybody know if special object identifiers have
>been defined for encryption algorithms with a fixed
>key size (e.g., DES-CBC), when used in export mode
>(e.g., DES40_CBC)?
>
>If no such object identifiers exist, how can two sites
>using different versions of the same software package
>(one domestic, one export) communicate with each other?
>
>This is not a problem where the encryption keysize is
>specified by a cipher suite identifier which can be negotiated
>between the two communicating parties as part of a protocol
>(e.g., SSL).
>This is also not a problem where one site wraps the encryption
>key in a digital envelope.
>
>However, this becomes a problem if both parties establish the
>encryption key independently, e.g., through password-based
>encryption, and the party using the exportable version of the
>software truncates the encryption key to say 40 bits.
>
>Since the definition of DES does not provide for 
>a key size parameter, how can a decrypting party
>determine the (potentially truncated) key size that was
>used by the encrypting party, other than through some out-of-band
>mechanism?
>
>So my question again: Is there a special AID for something
>like DES40_CBC?
>
>
>Thanks,
>
>
>Jan Luehe
>Sun Microsystems
>
>
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

Date: Mon, 4 Nov 1996 13:51:01 -0800
From: [email-masked] (Jan Luehe)
To: [email-masked], [email-masked]
Subject: Re: DSA Algorithm Ids -Reply
Cc: [email-masked], [email-masked]

Warwick:

> There is already a standard "Supported Algorithms" attribute, suitable for
> conveyance in the Subject Directory Attributes certificate extension.
> Sounds reasonable for us to profile use of that attribute in the PKIX
> Profile, by listing some common OIDs to go in it.

I am not so much concerned about where to store the supported
algorithm information. A certificate extension field seems to be
the appropriate place.

I am more concerned about which OID to assign to an exportable
flavor of an encryption algorithm (e.g., 40-bit DES), where the
current definition of that algorithm does not provide for a
parameter field (which could have been used to encode that information,
e.g., a key size).

Jan

Date: Mon, 4 Nov 1996 13:34:36 -0800
From: [email-masked] (Jan Luehe)
To: [email-masked]
Subject: Re: DSA Algorithm Ids
Cc: [email-masked]

Steve:

>         Where would one DES (or other symmetric algorithms) in this
> context?  The OIDs Warwick cited were for digital signatures.  Although it
> is technically possible to do symmetric-based signatures, I never hear of
> anyone really making use of them in practice.  Also, this is a public key
> certificate standard we are working on, so I see the need for OIDs for hash
> algorithms, signature algorithms, and public key encryption/key exchange
> algorithms, but not for synnetric encryption algortihms.  Thus I'm a bit
> puzzled by your request.

My request was not related to digital signature algorithms at all.
I just took Warwick's email about registering OIDs as an opportunity
to discuss an issue that had come up earlier (i.e., interoperability
between domestic and export versions of encryption algorithms) and
might also require some OID registration.

Jan

Date: Mon, 04 Nov 1996 15:30:38 -0500
To: Bob Jueneman <[email-masked]>, [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: DSA Algorithm Ids -Reply
Cc: [email-masked], [email-masked]

There is already a standard "Supported Algorithms" attribute, suitable for
conveyance in the Subject Directory Attributes certificate extension.
Sounds reasonable for us to profile use of that attribute in the PKIX
Profile, by listing some common OIDs to go in it.

Warwick

At 12:28 PM 11/4/96 -0700, Bob Jueneman wrote:
>The problem is even worse than Jan describes. In addition to the DES 
>flavor of the month, there is RC2 and RC4, maybe RC5, IDEA, and
>probably some proprietary (per country) algorithms as well.
>
>Over and above that, there will soon be the issue of what e-mail, SSL, etc.,
>protocols a given site can support.
>
>Sooner or later, people are going to recognize that a directory would 
>be an awfully handy way to solve these problems. But until that
>happens, I would support including a suite of supported hash and 
>symmetric key encryption algorithms within a certificate as a PKIX
>defined extension attribute.
>
>Bob
>
>>>> Jan Luehe <[email-masked]> 11/04/96 10:55am >>>
>----------
>X-Sun-Data-Type: text
>X-Sun-Data-Description: text
>X-Sun-Data-Name: text
>X-Sun-Charset: us-ascii
>X-Sun-Content-Lines: 83
>
>Hi Warwick:
>
>
>> We need (1) an OID for dsaWithSha-1, with no parameters, for use in the
>> certificate signature and the SIGNED macro fields; and (2) an OID for dsa,
>> with optional parameters, for use in subjectPublicKeyInfo.  Both X9 and the
>> OIW have algorithms defined.
>> 
>> For (1), the obvious candidate is X9.57 OID { x9algorithm 3 }, since no OIW
>> algorithm is defined with the parameter done right.
>> 
>> For (2), we could either use X9.57's { x9algorithm 1 } or the OIW's {
>> algorithm 12 }.  Both are the same.  For consistency we should maybe use the
>> X9 one.  Do any implementors have a serious preference for one or the other
>> (because of use in existing product).
>
>
>Would this be the right time to also assign an OID for an export version
>of DES (and triple-DES), in order to facilitate interoperability between
>export-restricted and full-strength implementations of DES?
>
>I remember two proposals for solving this problem:
>
>
>1. Assign a new OID for DES, where the effective key size is encoded as
>   a parameter.
>
>2. Assign a new OID for DES, where the effective key size is encoded
>   in the OID itself.
>
>
>I am in favor of the first proposal, because it would allow for more
>flexibility.
>
>(I have attached an earlier email which explains the problem in more 
>detail.)
>
>
>Thanks,
>
>
>Jan Luehe 
>Sun Microsystems
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>I would be in favor of the latter, becuase it will allow for more
>flexibility.
>
>
>Thanks,
>
>Jan Luehe
>Sun Microsystem
> 
>----------
>X-Sun-Data-Type: default
>X-Sun-Data-Description: default
>X-Sun-Data-Name: email
>X-Sun-Charset: us-ascii
>X-Sun-Content-Lines: 40
>
>>>> Jan Luehe <[email-masked]> 10/07/96 04:30pm >>>
>Hi there:
>
>
>Does anybody know if special object identifiers have
>been defined for encryption algorithms with a fixed
>key size (e.g., DES-CBC), when used in export mode
>(e.g., DES40_CBC)?
>
>If no such object identifiers exist, how can two sites
>using different versions of the same software package
>(one domestic, one export) communicate with each other?
>
>This is not a problem where the encryption keysize is
>specified by a cipher suite identifier which can be negotiated
>between the two communicating parties as part of a protocol
>(e.g., SSL).
>This is also not a problem where one site wraps the encryption
>key in a digital envelope.
>
>However, this becomes a problem if both parties establish the
>encryption key independently, e.g., through password-based
>encryption, and the party using the exportable version of the
>software truncates the encryption key to say 40 bits.
>
>Since the definition of DES does not provide for 
>a key size parameter, how can a decrypting party
>determine the (potentially truncated) key size that was
>used by the encrypting party, other than through some out-of-band
>mechanism?
>
>So my question again: Is there a special AID for something
>like DES40_CBC?
>
>
>Thanks,
>
>
>Jan Luehe
>Sun Microsystems
>
>
-------------------------------------------------------------------
Warwick Ford: [email-masked] Tel: (613)2253487 Fax: (613)2256361
   Postal:  25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8
-------------------------------------------------------------------

Date: Mon, 4 Nov 1996 14:35:14 -0500
To: [email-masked] (Jan Luehe)
From: [email-masked] (Stephen Kent)
Subject: Re: DSA Algorithm Ids
Cc: [email-masked]

Jan,

        Where would one DES (or other symmetric algorithms) in this
context?  The OIDs Warwick cited were for digital signatures.  Although it
is technically possible to do symmetric-based signatures, I never hear of
anyone really making use of them in practice.  Also, this is a public key
certificate standard we are working on, so I see the need for OIDs for hash
algorithms, signature algorithms, and public key encryption/key exchange
algorithms, but not for synnetric encryption algortihms.  Thus I'm a bit
puzzled by your request.

Steve

Date: Mon, 04 Nov 1996 12:28:44 -0700
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: DSA Algorithm Ids -Reply

The problem is even worse than Jan describes. In addition to the DES 
flavor of the month, there is RC2 and RC4, maybe RC5, IDEA, and
probably some proprietary (per country) algorithms as well.

Over and above that, there will soon be the issue of what e-mail, SSL, etc.,
protocols a given site can support.

Sooner or later, people are going to recognize that a directory would 
be an awfully handy way to solve these problems. But until that
happens, I would support including a suite of supported hash and 
symmetric key encryption algorithms within a certificate as a PKIX
defined extension attribute.

Bob

>>> Jan Luehe <[email-masked]> 11/04/96 10:55am >>>
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 83

Hi Warwick:

> We need (1) an OID for dsaWithSha-1, with no parameters, for use in the
> certificate signature and the SIGNED macro fields; and (2) an OID for dsa,
> with optional parameters, for use in subjectPublicKeyInfo.  Both X9 and the
> OIW have algorithms defined.
> 
> For (1), the obvious candidate is X9.57 OID { x9algorithm 3 }, since no OIW
> algorithm is defined with the parameter done right.
> 
> For (2), we could either use X9.57's { x9algorithm 1 } or the OIW's {
> algorithm 12 }.  Both are the same.  For consistency we should maybe use the
> X9 one.  Do any implementors have a serious preference for one or the other
> (because of use in existing product).

Would this be the right time to also assign an OID for an export version
of DES (and triple-DES), in order to facilitate interoperability between
export-restricted and full-strength implementations of DES?

I remember two proposals for solving this problem:

1. Assign a new OID for DES, where the effective key size is encoded as
   a parameter.

2. Assign a new OID for DES, where the effective key size is encoded
   in the OID itself.

I am in favor of the first proposal, because it would allow for more
flexibility.

(I have attached an earlier email which explains the problem in more 
detail.)

Thanks,

Jan Luehe 
Sun Microsystems

I would be in favor of the latter, becuase it will allow for more
flexibility.

Thanks,

Jan Luehe
Sun Microsystem
 
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: email
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 40

>>> Jan Luehe <[email-masked]> 10/07/96 04:30pm >>>
Hi there:

Does anybody know if special object identifiers have
been defined for encryption algorithms with a fixed
key size (e.g., DES-CBC), when used in export mode
(e.g., DES40_CBC)?

If no such object identifiers exist, how can two sites
using different versions of the same software package
(one domestic, one export) communicate with each other?

This is not a problem where the encryption keysize is
specified by a cipher suite identifier which can be negotiated
between the two communicating parties as part of a protocol
(e.g., SSL).
This is also not a problem where one site wraps the encryption
key in a digital envelope.

However, this becomes a problem if both parties establish the
encryption key independently, e.g., through password-based
encryption, and the party using the exportable version of the
software truncates the encryption key to say 40 bits.

Since the definition of DES does not provide for 
a key size parameter, how can a decrypting party
determine the (potentially truncated) key size that was
used by the encrypting party, other than through some out-of-band
mechanism?

So my question again: Is there a special AID for something
like DES40_CBC?

Thanks,

Jan Luehe
Sun Microsystems

Date: Mon, 4 Nov 1996 09:55:04 -0800
From: [email-masked] (Jan Luehe)
To: [email-masked]
Subject: Re: DSA Algorithm Ids
Cc: [email-masked], [email-masked], [email-masked]

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 83

Hi Warwick:

> We need (1) an OID for dsaWithSha-1, with no parameters, for use in the
> certificate signature and the SIGNED macro fields; and (2) an OID for dsa,
> with optional parameters, for use in subjectPublicKeyInfo.  Both X9 and the
> OIW have algorithms defined.
> 
> For (1), the obvious candidate is X9.57 OID { x9algorithm 3 }, since no OIW
> algorithm is defined with the parameter done right.
> 
> For (2), we could either use X9.57's { x9algorithm 1 } or the OIW's {
> algorithm 12 }.  Both are the same.  For consistency we should maybe use the
> X9 one.  Do any implementors have a serious preference for one or the other
> (because of use in existing product).

Would this be the right time to also assign an OID for an export version
of DES (and triple-DES), in order to facilitate interoperability between
export-restricted and full-strength implementations of DES?

I remember two proposals for solving this problem:

1. Assign a new OID for DES, where the effective key size is encoded as
   a parameter.

2. Assign a new OID for DES, where the effective key size is encoded
   in the OID itself.

I am in favor of the first proposal, because it would allow for more
flexibility.

(I have attached an earlier email which explains the problem in more 
detail.)

Thanks,

Jan Luehe 
Sun Microsystems

I would be in favor of the latter, becuase it will allow for more
flexibility.

Thanks,

Jan Luehe
Sun Microsystem
 
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: email
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 40

>>> Jan Luehe <[email-masked]> 10/07/96 04:30pm >>>
Hi there:

Does anybody know if special object identifiers have
been defined for encryption algorithms with a fixed
key size (e.g., DES-CBC), when used in export mode
(e.g., DES40_CBC)?

If no such object identifiers exist, how can two sites
using different versions of the same software package
(one domestic, one export) communicate with each other?

This is not a problem where the encryption keysize is
specified by a cipher suite identifier which can be negotiated
between the two communicating parties as part of a protocol
(e.g., SSL).
This is also not a problem where one site wraps the encryption
key in a digital envelope.

However, this becomes a problem if both parties establish the
encryption key independently, e.g., through password-based
encryption, and the party using the exportable version of the
software truncates the encryption key to say 40 bits.

Since the definition of DES does not provide for 
a key size parameter, how can a decrypting party
determine the (potentially truncated) key size that was
used by the encrypting party, other than through some out-of-band
mechanism?

So my question again: Is there a special AID for something
like DES40_CBC?

Thanks,

Jan Luehe
Sun Microsystems

Date: Mon, 04 Nov 1996 09:41:21 -0500
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: DSA Algorithm Ids

We need (1) an OID for dsaWithSha-1, with no parameters, for use in the
certificate signature and the SIGNED macro fields; and (2) an OID for dsa,
with optional parameters, for use in subjectPublicKeyInfo.  Both X9 and the
OIW have algorithms defined.

For (1), the obvious candidate is X9.57 OID { x9algorithm 3 }, since no OIW
algorithm is defined with the parameter done right.

For (2), we could either use X9.57's { x9algorithm 1 } or the OIW's {
algorithm 12 }.  Both are the same.  For consistency we should maybe use the
X9 one.  Do any implementors have a serious preference for one or the other
(because of use in existing product).

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

From: [email-masked] (Denis Pinkas)
Subject: INFOSEC'COM 97
To: [email-masked] (ietf-pkix)
Date: Mon, 4 Nov 1996 14:05:12 +0100 (NFT)

                              INFOSEC'COM
                          International Congress on=20
              Information Systems and Telecommunications Security
              12 . 13 June 1997 - CNIT Paris-La Defense - FRANCE

Invitation to submit Presentations

The International Congress on Information Systems and Telecommunications=20
Security presents the state of the art, innovations, prospects and new=20
openings in the fields of information systems and telecommunications=20
security. The information presented is novel and the presentations by the=
=20
speakers are both diversified and of a high standard. As such, they are=20
mostly intended for specialists in the field (information systems securit=
y=20
managers, computer manufacturers, software publishers, consultants, ...).

This Congress will take place in Paris (CNIT La Defense) alongside the=20
INFOSEC trade fair (from June 11 to June 13) where the exhibitors will=20
demonstrate their know-how in the area of information systems security=20
products and services.

To make things even more attractive, June happens to be the most pleasant=
=20
period of the year to visit Paris.=20

The Programmes Committee will carefully study all submitted proposals for=
=20
lectures and select those that will be included in the programme.=20
Selection is based on the following criteria: originality and novelty of=20
the lecture, relevance of the topic, quality of the speaker, the=20
scientific contents of the presentation, ...=20

The Congress focuses on the latest breakthroughs and prospects for the=20
various security techniques, both in terms of theory and practice.

For 1997, the Programmes Committee will essentially, though not=20
exclusively, emphasise the following themes:

  *  Security organisation and engineering
  *  Security issues in the area of information outsourcing
  *  Cryptographic technologies update
  *  Practical implementation of trusted third parties, their missions=20
     guarantees, relationships between trusted third parties, ...
  *  Internet and information superhighways: "firewalls", integrated=20
     offerings by network operators and software publishers, the role of=20
     access suppliers, the war against viruses, ...
  *  Electronic commerce security
  *  Radiocommunications security
  *  Sector-specific issues (banking, health services, ...)
  *  Legal trends in the field of security, for instance on Internet,=20
     copyrights, intellectual property, protection of youth, taxes, ...
  *  Etc.

Programme s  Committee

Walter FUMY - SIEMENS AG (D)
Marc GIRAULT - SEPT (F)
Hans GLISS - DATENSCHUTZ-BERATER (D)
Andr=E9 GRISSONNANCHE - AGC (F)
Fr=E9d=E9ric HUYNH - CLUSIF (F)
Jean-Philippe JOUAS - CSC (F)
Jean-Marc LAMERE - FFSA (F)
Jo=EBl LEBIDOIS - THOMSON CSF (F)
Jean MENTHONNEX - EPI Conseil (CH)
Christopher MITCHELL - UNIVERSITY OF LONDON (UK)
Denis PINKAS - BULL (F)
Philippe ROSE - LE MONDE INFORMATIQUE (F)
Gilles RUGGIU - BERTIN ET CIE (F)
Pieter VAN DIJKEN - SHELL INT. PETROLEUM (NL)
Michael WALKER - VODAFONE (UK)

GENERAL  INFORMATION

DATES=09
- Congress:      12.13 June 1997
- Exhibition: 11.12.13 June 1997

SITE
C.N.I.T. Paris-La Defense - 4 Place de la Defense -=20
92090 PARIS LA DEFENSE - France

OFFICIAL LANGUAGES
French and English - Simultaneous interpretation.

ACCOMMODATION=20
CIP Hotel will help you to book a room.
Tel :  33 (0)1 44 70 29 36 or 33 (0)1 44 70 25 02
Fax :  33 (0)1 44 70 24 48

ASSISTANCE
M.C.I. could help you in organizing your stay in Paris.

TRAVEL DISCOUNTS
AIR INTER, AIR LIBERTE, TAT EUROPEAN AIRLINES and SNCF.

HOW TO GET THERE
Information will be given in: Programme and Participant's Card.

REGISTRATION FEE (participant) : FF 4.980 (taxes incl.)
Price will include: access to conference-rooms, participant's file,=20
proceedings, 2 lunches, 4 coffee-breaks, visit and catalogue of the=20
INFOSEC exhibition.

REGULATION

HOW TO SUBMIT A PROPOSAL

Send the "Project for Paper" by December 3, 1996
Or use Electronic mail: [email-masked]

Overtly "commercial" presentations are inappropriate.

ACCEPTANCE

Authors will be notified of rejection or acceptance by December 31 . But=20
the Programmes Committee reserves the right to reconsider its decision=20
upon presentation of the full paper due no later than February 28 :=20
paper in French or English + 2 abstracts (French and English) + biography=
=20
+ photo.

Authors will have to certify their paper will not be published prior to=20
June 12, 1997.=20

PRESENTATION PROPOSAL
Approximately 25 minutes.

BENEFITS FOR SPEAKERS
Free admission offered (congress and exhibition).

PATRONAGE
CLUSIF - Club de la Securite Informatique Francais

ORGANISATION=20
MCI - Manifestations & Communications Internationales
19 Rue d'Athenes - 75009 PARIS - FRANCE
T=E9l : 33 (0)1 44 53 72 20 - Fax : 33 (0)1 44 53 72 22

Date: Fri, 01 Nov 96 15:04:44 
From: "Housley, Russ" <[email-masked]>
Encoding: 476 Text
To: [email-masked]
Subject: Re: Certificate Serial Numbers

>>3.  Most importantly, assuming that X.509 serial numbers are constrained to 
>>    be 32-bit values, does SET place a similar restriction on serial numbers?
>
>As for PKIX, I suggest generate only 32 bit, accept anything.

The PKIX profile already requires implementations to process huge integers. 
Both the DSS and RSA encodings now use INTEGER.

I see no reason to keep the value to 32 bits since clients only need to 
perform comparisons for equality.

Russ