Subject: Re: PKCS#7 in PKIX-3
From: Warwick Ford <[email-masked]>
To: [email-masked]
Date: Fri, 31 Jan 1997 16:57:57 -0800

>From observation of many prior standardization activities, I suggest that
solutions built by incrementally advancing existing, accepted,
well-understood solutions have been far more successful than attempts to
define something totally new, even if the latter was technically superior.

I believe this same feeling was supported by strong concensus in the San
Jose PKIX meeting.  If PKCS#7 satisfies requirements for many people, and
some incremental extensions to PKCS#7 would satisfy requirements for
everyone, then this is clearly far more likely to be accepted as a standard
than a totally new invention such as the proposal in the December I-D.

I would hate to see us use up scarce resources on a new protocol which lacks
broad buy-in from day one.

I would appreciate hearing opinions from other members of the list.

Warwick

At 12:08 PM 1/27/97, you wrote:
>
>Peter:
>
>> My observation that an *unbundled* protection envelope (which encapulates 
>> std information objects, rather than protects inner types) be the basis
>> of the design is founded on such observation of the success of the above 
>> approach in which componentware from multiple sources were bunded by the 
>> customers without third-party invention, yet all parties in a staticaly
>> configured certification system could agree the actual basis for technical 
>> interworking and system msg flow with minimal effort, complete control
>> over local security policy maintained in the hands of the procurer, and 
>> selection from muliple sources of equivalent product/toolkit/protction 
>> technology based on price, availability, and other value-adds  etc.
>
>I think that we are near concensus on this point.  A single 
>encapsulation mechanism would be ideal.  PKIX Part 3 contains one 
>suggestion, and PKCS #7 contains another.  Carlise provided an 
>analysis for the PKIX Part 3 approach.  PKCS #7 has a market 
>share that should not be ignored, and the specification is open 
>for reivew and update.  Further, RSA has agreed to work with the 
>IETF on the PKCS "standards" and give configuration control to 
>the IETF where standards track RFCs result.
>
>So, how does the group want to proceed?
>
>Russ
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date: Fri, 31 Jan 1997 11:15:37 -0800
To: Carlisle Adams <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Peter Williams <[email-masked]>
Subject: RE: PKCS#7 in PKIX-3
Cc: "[email-masked]'" <[email-masked]>

-----=_=_ 673551678-6741220-12299792 _=_=---
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Carlise:

I believe there is a better way than saying always "no, no
and no", to _actually_ open systems component technology and a world
of third-party, multi-vendor "highly re-bundlable" 
key management technology.

I want PKIX to be a useful componentware standard, not merely a 
pretend std for marketing closed or proprietary technology.

Surely the days of the monolithic CA management
systems are over; even their tiny appreciative market is
going away. We now need a plug-and play CA technology
world, where its the "proprietary" business rules of the using
and issuing organizations which govern how functional units of
a PKIX system are combined to make a specific
CA certificate issuing and mgt solutions for bank A,
brokerage B, institution C.

This is well represented by the PKCS7 (aka layered protection and
PKIX-protocol-independent mgt control framework) proposal
to this WG.

The notion I ventured (reflecting merely what the last meeting
asserted and concensually assented to, apparently - as with the
strangely missing WWW and S/MIME PKCS#10 feature whose assent was
consensually indiciated on at the previous meeting, but which
also failed to become realised in the PKIX-3 spec)  does not require
huge change to documents, nor does it require hold up of the current
publication schedules. It merely requires assent of *both*
authors to now go with the flow of the group and the interested
parties.

>From my mailbox, and having consulted the primary players, I think 
Carlise you are the only party not in consort with the proposal. As
an author whose document we are commenting, however, I respect your
judgement; so we should only do this is you too agree to move along
this path. I think the commercial relevance of PKIX-3 hinges on this
issue, however. Without PKIX-3, PKIX-1's profile judgements
may not be really that important either.

Id urge folk to respect the (expressed) will of the group to move
down this layering path. Precisely which wire format specs are agreed upon,
I for one dont really mind; this is not the issue for me. Id like PKCS7 as
defined now _at least_ to be indicated, and for the next generation
being developed in the IETF process with specifically these CA and other
environment's requirements in mind to be urged, and architected into
the PKIX-3 system and protocol requirements.

So, 

Just as the Oakley key agreement spec for IPSEC asserts that use of
DNS security/certs is mandatory (despite the fact that DNS security is
neither agreed, fully finished/documented, nor ratified within its
respective WG and the IESG security area directorate) so then,
with the appropriate language, we mandate an architectural
realationship to a PKCS7-like messaging service, but not required
that all implementations have to realise it.

just as SKIP specifies 4 cert types, not all of which need
to be implemented...

just as IPSEC std allows a multitude of non-interoperable 
security service and algoirithm profiles....

just as SSL/TLS allows an RSA client to fail to work with a DH-only
SSL server...

These std are real, and not pure. So PKIX-3 should be.

At 11:59 AM 1/28/97 -0500, Carlisle Adams wrote:
>Hi Russ,
>
>>----------
>>From: 	[email-masked][SMTP:[email-masked]]
>>Sent: 	Monday, January 27, 1997 7:08 AM
>>To: 	[email-masked]; [email-masked]
>>Subject: 	Re: PKCS#7 in PKIX-3
>>
>>
>>I think that we are near concensus on this point.  A single 
>>encapsulation mechanism would be ideal.  PKIX Part 3 contains one 
>>suggestion, and PKCS #7 contains another.  Carlise provided an 
>>analysis for the PKIX Part 3 approach.  PKCS #7 has a market 
>>share that should not be ignored, and the specification is open 
>>for reivew and update.  Further, RSA has agreed to work with the 
>>IETF on the PKCS "standards" and give configuration control to 
>>the IETF where standards track RFCs result.
>>
>>So, how does the group want to proceed?
>>
>>Russ
>
>
>At the risk of sounding repetitious, let me try to state a couple of
>things as clearly and succinctly as I possibly can.
>
>1) The PKIX-3 protocol, as currently specified, is able to handle
>protection for PKIX-3 messages in all situations (i.e., when
>end-entities already have public-key certificates (for various
>algorithms), and when they don't (but they do have some shared secret
>information with the other end)).  Furthermore, it allows the option of
>"no protection", so that if two parties want to take "bare" PKIX-3
>messages and wrap these using PKCS#7 (or any other mechanism) in
>circumstances for which this is appropriate, they are free to do so.
>
>2) The PKCS#7 enveloping protocol, as currently specified, is *not* able
>to handle protection for PKIX-3 messages in all situations (for reasons
>discussed in my previous posts).  It is perfectly adequate for *some*
>situations, but not all.
>
>
>I cannot imagine that it makes sense to make *mandatory* a mechanism
>which will not work in all situations.  It makes much more sense to make
>such a mechanism *optional*, so that it can be used wherever
>appropriate.  This is exactly what the current PKIX-3 protocol does.
>What is mandatory is the lowest common denominator which will work in
>every situation providing perfectly good protection; PKCS#7 is
>optionally allowed for any situation for which it is appropriate.
>
>The two statements, "PKCS#7 has a market share that should not be
>ignored" and "the specification is open for update" are contradictory.
>Changing PKCS#7 in any way (even if change control is given to the IETF)
>*does* ignore the market share, since it requires every implementation
>in the installed base to be modified.  If the market share should really
>not be ignored, then the current PKIX-3 makes the most sense since this
>allows the installed base to be used, as is, whenever this is
>appropriate.
>
>"How does the group want to proceed?"  Good question.  As I see it,
>there are two options.  We can keep what we have since it works in all
>situations, since it is easy to understand and implement, and since it
>respects the installed base by allowing code re-use wherever this can be
>done.  Or we can hold up progression of the PKIX management protocols
>for some indeterminate time (at least months; possibly longer) until
>PKCS#7 is "updated" to everyone's satisfaction.  [In my opinion, we are
>likely to find that the update, when finally complete, looks very much
>like the protection scheme we already have.]
>>
>--------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>---------------------------------------
>
>
-----=_=_ 673551678-6741220-12299792 _=_=---
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

-----=_=_ 673551678-6741220-12299792 _=_=-----

Date: Fri, 31 Jan 1997 9:38:00 -0500
From: "CHUCK.PHILIPP" <[email-masked]>
Subject: unsubscribe
To: "KEVIN.SHAVER" <[email-masked]>
To: [email-masked]
X400-Mts-Identifier: [ /P=USDOE/A=ATTMAIL/C=US/ ; c\hq\970131093314a ]

          unsubscribe

          [email-masked]

Date: Fri, 31 Jan 1997 14:02:07 +0100
From: Anette Byskov <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: (no subject)

subscribe

Date: Wed, 29 Jan 1997 08:06:24 -0500
To: FC97 Conference Distribution <[email-masked]>
From: Robert Hettinga <[email-masked]>
Subject: FC97: PRELIMINARY CONFERENCE PROGRAM

		      Financial Cryptography '97
		  February 24-28 1997, Anguilla, BWI
		       PRELIMINARY PROGRAM

General Information:

Financial Cryptography '97 (FC97) is a new conference on the security
of digital financial transactions.  The first meeting will be held on
the island of Anguilla in the British West Indies on February 24-28,
1997.  FC97 aims to bring together persons involved in both the
financial and data security fields to foster cooperation and exchange
of ideas.

Original papers were solicited on all aspects of financial data
security and digital commerce in general.

Program Committee:

Matthew Franklin, AT&T Laboratories--Research, Murray Hill, NJ, USA
Michael Froomkin, U. Miami School of Law, Coral Gables, FL, USA
Rafael Hirschfeld (Program Chair), CWI, Amsterdam, The Netherlands
Arjen Lenstra, Citibank, New York, NY, USA
Mark Manasse, Digital Equipment Corporation, Palo Alto, CA, USA
Kevin McCurley, Sandia Laboratories, Albuquerque, NM, USA
Charles Merrill, McCarter & English, Newark, NJ, USA
Clifford Neuman, Information Sciences Institute, Marina del Rey, CA, USA
Sholom Rosen, Citibank, New York, NY, USA
Israel Sendrovic, Federal Reserve Bank of New York, New York, NY, USA

Preliminary Conference Program for FC97:

Monday 24 February 1997

 830 --  905

    Anonymity Control in E-Cash Systems
    George Davida (University of Wisconsin, Milwaukee, WI, USA),
    Yair Frankel (Sandia National Laboratories, Albuquerque, NM, USA),
    Yiannis Tsiounis (Northeastern University, Boston, MA, USA),
    Moti Yung (CertCo, New York, NY, USA)

 905 --  940

    How to Make Personalized Web Browsing Simple, Secure, and Anonymous
    Eran Gabber, Phil Gibbons, Yossi Matias, Alain Mayer
        (Bell Laboratories, Lucent Technologies)

 940 -- 1015

    An Anonymous Networking Infrastructure and Virtual Intranets
    Jim McCoy (Electric Communities, Cupertino, CA, USA)

1015 -- 1045
    Coffee Break

1045 -- 1120

    Unlinkable Serial Transactions
    Paul F. Syverson (Naval Research Laboratory, Washington, DC, USA),
    Stuart G. Stubblebine (AT&T Labs--Research, Murray Hill, NJ, USA),
    David M. Goldschlag (Naval Research Laboratory, Washington, DC, USA)

1120 -- 1155

    Efficient Electronic Cash with Restricted Privacy
    Cristian Radu, Rene Govaerts, Joos Vandewalle
        (Katholieke Universiteit Leuven, Leuven, Belgium)

1155 -- 1230

    The SPEED Cipher
    Yuliang Zheng (Monash University, Melbourne, Australia)

Tuesday 25 February 1997

 830 --  930
    Invited Speaker
    To Be Announced

 930 -- 1005

    Smart Cards and Superhighways
        The technology-driven denationalisation of money
    David G.W. Birch, Neil A. McEvoy (Hyperion, Surrey, England)

1005 -- 1045
    Coffee Break

1045 -- 1120

    Fault Induction Attacks, Tamper Resistance, and Hostile Reverse
        Engineering in Perspective
    David P. Maher (AT&T Labs--Research, Murray Hill, NJ, USA)

1120 -- 1155

    Some Critical Remarks on "Dynamic Data Authentication" as
        specified in EMV '96
    Louis C. Guillou (CCETT, Cesson-Sevigne, France)

1155 -- 1230

    Single-chip implementation of a cryptosystem for financial
        applications
    Nikolaus Lange (SICAN Braunschweig GmbH, Braunschweig, Germany)

Wednesday 26 February 1997

 830 --  930
    Invited Speaker
    Ronald Rivest (MIT Lab for Computer Science, Cambridge, MA, USA)

 930 -- 1005

    Cyberbanking and Privacy: The Contracts Model
    Peter P. Swire (Ohio State University, Columbus, OH, USA)

1005 -- 1045
    Coffee Break

1045 -- 1120

    SVP: a Flexible Micropayment Scheme
    Jacques Stern, Serge Vaudenay (Ecole Normale Superieure, Paris, France)

1120 -- 1155

    An efficient micropayment system based on probabilistic polling
    Stanislaw Jarecki (MIT Lab for Computer Science, Cambridge, MA, USA),
    Andrew Odlyzko (AT&T Labs--Research, Murray Hill, NJ, USA)

1155 -- 1230

    On the continuum between on-line and off-line e-cash systems - I
    Yacov Yacobi (Microsoft, Redmond, WA, USA)

Thursday 27 February 1997

 830 --  905

    Auditable Metering with Lightweight Security
    Matthew K. Franklin, Dahlia Malkhi
        (AT&T Labs--Research, Murray Hill, NJ, USA)

 905 --  940

    Applying Anti-Trust Policies to Increase Trust in a Versatile
        E-Money System
    Markus Jakobsson (UCSD, La Jolla, CA, USA),
    Moti Yung (BTEC/CertCo, New York, NY, USA)

 940 -- 1015

    Towards Multiple-payment Schemes for Digital Money
    H. Pagnia, R. Jansen (University of Darmstadt, Darmstadt, Germany)

1015 -- 1045
    Coffee Break

1045 -- 1120

    Legal Issues in Cryptography
    Edward J. Radlo (Fenwick & West LLP, Palo Alto, CA, USA)

1120 -- 1230
    Panel Discussion
    Legal Issues of Digital Signatures
    Michael Froomkin (University of Miami School of Law, Miami, FL, USA),
    Charles Merrill (McCarter & English, Newark, NJ, USA),
    Benjamin Wright (Dallas, TX, USA)

Friday 28 February 1997

 830 --  930
    Invited Speaker
    To Be Announced

 930 -- 1005

    The Gateway Security Model in the Java Electronic Commerce Framework
    Theodore Goldstein (Sun Microsystems Laboratories/Javasoft)

1005 -- 1045
    Coffee Break

1045 -- 1120

    Highly Scalable On-line Payments Via Task Decoupling
    David William Kravitz (CertCo LLC, Albuquerque, NM, USA)

1120 -- 1155

    GUMP; Grand Unified Meta-Protocols
        Recipes for Simple, Standards-based Financial Cryptography
    Barbara Fox, Brian Beckman (Microsoft, Redmond, WA, USA)

1155 -- 1230

    Secure Network Communications and Secure Store & Forward Mechanisms
        with SAP R/3
    Bernhard Esslinger (SAP AG, Walldorf, Germany)

The conference will run from 8:30 AM to 12:30 PM, for five days, February
24-28 1997. Breakfast provided at the conference. The conference
organizers have left the afternoon and evenings open for corporate
sponsored events, for networking, and for recreational activities on the
resort island of Anguilla. Participants are encouraged to bring their families.

Workshop:

A 40-hour workshop, intended for anyone with commercial software
development experience who wants hands-on familiarity with the issues and
technology of financial cryptography, is planned in conjunction with FC97,
to be held during the week preceding the conference.

For more information on the workshop, please see the URL
http://www.cs.berkeley.edu/~iang/fc97/workshop.html .

For workshop registration, see the URL
http://www.offshore.com.ai/fc97/ .

Venue:

The InterIsland Hotel is a small 14-room guesthouse and a large,
comfortable 150 seat conference facility with additional space for a small
10-booth exhibition. The Inter-Island is on Road Bay, near Sandy Ground
Village, in the South Hill section of Anguilla. The conference, workshop,
and exhibition will have TCP/IP internet access. The rooms at the
InterIsland itself have sold out, but there are many other hotels
and guesthouses on Anguilla, and shuttle service to the conference will be
available.

Air Transportation and Hotels:

Air travel to Anguilla is typically done through either San Juan or St.
Thomas for US flights, or St. Maarten/Martin for flights from Europe and
the US.

Anguillan import duties are not imposed on hardware or software which will
leave the island again. There are no other taxes -- or cryptography
import/export restrictions -- on Anguilla.

Hotels range from spartan to luxurious, and more information about hotels
on Anquilla can be obtained from your travel agent, or at the URL
http://www.offshore.com.ai/fc97/ .

General Chairs:

Robert Hettinga, Shipwright/e$, Boston, MA, USA;
[email-masked]

Vincent Cate, Offshore Information Services, Anguilla, BWI;
[email-masked]

Conference, Exhibits, and Sponsorship Manager:

Julie Rackliffe, Boston, MA, USA;
[email-masked]

Workshop Leader:

Ian Goldberg, Berkeley, CA, USA;
[email-masked]

Registration:

You can register and pay for conference admission on the World Wide Web at
the URL http://www.offshore.com.ai/fc97/ .

The cost of the FC97 Conference is US$1,000.

Booths for the exhibition start at US$5,000 and include two conference
tickets. For more information about exhibit space, contact Julie Rackliffe,
[email-masked] . Sponsorship opportunities for FC97 are still available.

The cost of the workshop is US$5000, and includes meals but not lodging.
You can register for the workshop, which runs the week prior to the
conference, at the URL <http:/www.offshore.com.ai/fc97>

Financial Cryptography '97 is held in cooperation with the
International Association for Cryptologic Research.

It is sponsored by:

The Journal for Internet Banking and Commerce
<http://www.arraydev.com/commerce/JIBC/>
Offshore Information Services <http://www.offshore.com.ai/>
e$ <http://www.shipwright.com/rah/>
C2NET <http://www.c2.net/>
See Your Name Here <mailto: [email-masked]>

-----------------
Robert Hettinga ([email-masked]), Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"The cost of anything is the foregone alternative" -- Walter Johnson
The e$ Home Page: http://www.shipwright.com/rah/
FC97: Anguilla, anyone? http://www.ai/fc97/
"If *you* don't go to FC97, *I* don't go to FC97"

Date: Wed, 29 Jan 1997 07:41:52 -0500
To: FC97 Distribution <[email-masked]>
From: Robert Hettinga <[email-masked]>
Subject: Call for Participants: The Financial Cryptography 1997 Workshop for Senior Managers and IS Professionals

CALL FOR PARTICIPANTS
The Financial Cryptography 1997 (FC97)
Workshop for Senior Managers and IS Professionals
February 17-21, 1997
The InterIsland Hotel
Anguilla, BWI
<http://www.offshore.com.ai./fc97/>

Workshop Update: January 29, 1997

FC97 is sponsored by:

The Journal for Internet Banking and Commerce
<http://www.arraydev.com/commerce/JIBC/>
Offshore Information Services <http://www.offshore.com.ai/>
e$ <http://www.vmeng.com/rah/>
C2NET <http://www.c2.net/>
See Your Name Here! <mailto: [email-masked]>

FC97 Workshop for Senior Managers and IS Professionals
February 17-21, 1997

FC97 Conference and Exhibition,
February 24-28, 1997

The Inter-Island Hotel
Anguilla, BWI

Workshop and Conference Reservations: <http://www.offshore.com.ai./fc97/>

The world's first intensive financial cryptography workshop for senior
managers and IS professionals will be held Monday through Friday, February
17-21 1997, from 9:00am to 6:00pm, at the Inter-Island Hotel on the
Carribbean island of Anguilla.

This workshop will be the prelude to the world's first peer-reviewed
financial cryptography conference and commercial exhibition, Financial
Cryptography 1997 (FC97), which will be held the following week, February
24-28, 1997.

The goals of the combined workshop, conference and exhibition are:

-- to give senior managers and IS professionals a solid understanding of
the fundamentals of strong cryptgraphy as applied to financial
operations on public networks,

-- to provide a peer-reviewed forum for important research in financial
cryptography and the effects it will have on society, and,

-- to showcase the newest products in financial cryptography.

Workshop and Conference participants are encouraged to bring their
families, though Workshop participants should expect to be busy the first
week. :-).

The Workshop

Ian Goldberg, the Workshop chair, has picked an outstanding team of
instructors in financial cryptography and internet financial system
security to teach the courses in this workshop. The Workshop will consist
of 40 hours of intensive instruction and lab time over 5 days. Each student
will have their own internet workstation, and the lab will be open 24
hours.  The SSL internet commerce server used in the workshop will be
Stronghold, developed by C2NET, of Berkeley, California. For information on
Stronghold, please see <http://www.c2.net/>. Thanks to C2NET for their
gracious donation of this outstanding software to the FC97 Workshop.

Who Should Attend

The Workshop is intended for senior IS managers and technical professionals
who want to get completely up to speed on the design, development, and
implementation of financial cryptography systems, the core technology of
internet commerce. After the workshop, senior managers will have a hands-on
understanding the strengths and liabilities of currently available
financial cryptography and internet transaction security software and
hardware, and thus be able to make better asset allocation decisions in
this area of explosive technology growth. Senior technical professionals
with strong IS experience will be able to implement those technologies and
to pass on what they've learned to their clients and colleagues when they
return home.

The Workshop will be held in a casual but intensive atmosphere at the very
cutting edge of financial technology on the internet. Someone has likened
the experience to a financial cryptography bootcamp.  At the end, Workshop
attendees will be utterly conversant in cryptography as it applies to
finance, and will be quite prepared for the technical papers in the FC97
conference the following week. Workshop participants will not only know
what everyone else is doing now in internet commerce, but, more important,
because they understand the implications of strong financial cryptography
on ubiquitous public networks, they will be able to know what to do *next*.

The Workshop Leader

Ian Goldberg is a Ph.D. student in security and cryptography at the
University of California, Berkeley. Just last night, he cracked RSA Data
Security Inc.'s 40-bit challenge cipher in just under 3.5 hours. In late
1995, he discovered what became a much-publicized flaw in Netscape's
implementation of SSL. He is a recognized expert in electronic payment
systems, and in DigiCash's ecash digital bearer certificate protocol in
particular. He has produced several ecash clients for Unix and Windows, as
well as an ecash module for the Stronghold web server, which has extended
the existing ecash system for better security, privacy, and ease-of-use.

The Principal Instructors

Gary Howland worked on digital cash systems for DigiCash, and then moved to
Systemics, where he developed the SOX protocol, a flexible payments system
currently in use in a bond trading environment, soon to be available to the
public. He also developed the Cryptix and PGP libraries in Perl, and
assisted on the Cryptix and PGP library implementations in Java.

Adam Shostack is a security consultant based in the Boston area. He has
extensive background in designing, implementing and testing secure systems
for clients in the medical, computer, and financial industries. His recent
public work includes 'Apparent Weaknesses in the Security Dynamics Client
Server Protocol,' 'Source Code Review Guidelines,' and comparisons of
freely available cryptographic libraries. His clients include Fidelity
Investments and the Brigham and Women's Hospital, in Boston.

Additional Instructors

The Workshop will have student-to-instructor ratio of 5 to 1, not including
the Workshop leader. The Workshop will have an initial enrollment of 10
students, and an additional instructor will be added for each 5 students up
to a 25 student maximum enrollment.

Workshop Topics

The following is the complete list of topics that the workshop will cover:

      Security on the Internet
            Internet Protocols: IP, TCP, UDP
            Higher-level Protocols: Telnet, FTP, HTTP, SSL
            Solid Foundations for Cryptographic Systems
            A History of Internet Attacks
            Building Internet Firewalls
            Building a Bastion Host
            Turning your Bastion Host into a Web Server
            Non-internet Internet Security
      Cryptography
            The Need for Cryptography
            History of Cryptography
            Classical Methods
            Modern Methods
            Private and Public Key Cryptography
            Authentication vs. Security
            Certification and Public Key Infrastructures
            Cryptographic Protocols
            Engineering a Cryptographically Secure System
            Why Cryptography is Harder than it Looks
            Security Through Obscurity and How to Recognize Snake Oil
      Internet Payment Systems
            Payment models: coin-based, cheque-based, account-based
            Security Issues
            Privacy and Anonymity Issues
            Smartcards vs. Software
            Existing Payment Schemes
                  Credit Cards
                  First Virtual
                  CyberCash
                  DigiCash
            Forthcoming Payment Schemes
                  SET
                  Mondex
                  Millicent
                  micropayments
      Setting Up an ecash-Enabled Web Server
            Setting up the Web Server
            Signing up for ecash
            Installing the ecash Module
            Setting Prices
            Logging
            Advanced Methods
                  ecashiers
                  moneychangers

The workshop has been covered by Wired Magazine, and FC97 was the featured
conference in the January 1997 "Deductible Junkets" section. So, if you
have already decided to come to the FC97 Workshop and Conference, please
register and make your plane and hotel reservations as soon as possible.
Workshop space is extremely limited.

The price of the workshop is $5,000 U.S. You can pay for your FC97 workshop
ticket with Visa or MasterCard, with ecash, or with any of a number of
other internet commerce payment protocols, at the
regstriation site: <http://www.offshore.com.ai/fc97/>.

The workshop price includes meals (but not lodging) at the InterIsland
Hotel and lab space, plus the delivery and installation of hardware,
network access, internet commerce software, all to a location like
Anguilla. And, of course, 40 hours of instruction and structured lab
activity.  We have priced the workshop to be competitive with other
comprehensive business and professional technology workshops of similar
total session length.

In addition, the first 10 FC97 workshop participants will receive a 50%
reduction in their FC97 Conference and Exhibition fee, for a savings of
$500 off the $1,000 conference admission.

You can register, and pay for, your workshop ticket at:

<http://www.offshore.com.ai/fc97/>

Air Transportation and Hotels

Air travel to Anguilla is typically done through San Juan, St. Thomas or
St. Maarten/Martin. There are several non-stop flights a day from various
US and European locations. Connection through to Anguilla can be made
through American Eagle, or through LIAT, or in the case of St. Maarten,
with a short ferry ride to Anguilla. See your travel agent for details.

Anguilla's runway is 3600 feet, with a displaced threshold of 600 feet,
and can accomodate business jets. Obviously, you should talk to your
aviation staff for details about your own aircraft's capabilities in this
regard.

Anguilla import duties are not imposed on hardware or software which
will leave the island again, so, as long as you take it with you when
you leave, you won't pay import duties.

PLEASE NOTE: Your FC97 Workshop fee only covers *meals* at the InterIsland
Hotel. The InterIsland is actually a small guesthouse attached to a large
conference facility, and so rooms there are in short supply. Fortunately,
there are lots of small hotels and guesthouses nearby. For more information
on these hotels, please see <http://www.offshore.com.ai/fc97/> for more
information.

Other hotels on Anguilla range from spartan to luxurious, all within easy
walking or driving distance of the Workshop at the InterIsland. More
information about Anguillan hotels can be obtained from your travel agent,
or at <http://www.offshore.com.ai/fc97/>.

Registration and Information for Other FC97 Events

To register and pay for your ticket to the FC97 conference itself, see:
<http://www.offshore.com.ai/fc97/>

For information the selection of papers for the FC97 conference see:
<http://www.cwi.nl/conferences/FC97>

If you're interested in Exhibition space, please contact Julie Rackliffe:
<mailto:[email-masked]>

If you're interested in sponsoring FC97, also contact Julie Rackliffe:
<mailto:[email-masked]>

Financial Cryptography '97 is held in cooperation with the International
Association for Cryptologic Research. The conference proceedings will be
published on the web by the Journal for Internet Banking and Commerce.
<http://www.arraydev.com/commerce/JIBC/>.

The FC97 Organizing Committee:

Vince Cate and Bob Hettinga, General Chairs
Ray Hirschfeld, Conference Chair
Ian Goldberg, Workshop Chair
Julie Rackliffe, Conference, Exhibit, and Sponsorship Manager

And our sponsors...

The Journal for Internet Banking and Commerce
<http://www.arraydev.com/commerce/JIBC/>
Offshore Information Services <http://www.offshore.com.ai/>
e$ <http://www.vmeng.com/rah/>
C2NET <http://www.c2.net/>
See Your Name Here <mailto: [email-masked]>

-----------------
Robert Hettinga ([email-masked]), Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"The cost of anything is the foregone alternative" -- Walter Johnson
The e$ Home Page: http://www.shipwright.com/rah/
FC97: Anguilla, anyone? http://www.ai/fc97/
"If *you* don't go to FC97, *I* don't go to FC97"

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: PKCS#7 in PKIX-3
Date: Tue, 28 Jan 1997 11:59:45 -0500
Encoding: 73 TEXT

Hi Russ,

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Monday, January 27, 1997 7:08 AM
>To: 	[email-masked]; [email-masked]
>Subject: 	Re: PKCS#7 in PKIX-3
>
>
>I think that we are near concensus on this point.  A single 
>encapsulation mechanism would be ideal.  PKIX Part 3 contains one 
>suggestion, and PKCS #7 contains another.  Carlise provided an 
>analysis for the PKIX Part 3 approach.  PKCS #7 has a market 
>share that should not be ignored, and the specification is open 
>for reivew and update.  Further, RSA has agreed to work with the 
>IETF on the PKCS "standards" and give configuration control to 
>the IETF where standards track RFCs result.
>
>So, how does the group want to proceed?
>
>Russ

At the risk of sounding repetitious, let me try to state a couple of
things as clearly and succinctly as I possibly can.

1) The PKIX-3 protocol, as currently specified, is able to handle
protection for PKIX-3 messages in all situations (i.e., when
end-entities already have public-key certificates (for various
algorithms), and when they don't (but they do have some shared secret
information with the other end)).  Furthermore, it allows the option of
"no protection", so that if two parties want to take "bare" PKIX-3
messages and wrap these using PKCS#7 (or any other mechanism) in
circumstances for which this is appropriate, they are free to do so.

2) The PKCS#7 enveloping protocol, as currently specified, is *not* able
to handle protection for PKIX-3 messages in all situations (for reasons
discussed in my previous posts).  It is perfectly adequate for *some*
situations, but not all.

I cannot imagine that it makes sense to make *mandatory* a mechanism
which will not work in all situations.  It makes much more sense to make
such a mechanism *optional*, so that it can be used wherever
appropriate.  This is exactly what the current PKIX-3 protocol does.
What is mandatory is the lowest common denominator which will work in
every situation providing perfectly good protection; PKCS#7 is
optionally allowed for any situation for which it is appropriate.

The two statements, "PKCS#7 has a market share that should not be
ignored" and "the specification is open for update" are contradictory.
Changing PKCS#7 in any way (even if change control is given to the IETF)
*does* ignore the market share, since it requires every implementation
in the installed base to be modified.  If the market share should really
not be ignored, then the current PKIX-3 makes the most sense since this
allows the installed base to be used, as is, whenever this is
appropriate.

"How does the group want to proceed?"  Good question.  As I see it,
there are two options.  We can keep what we have since it works in all
situations, since it is easy to understand and implement, and since it
respects the installed base by allowing code re-use wherever this can be
done.  Or we can hold up progression of the PKIX management protocols
for some indeterminate time (at least months; possibly longer) until
PKCS#7 is "updated" to everyone's satisfaction.  [In my opinion, we are
likely to find that the update, when finally complete, looks very much
like the protection scheme we already have.]
>
--------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
---------------------------------------

Date: Mon, 27 Jan 97 12:08:41 
From: "Housley, Russ" <[email-masked]>
Encoding: 1321 Text
To: [email-masked], Peter Williams <[email-masked]>
Subject: Re: PKCS#7 in PKIX-3

Peter:

> My observation that an *unbundled* protection envelope (which encapulates 
> std information objects, rather than protects inner types) be the basis
> of the design is founded on such observation of the success of the above 
> approach in which componentware from multiple sources were bunded by the 
> customers without third-party invention, yet all parties in a staticaly
> configured certification system could agree the actual basis for technical 
> interworking and system msg flow with minimal effort, complete control
> over local security policy maintained in the hands of the procurer, and 
> selection from muliple sources of equivalent product/toolkit/protction 
> technology based on price, availability, and other value-adds  etc.

I think that we are near concensus on this point.  A single 
encapsulation mechanism would be ideal.  PKIX Part 3 contains one 
suggestion, and PKCS #7 contains another.  Carlise provided an 
analysis for the PKIX Part 3 approach.  PKCS #7 has a market 
share that should not be ignored, and the specification is open 
for reivew and update.  Further, RSA has agreed to work with the 
IETF on the PKCS "standards" and give configuration control to 
the IETF where standards track RFCs result.

So, how does the group want to proceed?

Russ

Date: Mon, 27 Jan 1997 15:48:09 -0500 (EST)
To: [email-masked]
From: sfd <[email-masked]>
Subject: Info on PKIX standards status

Would appreciate information on the status PKIX standards 

Where exactly are the WWW site or ftp sites

Edmond Van Hees
613-991-7413

From: [email-masked] (Yahya Al-Salqan)
Subject: Enterprise Security Workshop CFP
To: [email-masked]
Date: Fri, 24 Jan 1997 15:17:45 -0800 (PST)
Cc: [email-masked]

 			      Call For Papers 
 
  		  Second International Workshop on Enterprise Security
 
 			      June 18-20, 1997
 		    Massachusetts Institute of Technology (MIT),
 			Cambridge, Massachusetts, USA
 		
 		Co-sponsored by the IEEE Computer Society and the
 		Concurrent Engineering Research Center (CERC) at 
 			   West Virginia University

 ==============================================================================
 Enterprises are increasingly dependent on their information systems to
 support their business and workflow activities.  
 There is a need for universal electronic connectivity to support 
 interaction and cooperation between multiple  organizations.  
 This makes enterprise security and confidentiality more important, 
 but more difficult to achieve, as the multiple organizations may 
 have differences in their security policies and may have to interact 
 via an insecure Internet.  These inter-organizational enterprise systems 
 may be very large and so tools and techniques are needed
 to support the specification, analysis and implementation of security.
 
 This workshop will focus on the problems and challenges relating to
 enterprise security in inter-organizational systems. We aim to bring
 together principal players from both the internetwork and enterprise
 security community and will provide plenty of time for discussion.   Topics
 to be addressed include:
 
 	- Internet/Intranet security
         - Security infrastructure and protocols
 	- Java Security
 	- Specifying and Analyzing Enterprise Security Policy
         - Role-Based Access Control
         - Supporting enterprise security over the Internet
         - Conflicts and harmonization of inter- and intra-organizational
              Security
         - Distributed Database Security
         - Secure Transactions
         - Security in Workflow Process
         - Object-Oriented and CORBA Security
         - Secure Applications and Environments
         - Integrating Heterogeneous Security Environments
         - Managing inter-organizational Enterprise Security
 	- Internet Security protocols
 	- Security Algorithms
 
 This workshop will be part of the IEEE Sixth Workshops on Enabling
 Technologies: Infrastructure for Collaborative Enterprises (WET-ICE
 96) organized by the Concurrent Engineering Research Center (CERC)/
 West Virginia University.
 
 Important Dates:
 ================
 Papers Due			March 25, 1997
 Panel Proposals			March 18, 1997
 Authors notified of acceptance  April 21, 1997
 Workshop			June 18-20, 1997
 Camera Ready			June 28, 1997
 
 INFORMATION FOR AUTHORS OF PAPERS TO BE INCLUDED IN THE PROCEEDINGS 
 ===================================================================
 Mail six copies of an original (not submitted or published elsewhere)
 paper (double-spaced) of 3000-5000 words to one of the PC co-chairs. 
 Include the title of the paper, the name and affiliation of each author, a
 150-word abstract and no more than 8 keywords. The name, position,
 address, telephone number, and if possible, fax number and e-mail
 address of the author responsible for correspondence of the paper must
 be included.

 An e-mail submission in postscript format will be accepted.
 
 INFORMATION FOR PANEL ORGANIZERS 
 ================================
 Send six copies of panel proposals to one of the PC co-chairs. 
 Include the title, a 150-word scope statement, proposed session chair and
 panelists and their affiliations, the organizer's affiliation,
 address, telephone and fax number, and e-mail address.
 
 INFORMATION FOR AUTHORS OF POSITION PAPERS
 ==========================================
 Send six copies of position paper of 2-3 pages to one of the PC
 co-chairs. Include the title of the paper, the name and affiliation of
 each author, a 150-word abstract and no more than 8 keywords. The
 name, position, address, telephone number, and if possible, fax number
 and e-mail address of the author responsible for correspondence of the
 paper must be included. An accepted position paper will get less
 presentation time than full paper.  
 
 Workshop General Chair and Organizer
 ====================================
 	Yahya Al-Salqan, Ph.D.
 	Sun Microsystems
 	
 	[email-masked]
 
 Program Committee
 =================
 
 Program Committee Co-Chairs
 ==========================
 	Barbara C. Davis
 	Director of Technology
 	The Applied Knowledge Group
 	231 Market Place, #315
 	San Ramon, CA  94583-2785
 	USA
 
 	Tel. (888) 442-2785
 	FAX  (510) 275-9695
 	[email-masked]
 
 	Douglas Moughan
 	National Security Agency, R23
 	9800 Savage Rd.
 	Ft. Meade, Maryland 20755-6000
 	USA
 
 	[email-masked]

 
 Workshop Program Committee (Partial List):
 ==========================================
 Abdallah Abdallah, Birzeit University, Jerusalem
 Takasi Arano, NTT Corp, Japan
 Germano Caronni, ETH-Zurich, Switzerland
 Taher ElGamal, Netscape Corp., USA
 Stephen Farrell, Software and Systems Engineering, Ireland
 Takeo Hamada, Fujitsu, Japan
 Matthias Hirsch, BSI (Federal Department of Security in the Information
 	Technology-Germany
 Cynthia L Musselman, Sandia Lab, USA
 Lisa Pretty, Certicom Corp., Canada
 Jeffrey Parrett, LLNL, USA
 Sumitra Reddy, West Virginia University, USA
 Nahid Shahmehri, Linkoping University, Sweden
 Morris Sloman, Department of Computing: Imperial College, UK
 Badie Taha, Al-Quds University, Jerusalem
 Robert Thomys, BSI (Federal Department of Security in the Information
 	Technology-Germany
 Tatu Ylonen, SSH Communication Security, Finlad
 Nick Zhang, EIT, USA

 
 Internet Hot-line
 ================= 
 
 Information on Enterprise Security Workshop may be obtained through
 the WWW using the URL http://www.cerc.wvu.edu/SECWK/ 
 
 For more information on WET-ICE'97, visit the URL: 
 http://www.cerc.wvu.edu/WETICE/WETICE97.html
 
 One does not need to have a paper to attend the workshop.  

 

Date: Fri, 24 Jan 1997 15:43:47 +0000
From: [email-masked] (Suri Vangala)
Subject: LDAP over X25
To: [email-masked] (PKI WG)
Cc: [email-masked]
Encoding-Type: ISO8859.1

I am interested in  LDAP implementation over X25. If you know of such an
offering please advise.

From: "Suri Vangala" <[email-masked]>
To: "PKI WG" <[email-masked]>
Cc: <[email-masked]>
Subject: LDAP over X25
Date: Fri, 24 Jan 1997 15:43:47 -0500

I am interested in  LDAP implementation over X25. If you know of such an
offering please advise.

From: Mark Bartel <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Sample certificate sites
Date: Thu, 23 Jan 1997 21:14:52 -0500

Since some people expressed interest, I've posted a couple of sample =
certificates at =
http://www.magmacom.com/~mbartel/iso/certificates/samples/sample_certific=
ates.html, with the intention to put up a few more weird ones later, as =
well as "normal" ones with different algorithms.  These are all =
certificates that I've generated using the default configuration (well, =
MD2 is not the default hash algorithm).  The notable characteristics of =
the certificates are that they contain subject and issuer unique =
identifiers, use the basic constraints extension (marked critical), and =
one of them has a BMPString value in the subject name.  Peter, feel free =
to use these as examples in your style guide.

I've found that MSIE chokes on the unique identifiers, and won't read =
the BMPString value either.  But I'm going on faith that since the =
Cryptoapi 2.0 beta certificate viewer can read and display the =
BMPString, it's ok.  It's the only program I've found (other than my =
own, of course) that can.

- Mark Bartel

From: <[email-masked]>
To: [email-masked]
Report-Version: 2
>To: tandem.com!ietf-pkix
Date: Fri Jan 24 01:55:05     1997
Not-Delivered-To: edi!anu due to Message Transfer Agent Congestion (Cannot reach host. Delivery attempts will continue.)
X-SMTP-Diagnosis: UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed UX:cs: ERROR: smtp: TLI failure: t_connect failed
Content-Type: message
Content-Length: 1728

>From smtp Wed Jan 22 18:15 GMT 1997 remote from delhi
From: pca.dfn.de!kelm (Stefan Kelm)
Date: Wed, 22 Jan 1997 10:00:28 +0100 (MET)
Content-Length: 702
To: tandem.com!ietf-pkix, magmacom.com!mbartel 
Subject: Re: Sample certificate sites
Reply-To: [email-masked]

> 
> Entrust: http://www.entrust.com/
> 
> Xcert: http://www.xcert.com/
> 

You might also want to take a look at:

	http://www.pca.dfn.de/eng/team/ske/pem-dok.html#CA

where I collected links to several certification authorities some
of which offer sample certificates or testing of certificates, too.

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]

Date: Wed, 22 Jan 1997 09:43:27 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Interpretation of KeyUsage?

> 
> "My definition" stemmed from the suggestion by Russ Housley. It wasn't 
> my intention to propose a change to the X.509v3 DAM. However, just the
> fact that we're having this discussion indicates that the text in the
> DAM under subclause 12.2.2.3 might be too vague.
>
> [...]
> 
> Have we reached a common understanding of this issue?

Yes, I believe so :-).

I agree that there could be a little more explanation/clarification
(in the form of a "Note --"?) in DAM 1 to X.509, and a lot more in pkix
part 1.  I understand that Hoyt will consider redline changes to the DAM
(ftp://nc-17.ma02.bull.com/pub/OSIdirectory/Certificates/Certificates1Dec...)
in March, despite the document being labeled "Final Final draft (1 December)",
so perhaps a small clarification is possible.

I also agree that it is necessary to be able to issue a non-repudiation
key that should not be used for authentication (although it's up to the
signer, not the verifier as in most other cases, to enforce that
restriction).  It's also a good idea for signers never to sign
a bare "random" challenge, for the reason you suggest.  The signer
should always mix in his own random component before signing, and
the bank should never honor an e-check of the form
"pay $1000 <random garbage>" or "<random garbage> pay $1000", it
should verify that the transaction is in the exact form required.

Date: 	Wed, 22 Jan 97 08:26:23 EST
From: "Administrator" <[email-masked]>
Encoding: 22 Text, 23 Text
To: [email-masked]
Subject: Message not deliverable

> 
> Entrust: http://www.entrust.com/
> 
> Xcert: http://www.xcert.com/
> 

You might also want to take a look at:

 http://www.pca.dfn.de/eng/team/ske/pem-dok.html#CA

where I collected links to several certification authorities some
of which offer sample certificates or testing of certificates, too.

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]

From: Stefan Kelm <[email-masked]>
Date:     Wed, 22 Jan 1997 10:00:28 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: Sample certificate sites
Reply-To: [email-masked]

Date: Wed, 22 Jan 1997 12:54:48 +0100
From: Lars Johansson <[email-masked]>
Organization: PSab
To: "David P. Kemp" <[email-masked]>
Cc: [email-masked]
Subject: Re: Interpretation of KeyUsage?

David P. Kemp wrote:
> 
> Amendment 1 to ISO 9594-8:1995(E) includes the following text under
> 12.2.2.3 Key Usage field:
> 
>  "Bits in the KeyUsage type are as follows:
> 
>    a) digitalSignature: for verifying digital signatures that have purposes
>       other than those identified in b), f), or g) below;
> 
>    b) nonRepudiation: for verifying digital signatures used in providing
>       a nonrepudiation service which protects against the signing entity
>       falsely denying some action (excluding certificate or CRL signing,
>       as in f) or g) below);
> 
>     ...
> 
>    f) keyCertSign: ...
>    g) cRLSign: ..."
> 
> My interpretation of this text is that a key which may be used only for
> authentication would have 'digitalSignature' set and 'nonRepudiation'
> not set (as everyone agrees, above).  But a key which is to be used
> only for signing contracts (and not for authentication) would have
> 'nonRepudiation' set and 'digitalSignature' *not* set.
> 
> A single key which may used for both purposes would, of course,
> have both bits set.  Lars' definition would disallow the issuance of
> a single key that could be used for both purposes, so I prefer the
> current DAM definition as it stands.

David,

"My definition" stemmed from the suggestion by Russ Housley. It wasn't 
my intention to propose a change to the X.509v3 DAM. However, just the
fact that we're having this discussion indicates that the text in the
DAM under subclause 12.2.2.3 might be too vague.

Your interpratation of KeyUsage is the same as what is today stated in
the SEIS certificate specification. I think that both yours and Russ'
interpretation are ok as long as we agree on one or the other. Not both
at the same time.

So, what I originally wanted was a key that may _only_ be used for non-
repudiation services and should by no means _never_ be used in
authentication 
protocols. If it would, then somebody may ask me to authenticate myself
by 
signing some random data that could be a hash of a text that give that
other
person permission to withdraw $1000 from my bank account. Since I would
only see the "random" hash value, I couldn't have any chance to check
what 
I was actually signing. That's why I wouldn't want to mix my
authentication
key with my key for non-repudiation. The question is how that should be
done according to the X.509v3 DAM.

Nevertheless, I understand the point you're making in your comment that
it should be _possible_ to indicate that a key may be used for both
authentication and non-repudiation. It could be useful for keys issued
under a less restrictive security policy, e.g. software keys for www-
browsers. So should we then stick to the original definition as you
propose?

Have we reached a common understanding of this issue?

Kind regards,
/Lars Johansson

From: Stefan Kelm <[email-masked]>
Date: Wed, 22 Jan 1997 10:00:28 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: Sample certificate sites
Reply-To: [email-masked]

> 
> Entrust: http://www.entrust.com/
> 
> Xcert: http://www.xcert.com/
> 

You might also want to take a look at:

	http://www.pca.dfn.de/eng/team/ske/pem-dok.html#CA

where I collected links to several certification authorities some
of which offer sample certificates or testing of certificates, too.

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]

From: Mark Bartel <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Sample certificate sites
Date: Tue, 21 Jan 1997 23:07:18 -0500

Here's a short list of places to get certificates.  When I have more =
time, I'll go through my bookmarks and make a fuller list and also make =
available some sample certificates I've created (including ones =
containing BMPString and UniversalString values, for which I still =
haven't found a source).

Verisign: http://www.verisign.com/ (both for creating certificates and =
querying for certificates; you can find some old Netscape certificates =
here that contain different extensions marked critical)

Entrust: http://www.entrust.com/

Xcert: http://www.xcert.com/

Some useful tools are SSLeay (http://psych.psy.uq.oz.au/~ftp/Crypto/), =
Certificate Viewer (beta - http://www.iol.ie/~formal), Secude (beta - =
http://www.darmstadt.gmd.de/secude), and the Cryptoapi 2.0 beta, all of =
which contain certificate viewers.  Certificate Viewer also contains =
about a dozen sample certificates from all kinds of different places. =
The Cryptoapi viewer is the only one that will actually parse BMPString =
and UniversalString values.

- Mark Bartel=20

From: Mark Bartel <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Questions about character sets and their encodings
Date: Tue, 21 Jan 1997 23:09:11 -0500

I finally managed to confirm my implementation of both UniversalString =
and BMPString against somebody else, namely the certificate dump program =
in the Cryptoapi 2.0 beta.  I feel better now.

Hoyt, just after I responded to your last message, I found the version =
of DirectoryString that you list in the SET specification (it occurred =
to me that it would have reasonably up-to-date versions of this stuff).  =
Furthermore, it states that compliant implementations should only =
generate PrintableStrings and BMPStrings; TeletexStrings and =
UniversalStrings are forbidden (not just depreciated).

So in light of this preference for avoiding TeletexStrings and =
UniversalStrings that SET dictates and other people have expressed, my =
certificate creator now generates PrintableStrings if possible, =
TeletexStrings if the characters are in 7-bit ASCII (no need for SET =
compliance in this application), and BMPStrings otherwise.  I'll accept =
anything, although I won't interpret escape codes in TeletexStrings.

 (An aside for the general amusement of this list:  I finally got a =
response out the SCC [Standards Council of Canada] about my request for =
ISO/IEC 10646-1; it's only about US$350, and US$12 for each of the four =
amendments [translating from Canadian dollars here].  I thought the ITU =
was bad.)

- Mark Bartel

-----Original Message-----
From:	KESTERSON.H [SMTP:[email-masked]]
Sent:	Tuesday, January 21, 1997 5:30 PM
To:	Mark Bartel; [email-masked]'
Cc:	[email-masked]
Subject:	Re[2]: Questions about character sets and their encodings

salString is somewhat of an irritation to me (a long story that i prefer =
to tell
in person). we added bmpstring via technical corrigendum 1 to x.520. =
there
should also be a change to the conformance statement in 591

here is unformatted text. ;look in v9 of implementor's guide

Page 3

Clause 5

Replace the ASN.1 specification with:

    DirectoryString { INTEGER : maxSize } ::=3D CHOICE {
        teletexString       TeletexString (SIZE (1..maxSize)),
        printableString PrintableString (SIZE (1..maxSize)),
        bmpString       BMPString (SIZE (1..maxSize)),
        universalString UniversalString (SIZE (1..maxSize)) }

Replace the final paragraph with:

Some implementations of the Directory do not support BMPString or
UniversalString, and will not be able to generate, match, or display =
attributes
having such a syntax.

Page 15

Clause 6.1.1

In the first paragraph, replace the text "attribute value of type
DirectoryString" with:

attribute value of type PrintableString, NumericString, TeletexString,
BMPString, UniversalString, or DirectoryString

Page 15 - 17

Clause 6.1.2 - 6.1.6

In the first paragraph, replace the text "attribute value of type
DirectoryString" with:

attribute value whose type is one of the ones listed in 6.1.1

_________________________________________________________________________=
______
Subject: Re: Questions about character sets and their encodings
From:    Mark Bartel <[email-masked]> at az05-smtp
Date:    1/21/97  11:17

Hoyt,

In the version of X.520 that I have, it says (at the start of section 2, =
just
before 5.1)

DirectoryString { INTEGER : maxSize } ::=3D CHOICE {
    teletexString   TeletexString (SIZE (1..maxSize)),
    printableString PrintableString (SIZE (1..maxSize)),
    universalString UniversalString (SIZE (1..maxSize)) }

This is 1993 version however, has it been revised to include BMPString?  =
I'd be
quite happy to use BMPString if I could.  As far as I've heard, BMP and =
Unicode
are identical, and my products use Unicode internally.

And I'm aware of the ITU site, and have gotten several recommendations =
from
there.  However, X.680 and X.681 are not among the recommendations that =
are
available electronically.  I really hate the idea of ordering a paper =
copy, and
of having to use snail mail, although I suspect I may break down soon. =20

I don't think I really need ISO/IEC 10646-1, because all I need to know =
is what
"4-octet canonical form" is (or if I use BMPString, what "2-octet BMP =
form" is).
 I can't imagine that those forms are anything other than the obvious =
(four
octets, big endian format, or in the case of BMPString, two octets, big =
endian)
but nobody seems to be able to confirm this.

- Mark Bartel

>-----Original Message-----
>From:  KESTERSON.H [SMTP:[email-masked]]
>Sent:  Monday, January 20, 1997 5:18 PM
>To:    Borka Jerman-Blazic; [email-masked]
>Cc:    [email-masked]; [email-masked]
>Subject:   Re: Questions about character sets and their encodings
>
>asn1. also defines the type BMPString which is the Basic Multilingual =
Plane
>character set. This is the set of 16 bit character encodings that is
>"supposedly" equivalent to the unicode set (the intent was to make =
unicode and
>BMP identical - i believe they succeeded but i never verified it by =
checking
the
>final version of the standard). the advantage of this asn.1 type is =
that it
uses
>the asn.1 tage to indicate the selection from the rather large =
UniversalString
>set of character encodings. x.500 permits the use of BMPString in a
>distinguished name. therefore, the standard permits this characterset =
in a
>certificate, subject to profiles of course
>although 646 provides greater interoperability, one should consider =
national
language=20
>and localization requirements for your product. the BMP set (Unicode) =
from
10646=20
>is the best character set to address such requirements.
>the tag value for UniversalString is 28; BMPString is 30. The asn.1 =
standard
does=20
>not recommend the use of UniversalString without constraints.
>you can order and retrieve itu recommendations electronically. see =
http://
www.itu.ch/POD/itut-123.html.=20
>this can help you get the asn.1 documents. iso does not offer such a =
service;
however,=20
>i suspect that you would want a paper copy of 10646 since display of =
the glyphs

>from an electronic text would be a challenge for the font capability of =
most
systems.
>hoyt
>________________________________________________________________________=
_______
>Subject:   Questions about character sets and their encodings
>From:  Borka Jerman-Blazic <[email-masked]> at az05-smtp
>Date:  1/20/97  11:32
>
>
>
>>I've been searching for resources on the web on character sets for
>>ASN.1 types, but haven't been able to find what I need.  Does anybody
>>know of such resources?
>
>>More specifically, my questions are:
>
>>        IA5String: I've heard this is just 7-bit ASCII, but is that
>>true?
>
>
>Yes, IA5String is the same as 7-bit ASCII or ISO IRV 646 with one =
exception
(the=20
>old one) instead of dollar sign it could be currency sign.
>>        TeletexString: I understand that one can select different
>>character sets with escape codes; does anybody have the set of escape
>>codes and character sets they select?
>
>
>TeleString is mainly T.61 or T.50 (one of them is currently used in =
Teletex) or

>its international ISO version ISO 6937.  This is 8-bit coding with =
changable
use=20
>of a code lenght per character e.g. the accented letter of Latin =
alphabet are
coded=20
>with 2 bytes, one for the so called "non-spacing" character (the acent =
or
diacritic=20
>sign) and the other for the basic letter.
>>        UniversalString: X.690 says that this is encoded in 4-octet
>>canonical form, which I would imagine is 4 bytes, big-endian.  Also, I
>>believe that the subset of the 32-bit space with the high 16 bits set
>>to 0 is equivalent to Unicode.  Am I correct in these assumptions?
>>X.690 says a bunch of things that I don't really understand (probably
>>because I don't have X.680) about character string types and their
>>encodings.  Also, what is the tag for UniversalString?  Does anybody
>>have examples of certificates with UniversalString values in the
>>Issuer or Subject?  I've heard that Microsoft certificates do, but
>>when I queried Verisign for Microsoft certificates they didn't.  I
>>couldn't get ahold of any Microsoft products that actually issue
>>certificates to check that possibility.
>
>UniversalString allows all methods of coding e.g. with the ISO 2022 =
standard
which=20
>is basic standard for code extension techniques in 7-bit and 8-bit =
environment
you=20
>can use any of the registred code tables in the International Register =
of Coded

>Character sets. The invocation is done with shift functions and there =
are 4 of
them:=20
>Single shift and locked single shift for one characater from the code =
table and

>2 others for invocation of the whole coded charcater set table. Every =
code
table=20
>has his registered escape sequence for invocation, thus ISO 10 646 =
which first
Multilingual=20
>plane is equal to Unicode has its one escape sequence and thus can be =
invoced
in=20
>the UniversalString.
>The other way of use of different coded character sets  in =
UniversalString is
with=20
>an  announcement mechanisms which are specified in ASN.1 or ISO 8825 =
and ISO
8824=20
>standard. Every used coded charcater set has his OID.=20
>
>>I know I could probably get the answers by ordering ISO/IEC 10646-1
>>and X.680, but from what I can see I'd have to do it snail mail.  I'd
>>rather not.
>
>My recommendation is to use ISO 10 646 as this is the only remedy for =
the mess
in=20
>the charcater set world.
>
>I am very interested in the solutions used by Microsoft. The new =
version of the

>X.500 standard allows used of "context" for different attributes which =
means
specification=20
>of the used coded charcater set.  Without proper spelling of people =
names and
addresses=20
>there will be no value of the certificates as the names will differ =
from the
names=20
>on the documents e.g. on the credit cards.
>
>Regards,
>
>
>Borka Jerman-blazic
>Chair, [email-masked]
>
>TERENA is European Association of the Research and Academic Networks
>
>
>
>
>

=00

Date: Tue, 21 Jan 1997 15:29:45 -0700
From: [email-masked] (KESTERSON.H)
Subject: Re[2]: Questions about character sets and their encodings
To: Mark Bartel <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Content-Description: cc:Mail note part

salString is somewhat of an irritation to me (a long story that i prefer to tell
in person). we added bmpstring via technical corrigendum 1 to x.520. there
should also be a change to the conformance statement in 591

here is unformatted text. ;look in v9 of implementor's guide

Page 3

Clause 5

Replace the ASN.1 specification with:

    DirectoryString { INTEGER : maxSize } ::= CHOICE {
        teletexString       TeletexString (SIZE (1..maxSize)),
        printableString PrintableString (SIZE (1..maxSize)),
        bmpString       BMPString (SIZE (1..maxSize)),
        universalString UniversalString (SIZE (1..maxSize)) }

Replace the final paragraph with:

Some implementations of the Directory do not support BMPString or
UniversalString, and will not be able to generate, match, or display attributes
having such a syntax.

Page 15

Clause 6.1.1

In the first paragraph, replace the text "attribute value of type
DirectoryString" with:

attribute value of type PrintableString, NumericString, TeletexString,
BMPString, UniversalString, or DirectoryString

Page 15 - 17

Clause 6.1.2 - 6.1.6

In the first paragraph, replace the text "attribute value of type
DirectoryString" with:

attribute value whose type is one of the ones listed in 6.1.1

_______________________________________________________________________________
Subject: Re: Questions about character sets and their encodings
From:    Mark Bartel <[email-masked]> at az05-smtp
Date:    1/21/97  11:17

Hoyt,

In the version of X.520 that I have, it says (at the start of section 2, just
before 5.1)

DirectoryString { INTEGER : maxSize } ::= CHOICE {
    teletexString   TeletexString (SIZE (1..maxSize)),
    printableString PrintableString (SIZE (1..maxSize)),
    universalString UniversalString (SIZE (1..maxSize)) }

This is 1993 version however, has it been revised to include BMPString?  I'd be
quite happy to use BMPString if I could.  As far as I've heard, BMP and Unicode
are identical, and my products use Unicode internally.

And I'm aware of the ITU site, and have gotten several recommendations from
there.  However, X.680 and X.681 are not among the recommendations that are
available electronically.  I really hate the idea of ordering a paper copy, and
of having to use snail mail, although I suspect I may break down soon.  

I don't think I really need ISO/IEC 10646-1, because all I need to know is what
"4-octet canonical form" is (or if I use BMPString, what "2-octet BMP form" is).
 I can't imagine that those forms are anything other than the obvious (four
octets, big endian format, or in the case of BMPString, two octets, big endian)
but nobody seems to be able to confirm this.

- Mark Bartel

>-----Original Message-----
>From:  KESTERSON.H [SMTP:[email-masked]]
>Sent:  Monday, January 20, 1997 5:18 PM
>To:    Borka Jerman-Blazic; [email-masked]
>Cc:    [email-masked]; [email-masked]
>Subject:   Re: Questions about character sets and their encodings
>
>asn1. also defines the type BMPString which is the Basic Multilingual Plane
>character set. This is the set of 16 bit character encodings that is
>"supposedly" equivalent to the unicode set (the intent was to make unicode and
>BMP identical - i believe they succeeded but i never verified it by checking
the
>final version of the standard). the advantage of this asn.1 type is that it
uses
>the asn.1 tage to indicate the selection from the rather large UniversalString
>set of character encodings. x.500 permits the use of BMPString in a
>distinguished name. therefore, the standard permits this characterset in a
>certificate, subject to profiles of course
>although 646 provides greater interoperability, one should consider national
language 
>and localization requirements for your product. the BMP set (Unicode) from
10646 
>is the best character set to address such requirements.
>the tag value for UniversalString is 28; BMPString is 30. The asn.1 standard
does 
>not recommend the use of UniversalString without constraints.
>you can order and retrieve itu recommendations electronically. see http://
www.itu.ch/POD/itut-123.html. 
>this can help you get the asn.1 documents. iso does not offer such a service;
however, 
>i suspect that you would want a paper copy of 10646 since display of the glyphs

>from an electronic text would be a challenge for the font capability of most
systems.
>hoyt
>_______________________________________________________________________________
>Subject:   Questions about character sets and their encodings
>From:  Borka Jerman-Blazic <[email-masked]> at az05-smtp
>Date:  1/20/97  11:32
>
>
>
>>I've been searching for resources on the web on character sets for
>>ASN.1 types, but haven't been able to find what I need.  Does anybody
>>know of such resources?
>
>>More specifically, my questions are:
>
>>        IA5String: I've heard this is just 7-bit ASCII, but is that
>>true?
>
>
>Yes, IA5String is the same as 7-bit ASCII or ISO IRV 646 with one exception
(the 
>old one) instead of dollar sign it could be currency sign.
>>        TeletexString: I understand that one can select different
>>character sets with escape codes; does anybody have the set of escape
>>codes and character sets they select?
>
>
>TeleString is mainly T.61 or T.50 (one of them is currently used in Teletex) or

>its international ISO version ISO 6937.  This is 8-bit coding with changable
use 
>of a code lenght per character e.g. the accented letter of Latin alphabet are
coded 
>with 2 bytes, one for the so called "non-spacing" character (the acent or
diacritic 
>sign) and the other for the basic letter.
>>        UniversalString: X.690 says that this is encoded in 4-octet
>>canonical form, which I would imagine is 4 bytes, big-endian.  Also, I
>>believe that the subset of the 32-bit space with the high 16 bits set
>>to 0 is equivalent to Unicode.  Am I correct in these assumptions?
>>X.690 says a bunch of things that I don't really understand (probably
>>because I don't have X.680) about character string types and their
>>encodings.  Also, what is the tag for UniversalString?  Does anybody
>>have examples of certificates with UniversalString values in the
>>Issuer or Subject?  I've heard that Microsoft certificates do, but
>>when I queried Verisign for Microsoft certificates they didn't.  I
>>couldn't get ahold of any Microsoft products that actually issue
>>certificates to check that possibility.
>
>UniversalString allows all methods of coding e.g. with the ISO 2022 standard
which 
>is basic standard for code extension techniques in 7-bit and 8-bit environment
you 
>can use any of the registred code tables in the International Register of Coded

>Character sets. The invocation is done with shift functions and there are 4 of
them: 
>Single shift and locked single shift for one characater from the code table and

>2 others for invocation of the whole coded charcater set table. Every code
table 
>has his registered escape sequence for invocation, thus ISO 10 646 which first
Multilingual 
>plane is equal to Unicode has its one escape sequence and thus can be invoced
in 
>the UniversalString.
>The other way of use of different coded character sets  in UniversalString is
with 
>an  announcement mechanisms which are specified in ASN.1 or ISO 8825 and ISO
8824 
>standard. Every used coded charcater set has his OID. 
>
>>I know I could probably get the answers by ordering ISO/IEC 10646-1
>>and X.680, but from what I can see I'd have to do it snail mail.  I'd
>>rather not.
>
>My recommendation is to use ISO 10 646 as this is the only remedy for the mess
in 
>the charcater set world.
>
>I am very interested in the solutions used by Microsoft. The new version of the

>X.500 standard allows used of "context" for different attributes which means
specification 
>of the used coded charcater set.  Without proper spelling of people names and
addresses 
>there will be no value of the certificates as the names will differ from the
names 
>on the documents e.g. on the credit cards.
>
>Regards,
>
>
>Borka Jerman-blazic
>Chair, [email-masked]
>
>TERENA is European Association of the Research and Academic Networks
>
>
>
>
>

Date: Mon, 20 Jan 97 14:21:45 -0800
From: "Kirpal Khalsa"<[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re:Questions about character sets and their encodings

Hi, 

I'm moderately confused by some of the information being passed regarding T.50.
I have a copy dated 09/92 titled International Reference Alphabet (IRA)
(Formerly International Alphabet No. 5 or IA5).

There were two characters that used to be ambiguous (also referred to as
alternate graphic characters): hex23 (2/3) which could be either a pound sign or
a number sign and hex24 (2/4) which could be either a dollar sign or the
universal currency sign. This is still referenced in Table 2. You can have
versions of T.50 that are different from the IRV by selecting non-IRV
combinations of 2/3 and 2/4.

However the G0 part of the IRV shown in Table 5 no longer has alternates. It
specifies 2/3 as the number sign and 2/4 as the dollar sign. So as far as I can
tell, the IRV of IA5 is now identical to 7-bit ASCII.

Am I missing something?

Regards,
    Kirpal Khalsa
    Lotus Development

>>I've been searching for resources on the web on character sets for
>>ASN.1 types, but haven't been able to find what I need.  Does anybody
>>know of such resources?
>>More specifically, my questions are:
>>  IA5String: I've heard this is just 7-bit ASCII, but is that true?

>Yes, IA5String is the same as 7-bit ASCII or ISO IRV 646 with one
>exception (the old one) instead of dollar sign it could be
>currency sign.

From: Mark Bartel <[email-masked]>
To: "'Borka Jerman-Blazic'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Questions about character sets and their encodings 
Date: Tue, 21 Jan 1997 11:17:50 -0500

Borka,

There are two ISO 10646-1 types:  UniversalString and BMPString. =
UniversalString is encoded in "4-octet canonical form,"  (X.690, 8.20.7) =
whatever that is (that's what I'm trying to determine!) and BMPString is =
encoded in "2-octet BMP form," (X.690, 8.20.8) whatever that is.  I =
assume they're encoded as I suggested (in the obvious fashion), but =
there doesn't seem to be anybody who can confirm this.  I'd rather use =
BMPString, but I'm assuming I can't because DirectoryString only gives =
the choice of TeletexString, PrintableString, and UniversalString.

As an aside, the tag number for UniversalString is 28, for BMPString is =
30, and for the unrestricted type (GeneralString?) is 29.

- Mark Bartel

-----Original Message-----
From:	Borka Jerman-Blazic [SMTP:[email-masked]]
Sent:	Tuesday, January 21, 1997 2:12 AM
To:	Mark Bartel
Cc:	Borka Jerman-Blazic; [email-masked]; =
[email-masked]; [email-masked]
Subject:	Re: Questions about character sets and their encodings=20

Mark,

You are right, I did a mistake taking UniversalString for GeneralString
(which allows all 2022 coding and announcements).

Obviously UniversalString is rserved for BMP of ISO 10 646, canonical =
form
- 4 bytes per charcater. What is not clear here is the 4 bytes, which =
are
used when you specify the group, the plane and the row and cell
of every charcater. If it is just BMP ISO 10 646 1.1 then you do not =
need
the first two bytes. Using them just take more space and bandwith.
It will be intersting to see who else has done the same implementation
as you. However. it is true that very soon we will have another plane
which will code all ideographic scripts. That was solution recently
endorsed by WG 2 of ISO JTC1 SC2.

Regards,

Borka

> Borka,=20
>=20
> It sounds to me like you are refering (in the quoted text at the end
> of this message) to the unrestricted string type, rather than the
> UniversalString type.  X.690 describes a rather complicated structure
> (in 8.21.6) for that type that includes the object identifiers and
> such.  But X.690 says:
>=20
>  8.20.5 For restricted character string apart from UniversalString and
>  BMPString the octet string shall contain the octets specified in ISO
>  2022 for encodings in an 8-bit environment, using the escape sequence
>  and character codings registered in accordance with ISO 2375.
>=20
> This would seem to imply that UniversalString and BMPString don't use
> escape sequences, since escape sequences aren't mentioned anywhere
> else in reference to UniversalString.  Which would make sense, because
> it seems to me that the whole point of UniversalString is to be a
> "flat" character set, where you don't have to worry about escape
> sequences and modes.  This seems to be confirmed by the fact that
> UniversalString doesn't appear in "Table 3 - Use of escape sequences",
> and also by
>=20
>  8.20.7 For the "UniversalString" type, the octet string shall contain
>  the octets specified in ISO/IEC 10646-1, using the 4-octet canonical
>  form (see 14.2 of ISO/IEC 10646-1).  Control functions and signatures
>  shall not be used.
>=20
> Since all values in the character set can be reproduced in 4 octets,
> there is no reason for escape codes.
>=20
> I think my current encoding is correct (nobody said my example was
> wrong) but I'd like to see other examples of UniversalString encodings
> (not necessarily even in certificates!), both because I'm paranoid :)
> and because nobody has indicated that they believe my encoding to be
> correct.  Knowing this list, I wouldn't be surprised if it was just
> that the few people who actually know (at this point in time it's kind
> of an obscure issue) just were too busy to respond.  But up until now,
> I haven't been able to find a single example of a UniversalString DER
> or BER encoding, in or out of a certificate.  Arrrggghhh!  Isn't
> *anybody* using UniversalString?  Is anybody reading this thread?
>=20
> - Mark Bartel
>=20

From: Mark Bartel <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: Questions about character sets and their encodings
Date: Tue, 21 Jan 1997 11:17:48 -0500

Hoyt,

In the version of X.520 that I have, it says (at the start of section 2, =
just before 5.1)

DirectoryString { INTEGER : maxSize } ::=3D CHOICE {
	teletexString	TeletexString (SIZE (1..maxSize)),
	printableString	PrintableString (SIZE (1..maxSize)),
	universalString	UniversalString (SIZE (1..maxSize)) }

This is 1993 version however, has it been revised to include BMPString?  =
I'd be quite happy to use BMPString if I could.  As far as I've heard, =
BMP and Unicode are identical, and my products use Unicode internally.

And I'm aware of the ITU site, and have gotten several recommendations =
from there.  However, X.680 and X.681 are not among the recommendations =
that are available electronically.  I really hate the idea of ordering a =
paper copy, and of having to use snail mail, although I suspect I may =
break down soon. =20

I don't think I really need ISO/IEC 10646-1, because all I need to know =
is what "4-octet canonical form" is (or if I use BMPString, what =
"2-octet BMP form" is).  I can't imagine that those forms are anything =
other than the obvious (four octets, big endian format, or in the case =
of BMPString, two octets, big endian) but nobody seems to be able to =
confirm this.

- Mark Bartel

>-----Original Message-----
>From:	KESTERSON.H [SMTP:[email-masked]]
>Sent:	Monday, January 20, 1997 5:18 PM
>To:	Borka Jerman-Blazic; [email-masked]
>Cc:	[email-masked]; [email-masked]
>Subject:	Re: Questions about character sets and their encodings
>
>asn1. also defines the type BMPString which is the Basic Multilingual =
Plane
>character set. This is the set of 16 bit character encodings that is
>"supposedly" equivalent to the unicode set (the intent was to make =
unicode and
>BMP identical - i believe they succeeded but i never verified it by =
checking the
>final version of the standard). the advantage of this asn.1 type is =
that it uses
>the asn.1 tage to indicate the selection from the rather large =
UniversalString
>set of character encodings. x.500 permits the use of BMPString in a
>distinguished name. therefore, the standard permits this characterset =
in a
>certificate, subject to profiles of course
>although 646 provides greater interoperability, one should consider =
national language=20
>and localization requirements for your product. the BMP set (Unicode) =
from 10646=20
>is the best character set to address such requirements.
>the tag value for UniversalString is 28; BMPString is 30. The asn.1 =
standard does=20
>not recommend the use of UniversalString without constraints.
>you can order and retrieve itu recommendations electronically. see =
http:// www.itu.ch/POD/itut-123.html.=20
>this can help you get the asn.1 documents. iso does not offer such a =
service; however,=20
>i suspect that you would want a paper copy of 10646 since display of =
the glyphs=20
>from an electronic text would be a challenge for the font capability of =
most systems.
>hoyt
>________________________________________________________________________=
_______
>Subject:	Questions about character sets and their encodings
>From:	Borka Jerman-Blazic <[email-masked]> at az05-smtp
>Date:	1/20/97  11:32
>
>
>
>>I've been searching for resources on the web on character sets for
>>ASN.1 types, but haven't been able to find what I need.  Does anybody
>>know of such resources?
>
>>More specifically, my questions are:
>
>>        IA5String: I've heard this is just 7-bit ASCII, but is that
>>true?
>
>
>Yes, IA5String is the same as 7-bit ASCII or ISO IRV 646 with one =
exception (the=20
>old one) instead of dollar sign it could be currency sign.
>>        TeletexString: I understand that one can select different
>>character sets with escape codes; does anybody have the set of escape
>>codes and character sets they select?
>
>
>TeleString is mainly T.61 or T.50 (one of them is currently used in =
Teletex) or=20
>its international ISO version ISO 6937.  This is 8-bit coding with =
changable use=20
>of a code lenght per character e.g. the accented letter of Latin =
alphabet are coded=20
>with 2 bytes, one for the so called "non-spacing" character (the acent =
or diacritic=20
>sign) and the other for the basic letter.
>>        UniversalString: X.690 says that this is encoded in 4-octet
>>canonical form, which I would imagine is 4 bytes, big-endian.  Also, I
>>believe that the subset of the 32-bit space with the high 16 bits set
>>to 0 is equivalent to Unicode.  Am I correct in these assumptions?
>>X.690 says a bunch of things that I don't really understand (probably
>>because I don't have X.680) about character string types and their
>>encodings.  Also, what is the tag for UniversalString?  Does anybody
>>have examples of certificates with UniversalString values in the
>>Issuer or Subject?  I've heard that Microsoft certificates do, but
>>when I queried Verisign for Microsoft certificates they didn't.  I
>>couldn't get ahold of any Microsoft products that actually issue
>>certificates to check that possibility.
>
>UniversalString allows all methods of coding e.g. with the ISO 2022 =
standard which=20
>is basic standard for code extension techniques in 7-bit and 8-bit =
environment you=20
>can use any of the registred code tables in the International Register =
of Coded=20
>Character sets. The invocation is done with shift functions and there =
are 4 of them:=20
>Single shift and locked single shift for one characater from the code =
table and=20
>2 others for invocation of the whole coded charcater set table. Every =
code table=20
>has his registered escape sequence for invocation, thus ISO 10 646 =
which first Multilingual=20
>plane is equal to Unicode has its one escape sequence and thus can be =
invoced in=20
>the UniversalString.
>The other way of use of different coded character sets  in =
UniversalString is with=20
>an  announcement mechanisms which are specified in ASN.1 or ISO 8825 =
and ISO 8824=20
>standard. Every used coded charcater set has his OID.=20
>
>>I know I could probably get the answers by ordering ISO/IEC 10646-1
>>and X.680, but from what I can see I'd have to do it snail mail.  I'd
>>rather not.
>
>My recommendation is to use ISO 10 646 as this is the only remedy for =
the mess in=20
>the charcater set world.
>
>I am very interested in the solutions used by Microsoft. The new =
version of the=20
>X.500 standard allows used of "context" for different attributes which =
means specification=20
>of the used coded charcater set.  Without proper spelling of people =
names and addresses=20
>there will be no value of the certificates as the names will differ =
from the names=20
>on the documents e.g. on the credit cards.
>
>Regards,
>
>
>Borka Jerman-blazic
>Chair, [email-masked]
>
>TERENA is European Association of the Research and Academic Networks
>
>
>
>
>
=00

Date: Tue, 21 Jan 1997 09:44:30 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Interpretation of KeyUsage?

> From: Lars Johansson <[email-masked]>
> 
> Housley, Russ wrote:
> > 
> > My opinion:
> > 
> > 1. Authentication is a 'digitalSignature' key.
> > 
> > 2. Computing digital signatures (e.g. signing legal contracts) is both a
> > 'digitalSignature' and a 'nonRepudiation' key.
> 
> This would be in line with the recommedation I received from Dennis
> Pinkas.  However, I still find it somewhat troublesome. Suppose I want
> to take part in an authentication protocol with somebody with two keys
> as described above.  Then which key do I pick? Many service providers
> may decide that a key with nonRepudiation "looks better" since then
> (they believe that) the other part can't repudiate the authentication
> protocol.
> 
> The point is that authentication and non-repudiation keys may never be
> mixed.  This could work with your suggestion as well as long as we're
> very clear what we mean with these key usages. Perhaps this definition
> would work:
> 
> 1. Authentication is a key with keyUsage 'digitalSignature' set and
>    'nonRepudiation' not set.
> 
> 2. Computing digital signatures (e.g. signing legal contracts) is a key
>    with both keyUsage 'digitalSignature' and 'nonRepudiation' set.
> 
> Notice that this definition doesn't differ from yours but it may be
> clearer.

Amendment 1 to ISO 9594-8:1995(E) includes the following text under
12.2.2.3 Key Usage field:

 "Bits in the KeyUsage type are as follows:

   a) digitalSignature: for verifying digital signatures that have purposes
      other than those identified in b), f), or g) below;

   b) nonRepudiation: for verifying digital signatures used in providing
      a nonrepudiation service which protects against the signing entity
      falsely denying some action (excluding certificate or CRL signing,
      as in f) or g) below);

    ...

   f) keyCertSign: ...
   g) cRLSign: ..."

My interpretation of this text is that a key which may be used only for
authentication would have 'digitalSignature' set and 'nonRepudiation'
not set (as everyone agrees, above).  But a key which is to be used
only for signing contracts (and not for authentication) would have
'nonRepudiation' set and 'digitalSignature' *not* set.

A single key which may used for both purposes would, of course,
have both bits set.  Lars' definition would disallow the issuance of
a single key that could be used for both purposes, so I prefer the
current DAM definition as it stands.

      dpk

To: Mark Bartel <[email-masked]>
Cc: [email-masked] (Borka Jerman-Blazic), [email-masked], [email-masked], [email-masked]
Subject: Re: Questions about character sets and their encodings 
Date: Tue, 21 Jan 1997 08:11:32 +0100
From: Borka Jerman-Blazic <[email-masked]>

Mark,

You are right, I did a mistake taking UniversalString for GeneralString
(which allows all 2022 coding and announcements).

Obviously UniversalString is rserved for BMP of ISO 10 646, canonical form
- 4 bytes per charcater. What is not clear here is the 4 bytes, which are
used when you specify the group, the plane and the row and cell
of every charcater. If it is just BMP ISO 10 646 1.1 then you do not need
the first two bytes. Using them just take more space and bandwith.
It will be intersting to see who else has done the same implementation
as you. However. it is true that very soon we will have another plane
which will code all ideographic scripts. That was solution recently
endorsed by WG 2 of ISO JTC1 SC2.

Regards,

Borka

> Borka, 
> 
> It sounds to me like you are refering (in the quoted text at the end
> of this message) to the unrestricted string type, rather than the
> UniversalString type.  X.690 describes a rather complicated structure
> (in 8.21.6) for that type that includes the object identifiers and
> such.  But X.690 says:
> 
>  8.20.5 For restricted character string apart from UniversalString and
>  BMPString the octet string shall contain the octets specified in ISO
>  2022 for encodings in an 8-bit environment, using the escape sequence
>  and character codings registered in accordance with ISO 2375.
> 
> This would seem to imply that UniversalString and BMPString don't use
> escape sequences, since escape sequences aren't mentioned anywhere
> else in reference to UniversalString.  Which would make sense, because
> it seems to me that the whole point of UniversalString is to be a
> "flat" character set, where you don't have to worry about escape
> sequences and modes.  This seems to be confirmed by the fact that
> UniversalString doesn't appear in "Table 3 - Use of escape sequences",
> and also by
> 
>  8.20.7 For the "UniversalString" type, the octet string shall contain
>  the octets specified in ISO/IEC 10646-1, using the 4-octet canonical
>  form (see 14.2 of ISO/IEC 10646-1).  Control functions and signatures
>  shall not be used.
> 
> Since all values in the character set can be reproduced in 4 octets,
> there is no reason for escape codes.
> 
> I think my current encoding is correct (nobody said my example was
> wrong) but I'd like to see other examples of UniversalString encodings
> (not necessarily even in certificates!), both because I'm paranoid :)
> and because nobody has indicated that they believe my encoding to be
> correct.  Knowing this list, I wouldn't be surprised if it was just
> that the few people who actually know (at this point in time it's kind
> of an obscure issue) just were too busy to respond.  But up until now,
> I haven't been able to find a single example of a UniversalString DER
> or BER encoding, in or out of a certificate.  Arrrggghhh!  Isn't
> *anybody* using UniversalString?  Is anybody reading this thread?
> 
> - Mark Bartel
> 

Date: Mon, 20 Jan 1997 15:18:11 -0700
From: [email-masked] (KESTERSON.H)
Subject: Re: Questions about character sets and their encodings
To: Borka Jerman-Blazic <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Content-Description: cc:Mail note part

asn1. also defines the type BMPString which is the Basic Multilingual Plane
character set. This is the set of 16 bit character encodings that is
"supposedly" equivalent to the unicode set (the intent was to make unicode and
BMP identical - i believe they succeeded but i never verified it by checking the
final version of the standard). the advantage of this asn.1 type is that it uses
the asn.1 tage to indicate the selection from the rather large UniversalString
set of character encodings. x.500 permits the use of BMPString in a
distinguished name. therefore, the standard permits this characterset in a
certificate, subject to profiles of course

although 646 provides greater interoperability, one should consider national
language and localization requirements for your product. the BMP set (Unicode)
from 10646 is the best character set to address such requirements.

the tag value for UniversalString is 28; BMPString is 30. The asn.1 standard
does not recommend the use of UniversalString without constraints.

you can order and retrieve itu recommendations electronically. see http://
www.itu.ch/POD/itut-123.html. this can help you get the asn.1 documents. iso
does not offer such a service; however, i suspect that you would want a paper
copy of 10646 since display of the glyphs from an electronic text would be a
challenge for the font capability of most systems.

   hoyt
_______________________________________________________________________________
Subject: Questions about character sets and their encodings
From:    Borka Jerman-Blazic <[email-masked]> at az05-smtp
Date:    1/20/97  11:32

>I've been searching for resources on the web on character sets for
>ASN.1 types, but haven't been able to find what I need.  Does anybody
>know of such resources?

>More specifically, my questions are:

>        IA5String: I've heard this is just 7-bit ASCII, but is that
>true?

Yes, IA5String is the same as 7-bit ASCII or ISO IRV 646 with one
exception (the old one) instead of dollar sign it could be
currency sign.
 
>        TeletexString: I understand that one can select different
>character sets with escape codes; does anybody have the set of escape
>codes and character sets they select?

TeleString is mainly T.61 or T.50 (one of them is currently
used in Teletex) or its international ISO version ISO 6937.
This is 8-bit coding with changable use of a code lenght per
character e.g. the accented letter of Latin alphabet are coded
with 2 bytes, one for the so called "non-spacing" character (the
acent or diacritic sign) and the other for the basic letter.

>        UniversalString: X.690 says that this is encoded in 4-octet
>canonical form, which I would imagine is 4 bytes, big-endian.  Also, I
>believe that the subset of the 32-bit space with the high 16 bits set
>to 0 is equivalent to Unicode.  Am I correct in these assumptions?
>X.690 says a bunch of things that I don't really understand (probably
>because I don't have X.680) about character string types and their
>encodings.  Also, what is the tag for UniversalString?  Does anybody
>have examples of certificates with UniversalString values in the
>Issuer or Subject?  I've heard that Microsoft certificates do, but
>when I queried Verisign for Microsoft certificates they didn't.  I
>couldn't get ahold of any Microsoft products that actually issue
>certificates to check that possibility.

UniversalString allows all methods of coding e.g. with the ISO 2022
standard which is basic standard for code extension techniques in
7-bit and 8-bit environment you can use any of the registred code tables
in the International Register of Coded Character sets. The invocation
is done with shift functions and there are 4 of them: Single shift and
locked single shift for one characater from the code table and
2 others for invocation of the whole coded charcater set table. Every code
table has his registered escape sequence for invocation, thus ISO
10 646 which first Multilingual plane is equal to Unicode has its
one escape sequence and thus can be invoced in the UniversalString.

The other way of use
of different coded character sets  in UniversalString is 
with an  announcement mechanisms which
are specified in ASN.1 or ISO 8825 and ISO 8824 standard. Every used
coded charcater set has his OID. 

>I know I could probably get the answers by ordering ISO/IEC 10646-1
>and X.680, but from what I can see I'd have to do it snail mail.  I'd
>rather not.

My recommendation is to use ISO 10 646 as this is the only remedy for the
mess in the charcater set world.

I am very interested in the solutions used by Microsoft. The
new version of the X.500 standard allows used of "context" for different
attributes which means specification of the used coded charcater set.
Without proper spelling of people names and addresses there will be no
value of the certificates as the names will differ from the
names on the documents e.g. on the credit cards.

Regards,

Borka Jerman-blazic
Chair, [email-masked]

TERENA is European Association of the Research and Academic Networks

From: Mark Bartel <[email-masked]>
Subject: Re: Questions about character sets and their encodings
To: [email-masked] (Borka Jerman-Blazic)
Date: Mon, 20 Jan 1997 17:04:45 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked]

Borka, 

It sounds to me like you are refering (in the quoted text at the end
of this message) to the unrestricted string type, rather than the
UniversalString type.  X.690 describes a rather complicated structure
(in 8.21.6) for that type that includes the object identifiers and
such.  But X.690 says:

 8.20.5 For restricted character string apart from UniversalString and
 BMPString the octet string shall contain the octets specified in ISO
 2022 for encodings in an 8-bit environment, using the escape sequence
 and character codings registered in accordance with ISO 2375.

This would seem to imply that UniversalString and BMPString don't use
escape sequences, since escape sequences aren't mentioned anywhere
else in reference to UniversalString.  Which would make sense, because
it seems to me that the whole point of UniversalString is to be a
"flat" character set, where you don't have to worry about escape
sequences and modes.  This seems to be confirmed by the fact that
UniversalString doesn't appear in "Table 3 - Use of escape sequences",
and also by

 8.20.7 For the "UniversalString" type, the octet string shall contain
 the octets specified in ISO/IEC 10646-1, using the 4-octet canonical
 form (see 14.2 of ISO/IEC 10646-1).  Control functions and signatures
 shall not be used.

Since all values in the character set can be reproduced in 4 octets,
there is no reason for escape codes.

I think my current encoding is correct (nobody said my example was
wrong) but I'd like to see other examples of UniversalString encodings
(not necessarily even in certificates!), both because I'm paranoid :)
and because nobody has indicated that they believe my encoding to be
correct.  Knowing this list, I wouldn't be surprised if it was just
that the few people who actually know (at this point in time it's kind
of an obscure issue) just were too busy to respond.  But up until now,
I haven't been able to find a single example of a UniversalString DER
or BER encoding, in or out of a certificate.  Arrrggghhh!  Isn't
*anybody* using UniversalString?  Is anybody reading this thread?

- Mark Bartel

> >        UniversalString: X.690 says that this is encoded in 4-octet
> >canonical form, which I would imagine is 4 bytes, big-endian.  Also, I
> >believe that the subset of the 32-bit space with the high 16 bits set
> >to 0 is equivalent to Unicode.  Am I correct in these assumptions?
> >X.690 says a bunch of things that I don't really understand (probably
> >because I don't have X.680) about character string types and their
> >encodings.  Also, what is the tag for UniversalString?  Does anybody
> >have examples of certificates with UniversalString values in the
> >Issuer or Subject?  I've heard that Microsoft certificates do, but
> >when I queried Verisign for Microsoft certificates they didn't.  I
> >couldn't get ahold of any Microsoft products that actually issue
> >certificates to check that possibility.
> 
> UniversalString allows all methods of coding e.g. with the ISO 2022
> standard which is basic standard for code extension techniques in
> 7-bit and 8-bit environment you can use any of the registred code tables
> in the International Register of Coded Character sets. The invocation
> is done with shift functions and there are 4 of them: Single shift and
> locked single shift for one characater from the code table and
> 2 others for invocation of the whole coded charcater set table. Every code
> table has his registered escape sequence for invocation, thus ISO
> 10 646 which first Multilingual plane is equal to Unicode has its
> one escape sequence and thus can be invoced in the UniversalString.
> 
> The other way of use
> of different coded character sets  in UniversalString is 
> with an  announcement mechanisms which
> are specified in ASN.1 or ISO 8825 and ISO 8824 standard. Every used
> coded charcater set has his OID. 
> 
> 
> >I know I could probably get the answers by ordering ISO/IEC 10646-1
> >and X.680, but from what I can see I'd have to do it snail mail.  I'd
> >rather not.
> 
> My recommendation is to use ISO 10 646 as this is the only remedy for the
> mess in the charcater set world.
> 
> 
> I am very interested in the solutions used by Microsoft. The
> new version of the X.500 standard allows used of "context" for different
> attributes which means specification of the used coded charcater set.
> Without proper spelling of people names and addresses there will be no
> value of the certificates as the names will differ from the
> names on the documents e.g. on the credit cards.
> 
> 
> Regards,
> 
> 
> Borka Jerman-blazic
> Chair, [email-masked]
> 
> TERENA is European Association of the Research and Academic Networks
> 
> 
> 
> 
> 

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Questions about character sets and their encodings
Date: Mon, 20 Jan 1997 11:32:15 +0100
From: Borka Jerman-Blazic <[email-masked]>

>I've been searching for resources on the web on character sets for
>ASN.1 types, but haven't been able to find what I need.  Does anybody
>know of such resources?

>More specifically, my questions are:

>        IA5String: I've heard this is just 7-bit ASCII, but is that
>true?

Yes, IA5String is the same as 7-bit ASCII or ISO IRV 646 with one
exception (the old one) instead of dollar sign it could be
currency sign.
 
>        TeletexString: I understand that one can select different
>character sets with escape codes; does anybody have the set of escape
>codes and character sets they select?

TeleString is mainly T.61 or T.50 (one of them is currently
used in Teletex) or its international ISO version ISO 6937.
This is 8-bit coding with changable use of a code lenght per
character e.g. the accented letter of Latin alphabet are coded
with 2 bytes, one for the so called "non-spacing" character (the
acent or diacritic sign) and the other for the basic letter.

>        UniversalString: X.690 says that this is encoded in 4-octet
>canonical form, which I would imagine is 4 bytes, big-endian.  Also, I
>believe that the subset of the 32-bit space with the high 16 bits set
>to 0 is equivalent to Unicode.  Am I correct in these assumptions?
>X.690 says a bunch of things that I don't really understand (probably
>because I don't have X.680) about character string types and their
>encodings.  Also, what is the tag for UniversalString?  Does anybody
>have examples of certificates with UniversalString values in the
>Issuer or Subject?  I've heard that Microsoft certificates do, but
>when I queried Verisign for Microsoft certificates they didn't.  I
>couldn't get ahold of any Microsoft products that actually issue
>certificates to check that possibility.

UniversalString allows all methods of coding e.g. with the ISO 2022
standard which is basic standard for code extension techniques in
7-bit and 8-bit environment you can use any of the registred code tables
in the International Register of Coded Character sets. The invocation
is done with shift functions and there are 4 of them: Single shift and
locked single shift for one characater from the code table and
2 others for invocation of the whole coded charcater set table. Every code
table has his registered escape sequence for invocation, thus ISO
10 646 which first Multilingual plane is equal to Unicode has its
one escape sequence and thus can be invoced in the UniversalString.

The other way of use
of different coded character sets  in UniversalString is 
with an  announcement mechanisms which
are specified in ASN.1 or ISO 8825 and ISO 8824 standard. Every used
coded charcater set has his OID. 

>I know I could probably get the answers by ordering ISO/IEC 10646-1
>and X.680, but from what I can see I'd have to do it snail mail.  I'd
>rather not.

My recommendation is to use ISO 10 646 as this is the only remedy for the
mess in the charcater set world.

I am very interested in the solutions used by Microsoft. The
new version of the X.500 standard allows used of "context" for different
attributes which means specification of the used coded charcater set.
Without proper spelling of people names and addresses there will be no
value of the certificates as the names will differ from the
names on the documents e.g. on the credit cards.

Regards,

Borka Jerman-blazic
Chair, [email-masked]

TERENA is European Association of the Research and Academic Networks

Date: Mon, 20 Jan 1997 10:24:34 +0100
From: Lars Johansson <[email-masked]>
Organization: PSab
To: "Housley, Russ" <[email-masked]>
Cc: [email-masked]
Subject: Re: Interpretation of KeyUsage?

Housley, Russ wrote:
> 
> My opinion:
> 
> 1. Authentication is a 'digitalSignature' key.
> 
> 2. Computing digital signatures (e.g. signing legal contracts) is both a
> 'digitalSignature' and a 'nonRepudiation' key.

This would be in line with the recommedation I received from Dennis
Pinkas.
However, I still find it somewhat troublesome. Suppose I want to take
part
in an authentication protocol with somebody with two keys as described
above.
Then which key do I pick? Many service providers may decide that a key
with
nonRepudiation "looks better" since then (they believe that) the other
part 
can't repudiate the authentication protocol.

The point is that authentication and non-repudiation keys may never be
mixed.
This could work with your suggestion as well as long as we're very clear
what
we mean with these key usages. Perhaps this definition would work:

1. Authentication is a key with keyUsage 'digitalSignature' set and
'nonRepudiation' 
   not set.

2. Computing digital signatures (e.g. signing legal contracts) is a key
with both
   keyUsage 'digitalSignature' and 'nonRepudiation' set.

Notice that this definition doesn't differ from yours but it may be
clearer.
 
> 3. Encryption is a 'keyEncipherment' or 'keyAgreement' key depending on the
> algorithm you use.  RSA is a 'keyEncipherment' key.  Diffie-Hellman is a
> 'keyAgreement' key.

We use RSA and have decided to set the key usage to 'keyEncipherment'.

However, due to backward compatibility reasons, the SEIS specification
also
includes the key usage 'keyAgreement'. The meaning of that alludes to a
protocol
(DASP) defined in the swedish "Allterminal"-project using key-exchange
based on RSA.

Unfortunately the authentication key is used in this protocol. This is
not a good
solution but it was a compromise in order to be backward compatible with
the 
"Allterminal" standard. Nevertheless, it's a lot harder to break this
scheme than
ordinary encryption because, in order to do so, you must attack both the 
communicating parties.

Thanks for your patience and helpful comments!
/Lars Johansson
 
> ______________________________ Reply Separator _________________________________
> Subject: Interpretation of KeyUsage?
> Author:  Lars Johansson <[email-masked]> at internet
> Date:    1/17/97 3:06 AM
> 
> Hi all,
> 
> This is a topic that has confused us a great deal
> in the swedish SEIS project (http://www.seis.se).
> One goal of SEIS is to agree on a standard of
> electronic ID-cards (i.e. smart cards primarly
> used for identification). The electronic ID-card
> shall be capable of performing the following
> cryptographic functions (all based on RSA):
> 
> 1. Authentication ("signing" a random challenge).
> 
> 2. Computing digital signatures (e.g. signing
>    legal contracts).
> 
> 3. Encryption
> 
> For each function there is a separate key with a
> corresponding certificate. These three certificates
> must therefore include the X.509v3 extension keyUsage.
> 
> It's quite clear that the encryption key can have the
> usage 'keyEncipherment' but what about the other two?
> 
> After reading the X.509 DAM over and over (and even
> calling Warwick Ford) it was decided that the key we
> use for (what we call) digital signatures (function no. 2)
> would be 'nonRepudiation' in the X.509 terminology.
> 
> This left us with the KeyUsage 'digitalSignatures'
> for the key we use for authentication. Although I think
> this interpretation of X.509v3 is correct it still
> worries me somehow. As we interpret the term authentication,
> it means encrypting some random data with your private key.
> Since the protocol uses random data, this type of signature
> mustn't be mixed with the ones performed on legally binding
> contracts (supporting non-repudiation).
> 
> Now I'd like to know for what other purposes are people
> using keys with the X.509v3 extension 'digitalSignature'?
> As I see it there is a potential risk that the intepretation
> differs from country to country or even from application to
> application.
> 
> Suppose that one service provider on the Internet accepts
> a digitally signed payment order using the extension
> 'digitalSignature' in the corresponding certificate.
> Do you all see the potential risk of fraud to our happily
> unworried swedish inhabitants that use their electronic
> ID-cards for authetication puposes?
> 
> Please comment!
> /Lars Johansson
> Sweden Post

Date: Fri, 17 Jan 97 10:17:25 
From: "Housley, Russ" <[email-masked]>
Encoding: 2679 Text
To: [email-masked], Lars Johansson <[email-masked]>
Subject: Re: Interpretation of KeyUsage?

My opinion:

1. Authentication is a 'digitalSignature' key.

2. Computing digital signatures (e.g. signing legal contracts) is both a 
'digitalSignature' and a 'nonRepudiation' key.

3. Encryption is a 'keyEncipherment' or 'keyAgreement' key depending on the 
algorithm you use.  RSA is a 'keyEncipherment' key.  Diffie-Hellman is a 
'keyAgreement' key.

Russ

______________________________ Reply Separator _________________________________
Subject: Interpretation of KeyUsage?
Author:  Lars Johansson <[email-masked]> at internet
Date:    1/17/97 3:06 AM

Hi all,

This is a topic that has confused us a great deal 
in the swedish SEIS project (http://www.seis.se). 
One goal of SEIS is to agree on a standard of 
electronic ID-cards (i.e. smart cards primarly 
used for identification). The electronic ID-card 
shall be capable of performing the following 
cryptographic functions (all based on RSA):

1. Authentication ("signing" a random challenge).

2. Computing digital signatures (e.g. signing 
   legal contracts).

3. Encryption

For each function there is a separate key with a 
corresponding certificate. These three certificates 
must therefore include the X.509v3 extension keyUsage.

It's quite clear that the encryption key can have the 
usage 'keyEncipherment' but what about the other two?

After reading the X.509 DAM over and over (and even 
calling Warwick Ford) it was decided that the key we
use for (what we call) digital signatures (function no. 2) 
would be 'nonRepudiation' in the X.509 terminology.

This left us with the KeyUsage 'digitalSignatures'
for the key we use for authentication. Although I think 
this interpretation of X.509v3 is correct it still
worries me somehow. As we interpret the term authentication, 
it means encrypting some random data with your private key. 
Since the protocol uses random data, this type of signature 
mustn't be mixed with the ones performed on legally binding 
contracts (supporting non-repudiation).

Now I'd like to know for what other purposes are people 
using keys with the X.509v3 extension 'digitalSignature'?
As I see it there is a potential risk that the intepretation 
differs from country to country or even from application to 
application.

Suppose that one service provider on the Internet accepts 
a digitally signed payment order using the extension 
'digitalSignature' in the corresponding certificate.
Do you all see the potential risk of fraud to our happily 
unworried swedish inhabitants that use their electronic 
ID-cards for authetication puposes?

Please comment!
/Lars Johansson
Sweden Post

Date: Fri, 17 Jan 1997 16:29:13 +0100
From: Lars Johansson <[email-masked]>
Organization: PSab
To: [email-masked]
Cc: [email-masked]
Subject: Re: Interpretation of KeyUsage?

Denis Pinkas wrote:
> 
> Lars Johansson wrote:
> >
> > After reading the X.509 DAM over and over (and even
> > calling Warwick Ford) it was decided that the key we
> > use for (what we call) digital signatures (function no. 2)
> > would be 'nonRepudiation' in the X.509 terminology.
> 
> No. This would be wrong. Non repudiation, as you point out later on, is
> legally binding people.  A digital signature is just a mechanism that
> can be used for providing (and I am using there the ISO 7498-2
> terminology) data origin authentication with integrity, or entity
> authentication. When used in conjonction with other information, like a
> counter-signature from a Time Stamping Authority, a digital signature
> can also provide non repudiation.

Non repudiation of origin can also be achieved when the key is securely
stored in a smart card and can only be accessed after a correct
presentation
of the PIN code. This is how our 'nonRepudiation'-key is used.
 
> The difference is introduced between "digital signature" and "non
> repudiation" so that if you use a key with a key usage "digital
> signature" then it is not intended to legally bind you. The key is
> restricted to authentication purposes (in the large sense). In other
> words, the digital signature may convince some one; but cannot be used,
> according to a security policy, to convince anyone.
> 
> On the contrary the a key marked as non-repudiation is intended to bind
> you, once again, according to a security policy.

This is interesting since it is almost exactly the interpretation of
keyUsage
that we agreed upon. Hopefully everyone has the same interpration(?). 

This would also mean that e.g. a time-stamping service would use a key
with
nonRepudiation and let the policy indicate that it may only be used to
legally sign time-stamps, not any contents of the time-stamped
documents.
 
> > Suppose that one service provider on the Internet accepts
> > a digitally signed payment order using the extension
> > 'digitalSignature' in the corresponding certificate.
> 
> The Internet service provider can do it, in order to be convinced
> itself, but it would not be able to use the received digital signature
> to convince a third party, like a judge.

...which is the reason why signatures should be used in the first place,
isn't it? No, I get the point. Thanks for clearifying it to me.
 
> I take this opportunity to present my best wishes for the new year to
> the happily unworried swedish inhabitants that will use electronic
> ID-cards for authentication purposes.  :-)

Thanks, I'll pass your greeting to them. ;-)

Kind regards,
/Lars Johansson

Date: Fri, 17 Jan 1997 15:55:19 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Lars Johansson <[email-masked]>
Cc: [email-masked]
Subject: Re: Interpretation of KeyUsage?

Lars Johansson wrote:
> 
> Hi all,
> 
> This is a topic that has confused us a great deal
> in the swedish SEIS project (http://www.seis.se).
> One goal of SEIS is to agree on a standard of
> electronic ID-cards (i.e. smart cards primarly
> used for identification). The electronic ID-card
> shall be capable of performing the following
> cryptographic functions (all based on RSA):
> 
> 1. Authentication ("signing" a random challenge).
> 
> 2. Computing digital signatures (e.g. signing
>    legal contracts).
> 
> 3. Encryption
> 
> For each function there is a separate key with a
> corresponding certificate. These three certificates
> must therefore include the X.509v3 extension keyUsage.
> 
> It's quite clear that the encryption key can have the
> usage 'keyEncipherment' but what about the other two?
> 
> After reading the X.509 DAM over and over (and even
> calling Warwick Ford) it was decided that the key we
> use for (what we call) digital signatures (function no. 2)
> would be 'nonRepudiation' in the X.509 terminology.

No. This would be wrong. Non repudiation, as you point out later on, is
legally binding people.  A digital signature is just a mechanism that
can be used for providing (and I am using there the ISO 7498-2
terminology) data origin authentication with integrity, or entity
authentication. When used in conjonction with other information, like a
counter-signature from a Time Stamping Authority, a digital signature
can also provide non repudiation.

The difference is introduced between "digital signature" and "non
repudiation" so that if you use a key with a key usage "digital
signature" then it is not intended to legally bind you. The key is
restricted to authentication purposes (in the large sense). In other
words, the digital signature may convince some one; but cannot be used,
according to a security policy, to convince anyone.

On the contrary the a key marked as non-repudiation is intended to bind
you, once again, according to a security policy.

> This left us with the KeyUsage 'digitalSignatures'
> for the key we use for authentication. Although I think
> this interpretation of X.509v3 is correct it still
> worries me somehow. As we interpret the term authentication,
> it means encrypting some random data with your private key.
> Since the protocol uses random data, this type of signature
> mustn't be mixed with the ones performed on legally binding
> contracts (supporting non-repudiation).
> 
> Now I'd like to know for what other purposes are people
> using keys with the X.509v3 extension 'digitalSignature'?
> As I see it there is a potential risk that the intepretation
> differs from country to country or even from application to
> application.

> Suppose that one service provider on the Internet accepts
> a digitally signed payment order using the extension
> 'digitalSignature' in the corresponding certificate.

The Internet service provider can do it, in order to be convinced
itself, but it would not be able to use the received digital signature
to convince a third party, like a judge.

> Do you all see the potential risk of fraud to our happily
> unworried swedish inhabitants that use their electronic
> ID-cards for authentication purposes?
> 
> Please comment!
> /Lars Johansson
> Sweden Post

I take this opportunity to present my best wishes for the new year to
the happily unworried swedish inhabitants that will use electronic
ID-cards for authentication purposes.  :-)

Regards,

Denis

-- 

      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Fri, 17 Jan 1997 10:56:33 +0100
From: Lars Johansson <[email-masked]>
Organization: PSab
To: [email-masked]
Subject: Interpretation of KeyUsage?

Hi all,

This is a topic that has confused us a great deal 
in the swedish SEIS project (http://www.seis.se).
One goal of SEIS is to agree on a standard of 
electronic ID-cards (i.e. smart cards primarly 
used for identification). The electronic ID-card
shall be capable of performing the following
cryptographic functions (all based on RSA):

1. Authentication ("signing" a random challenge).

2. Computing digital signatures (e.g. signing 
   legal contracts).

3. Encryption

For each function there is a separate key with a
corresponding certificate. These three certificates 
must therefore include the X.509v3 extension keyUsage.

It's quite clear that the encryption key can have the
usage 'keyEncipherment' but what about the other two?

After reading the X.509 DAM over and over (and even
calling Warwick Ford) it was decided that the key we
use for (what we call) digital signatures (function no. 2)
would be 'nonRepudiation' in the X.509 terminology.

This left us with the KeyUsage 'digitalSignatures'
for the key we use for authentication. Although I think
this interpretation of X.509v3 is correct it still
worries me somehow. As we interpret the term authentication,
it means encrypting some random data with your private key.
Since the protocol uses random data, this type of signature
mustn't be mixed with the ones performed on legally binding
contracts (supporting non-repudiation).

Now I'd like to know for what other purposes are people
using keys with the X.509v3 extension 'digitalSignature'?
As I see it there is a potential risk that the intepretation
differs from country to country or even from application to
application.

Suppose that one service provider on the Internet accepts
a digitally signed payment order using the extension 
'digitalSignature' in the corresponding certificate.
Do you all see the potential risk of fraud to our happily
unworried swedish inhabitants that use their electronic
ID-cards for authetication puposes?

Please comment!
/Lars Johansson
Sweden Post

From: Mark Bartel <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Sample certificate sites
Date: Thu, 16 Jan 1997 23:51:43 -0500

Well, I've gotten lots of pointers to various places to get sample =
certificates, and have run a lot of them through my code (successfully). =
 Unfortunately, I still couldn't find any with UniversalString values.  =
The closest I came was managing to get the demo at http://www.xcert.com =
to generate certificates containing TeletexString values; Verisign won't =
even do that.=20

And I've tried importing my certificates into MS Internet Explorer 3.01, =
and the UniversalString certificates do not work (MSIE can't display =
them).  Peter (Gutmann), you said (in your X.509 style guide) that =
Microsoft generates certificates with UniversalString values, so =
presumably MSIE will read such and I must assume that I've done =
something wrong.  I had figured that if Microsoft had a product that =
generated such certificates, it would be easy to find examples, but I've =
failed to dig any up.

>From X.690:
8.20.7 For the "UniversalString" type, the octet string shall contain =
the octets specified in ISO/IEC 10646-1, using the 4-octet canonical =
form (see 14.2 of ISO/IEC 10646-1).  Control functions and signatures =
shall not be used.

Does anybody know what this means?  Could someone quote the above =
section 14.2?  I've assumed that 4-octet canonical form means 4-bytes, =
big endian, per character, but that's just a guess.  I'm hoping that =
MSIE just doesn't work with UniversalString.

As an example, I'd encode "AB" as

	1C 08 00 00 00 41 00 00 00 42

 (I also tried running my UniversalString certificates through a few =
other programs; SSLeay identified the UniversalString values but didn't =
try to parse them, and Certificate Viewer couldn't read the certificate =
at all.  I couldn't figure out how to get Netscape to look at the =
certificates as such.)

- Mark Bartel

From: <[email-masked]>
To: [email-masked]
Subject: Re: Sample certificate sites
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 16 Jan 1997 23:59:19 (NZDT)

>I've looked at doing that as part of my X.509 style guide,
>http://www.cs.auckland.ac.nz/pgut001/x509guide.txt, 
 
This URL isn't quite right, something in this mailer is eating tildes and got 
the one before the 'p'.  The correct URL is 
http://www.cs.auckland.ac.nz/~pgut001/x509guide.txt (I hope it works this 
time).  Sorry about the confusion. 
 
Peter.

From: "Carl Binding"<[email-masked]>
To: [email-masked]
Date: Thu, 16 Jan 1997 08:35:53 +0200
Subject: Re: Sample certificate sites

  It certainly would be great to have a repository of "reference" X.509
  certificates....
  As an aside: does anybody know how to "read" the Netscape certificate
  "db" used by Navigator?
  There are few, albeit simple, test certificates right there.
  Any pointers into that direction would be appreciated.
  Carl Binding

From: <[email-masked]>
To: [email-masked]
Subject: Re: Sample certificate sites
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 16 Jan 1997 17:24:13 (NZDT)

>i think it would be a service to the profiling community if you (as a result
>of this activity) publish to anonymous accessors a set of certificates which
>are conformant to the PKIX-1 I-D, which explore some of the more interesting
>options within that option space, inclduing char sets, length maximums, policy
>values, std qualifiers, etc, etc.
 
I've looked at doing that as part of my X.509 style guide,
http://www.cs.auckland.ac.nz/pgut001/x509guide.txt, however all I've got is all 
of the more conventional certs (I've got one which mixes BER and DER, but 
that's about as far as it goes, so I never went any further than adding a list 
and saying "Can people send me any strange certs they find".  The response to 
date has been underwhelming).  If anyone has anything unusual, could you 
please send them to me and I'll include them in the guide.
 
Peter.

Date: Wed, 15 Jan 1997 16:21:14 -0800
To: Mark Bartel <[email-masked]>, [email-masked]
From: Peter Williams <[email-masked]>
Subject: Re: Sample certificate sites

i think it would be a service to the profiling community
if you (as a result of this activity) publish to
anonymous accessors a set of certificates which are
conformant to the PKIX-1 I-D, which explore
some of the more interesting options within
that option space, inclduing char sets, length maximums,
policy values, std qualifiers, etc, etc.

Look at it as good advertising for yourself, or your
product/service etc. We found lots of issues (and new business
partners) when providing a similar community service for the
SET-specified certficates.

Peter.

At 05:42 PM 1/15/97 -0500, Mark Bartel wrote:
>I've resolved my character set questions (ie. figured out
>UniversalString, decided to ignore TeletexString) and it all seems to
>work fine, but I'd like to have certificates created by someone else
>that contain UniversalStrings to test it on.  Just my general level of
>paranoia.
>
>I've tested previously by using certificates from Verisign, in
>addition to the samples that came with the various tools I use.  I'd
>like to test with certificates from other vendors (not necessarily
>containing UniversalString values).  Where are good sources of sample
>certificates?
>
>- Mark Bartel
>
>

From: Mark Bartel <[email-masked]>
Subject: Sample certificate sites
To: [email-masked]
Date: Wed, 15 Jan 1997 17:42:20 -0500 (EST)

I've resolved my character set questions (ie. figured out
UniversalString, decided to ignore TeletexString) and it all seems to
work fine, but I'd like to have certificates created by someone else
that contain UniversalStrings to test it on.  Just my general level of
paranoia.

I've tested previously by using certificates from Verisign, in
addition to the samples that came with the various tools I use.  I'd
like to test with certificates from other vendors (not necessarily
containing UniversalString values).  Where are good sources of sample
certificates?

- Mark Bartel

Date: Wed, 15 Jan 1997 17:26:19 +0100
From: Lars Johansson <[email-masked]>
Organization: PSab
To: [email-masked]
Subject: HMAC OID?

Hi all,

This question actually relates to the SET spec but 
perhaps someone on this list could answer it for me.

Is there an OID for HMAC? In particular HMAC with SHA-1?

In the previous version of the SET Specification (Book 2:
Programmers Guide) the PANSecret value were just hashed
with SHA-1 and the ASN.1 definition of the certificate 
included the id-sha OID from X9.30.

Now, in the latest version, the hash algorithm is instead 
keyed HMAC (with SHA-1 replacing MD5) but no OIDs are given 
and the exact coding of the hashvalue is not specified.

So, does somebody on this list know of an OID for HMAC with
SHA-1? Please let me then know too.

Thanks,
/Lars Johansson
Sweden Post

From: Mark Wahl <[email-masked]>
To: Mark Bartel <[email-masked]>
cc: [email-masked]
Subject: Re: Questions about character sets and their encodings
Date: Tue, 14 Jan 1997 12:05:13 -0600
Sender: [email-masked]

> IA5String: I've heard this is just 7-bit ASCII, but is that true?

Letters and number characters are the same as ASCII.  Instead of a dollar sign,
IA5String may have a "currency symbol".  

>        TeletexString: I understand that one can select different
> character sets with escape codes; does anybody have the set of escape
> codes and character sets they select?

The character sets are Japanese Kanji (JIS C 6226-1983, set No. 87), Chinese 
(GB 2312-80, set No. 58), and Greek.   There are character set shifting codes 
in ITU-T Rec. T.61(88).  IMHO it would probably be much easier to use 
UniversalString and BMPString than T.61 for non-Western-European character 
sets.

> encodings.  Also, what is the tag for UniversalString?  

I think UniversalString is UNIVERSAL 28 and BMPString is UNIVERSAL 30.  
BMPString is a two-byte encoding of the UniversalString characters in the 0/0
plane.

Mark Wahl, Enterprise Directory Integration
Critical Angle Inc.

From: Mark Bartel <[email-masked]>
Subject: Questions about character sets and their encodings
To: [email-masked]
Date: Tue, 14 Jan 1997 11:56:44 -0500 (EST)

I've been searching for resources on the web on character sets for
ASN.1 types, but haven't been able to find what I need.  Does anybody
know of such resources?

More specifically, my questions are:

        IA5String: I've heard this is just 7-bit ASCII, but is that
true?

        TeletexString: I understand that one can select different
character sets with escape codes; does anybody have the set of escape
codes and character sets they select?

        UniversalString: X.690 says that this is encoded in 4-octet
canonical form, which I would imagine is 4 bytes, big-endian.  Also, I
believe that the subset of the 32-bit space with the high 16 bits set
to 0 is equivalent to Unicode.  Am I correct in these assumptions?
X.690 says a bunch of things that I don't really understand (probably
because I don't have X.680) about character string types and their
encodings.  Also, what is the tag for UniversalString?  Does anybody
have examples of certificates with UniversalString values in the
Issuer or Subject?  I've heard that Microsoft certificates do, but
when I queried Verisign for Microsoft certificates they didn't.  I
couldn't get ahold of any Microsoft products that actually issue
certificates to check that possibility.

I know I could probably get the answers by ordering ISO/IEC 10646-1
and X.680, but from what I can see I'd have to do it snail mail.  I'd
rather not.

- Mark Bartel

Date: Tue, 14 Jan 1997 15:44:46 +0100
From: "Sheedy, E.C.C." <[email-masked]>
Subject: subscribe
To: "[email-masked]'" <[email-masked]>

Kamer    :  B40
Telefoon : (050-58)22816
Fax      :      050-3122415
Email    :    [email-masked]

Date: Mon, 13 Jan 1997 17:03:33 +0100
From: "Adriano Santoni" <[email-masked]>
To: [email-masked]
Subject: About restrictions on length of certificate fields

--part_AF001B650008546500000002
Content-Type: Text/Plain; charset=US-ASCII
Content-Disposition: Inline

Hello PKIXers!

Is anybody willing to explain whether is there any sort of restrictions, 
imposed either by consequences of standards or by practice or common sense, on 
the length of seemingly unlimited-length X.509 fields like subject, or 
subjectAltName, etc. ???

Many thanks to any volunteer,

Adriano Santoni

--part_AF001B650008546500000002
Content-Type: Text/Plain; charset=US-ASCII
Content-Disposition: Inline

Ing. Adriano Santoni <[email-masked]>
Ufficio Progetti WAN c/o Direzione Rete
SIA - Societa' Interbancaria per l'Automazione S.p.A.
Viale Certosa 218, 20156 Milano, ITALIA
vox: +39(2)3005.277
fax: +39(2)38003333
cell: 0338-8495592

--part_AF001B650008546500000002--

Date: Mon, 13 Jan 1997 18:49:39 +0900
From: Taketoshi Sakuraba <[email-masked]>
Reply-To: [email-masked]
Organization: Hitachi, Ltd.
To: [email-masked]
Subject: subscribe

subscribe [email-masked] ietf-pkix

Date: Fri, 10 Jan 1997 18:50:06 -0800 (PST)
From: "Patrick C. Richard" <[email-masked]>
To: Moti Frances <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: LDAP server with X509 certificates

On Thu, 9 Jan 1997, Moti Frances wrote:

> Hello All,
> 
> Does anybody know about LDAP servers that hold X509 certificates
> and are available for public usage ?
> 

Try https://www.xcert.com

> Thanx,
> Moti.
> 
> 
> ===========================================================================
> Moti Frances
> [email-masked]
> Tel: + 972 3 6131833 extension 149
> ---------------------------------------------------------------------------
> CheckPoint Software Technologies Ltd.
> 3A Jabotinsky St., Diamond Tower       | Tel: + 972 3 6131833
> Ramat-Gan 52511, ISRAEL                | Fax: + 972 3 5759256
> 
> http://www.checkpoint.com
> ============================================================================
> 

----
Pat Richard
[email-masked]

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: 2ND ANNOUNCEMENT: ISOC 97 SYMP NETWORK & DISTRIBUTED SYSTEM SECURITY
Date: Fri, 10 Jan 1997 19:01:26 -0500
From: "David M. Balenson" <[email-masked]>

PLEASE NOTE THE EARLY REGISTRATION AND HOTEL ROOM AVAILABILITY AND SPECIAL 
RATES DEADLINES ARE APPROACHING!!  RESERVATIONS AT THE PRINCESS RESORT
MUST BE MADE NO LATER THAN JAN 13TH FOR THE GOVERNMENT RATE, AND NO LATER
THAN JAN 20TH FOR THE REDUCED GROUP RATE.  EARLY REGISTRATION FOR THE
SYMPOSIUM MUST BE POSTMARKED NO LATER THAN JAN 22ND.

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

                 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 (AT&T Research Labs, USA)
Panelists: Li Gong (JavaSoft, USA), Jim Roskind (Netscape, USA),
Edward W. Felten (Princeton University, USA) and Peter G. Neumann
(SRI International, 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)
Panelists: Paul Lambert (Oracle, USA), Jeff Schiller (MIT, USA), 
Olafur Gudmundsson (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 and Justo Carracedo
  (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: Clifford Neuman (USC Information Sciences Institute, USA)

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

                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: Thu, 9 Jan 1997 18:31:42 +0200
From: [email-masked] (Moti Frances)
To: [email-masked]
Subject: LDAP server with X509 certificates
Cc: [email-masked]

Hello All,

Does anybody know about LDAP servers that hold X509 certificates
and are available for public usage ?

Thanx,
Moti.

===========================================================================
Moti Frances
[email-masked]
Tel: + 972 3 6131833 extension 149
---------------------------------------------------------------------------
CheckPoint Software Technologies Ltd.
3A Jabotinsky St., Diamond Tower       | Tel: + 972 3 6131833
Ramat-Gan 52511, ISRAEL                | Fax: + 972 3 5759256

http://www.checkpoint.com
============================================================================

Date: Thu, 9 Jan 1997 17:22:12 +0200
From: [email-masked] (Moti Frances)
To: [email-masked]
Subject: LDAP server with X509 certificates
Cc: [email-masked]

Hello All,

Does anybody know about LDAP servers that hold X509 certificates
and are available for public usage ?

Thanx,
Moti.

===========================================================================
Moti Frances
[email-masked]
Tel: + 972 3 6131833 extension 149
---------------------------------------------------------------------------
CheckPoint Software Technologies Ltd.
3A Jabotinsky St., Diamond Tower       | Tel: + 972 3 6131833
Ramat-Gan 52511, ISRAEL                | Fax: + 972 3 5759256

http://www.checkpoint.com
============================================================================

Date: Thu, 9 Jan 1997 15:42:01 +0200
From: [email-masked] (Moti Frances)
To: [email-masked], [email-masked]
Subject: LDAP server with X509 certificates

Hello All,

Does anybody know about LDAP servers that hold X509 certificates
and are available for public usage ?

Thanx,
Moti.

===========================================================================
Moti Frances
[email-masked]

Tel: + 972 3 6131833 extension 149
---------------------------------------------------------------------------
CheckPoint Software Technologies Ltd.
3A Jabotinsky St., Diamond Tower       | Tel: + 972 3 6131833
Ramat-Gan 52511, ISRAEL                | Fax: + 972 3 5759256

http://www.checkpoint.com
============================================================================

Date: Wed, 08 Jan 1997 09:45:07 +0100
From: Lars Johansson <[email-masked]>
Organization: PSab
To: Mark Bartel <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Error in encoding of subjectUniqueIdentifier

Mark Bartel wrote:
> 
> I was searching for examples that use UniversalString in the Subject
> or Issuer names (anybody know of any?) when I found the following in a
> certificate example:
> 
>       A2 13 00 13 10 39 37 35 32 32 31 35 32 31 32 33 34 35 36 37 31
>         -- subjectUniqueIdentifier ("9752 2152 1234 5671")
> 
> This is the only example I've ever found that uses subjectUniqueIdentifier.
> Shouldn't it be flagged primitive rather than constructed?  As in
> 
>       82 13 00 13 10 39 37 35 32 32 31 35 32 31 32 33 34 35 36 37 31
>         -- subjectUniqueIdentifier ("9752 2152 1234 5671")
> 
> (The example is from the Swedish SEIS project, at
> http://www.seis.se/proj/card/seis3v1.html.)
> 
> - Mark Bartel

You are absolutely correct! The tag should've been '82' instead of 'A2'.
There are slightly more errors in the certificate example in the SEIS S3
document. However this spec is currently being updated.

Thanks for your comment!
/Lars Johansson
Sweden Post

From: Mark Bartel <[email-masked]>
Subject: Error in encoding of subjectUniqueIdentifier
To: [email-masked]
Date: Tue, 7 Jan 1997 14:57:26 -0500 (EST)

I was searching for examples that use UniversalString in the Subject
or Issuer names (anybody know of any?) when I found the following in a
certificate example:

      A2 13 00 13 10 39 37 35 32 32 31 35 32 31 32 33 34 35 36 37 31
        -- subjectUniqueIdentifier ("9752 2152 1234 5671")

This is the only example I've ever found that uses subjectUniqueIdentifier.  
Shouldn't it be flagged primitive rather than constructed?  As in

      82 13 00 13 10 39 37 35 32 32 31 35 32 31 32 33 34 35 36 37 31
        -- subjectUniqueIdentifier ("9752 2152 1234 5671")

(The example is from the Swedish SEIS project, at
http://www.seis.se/proj/card/seis3v1.html.)

- Mark Bartel

From: Peter Williams <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Stephen Farrell'" <[email-masked]>
Subject: RE: PKCS#7 in PKIX-3
Date: Mon, 6 Jan 1997 12:49:23 -0800
Encoding: 103 TEXT

lets distinguish in the document two threat environments:

(a) internal threats to the reliability of the certification system due to 
poor message handling
(b) external threats to message communication affecting reliably auditable
release, transport and  auditable message delivery between distributed elements of
the PKIX-3 agents

(a) is countered by existing inband protection mechanism which support integrity
and possibly confidentiality-based access control.

(b) is countered by external protection mechanisms whose
use (and possible generic reliance upon) is signalled by the PKIX-3 message

This suggests that (i) PKIX-3 does not inherently change (the certification
system and flows modelled in the PKIX-3 continues to resist the threats due to
unreliable handling by end-points) as provided for by the inband protection
mechanisms (ii) PKIX-3 mesage formats have an oid field, which identifies
which external protection mechanism was used by an orignator to protect
the release, transport and delivery of the message identified by msgId.

I would expect that the PKIX-3 message would NOT be responsible
for any end-end negotiation of, or specification of required capabilities of the
external channels/controls (IPSEC would have to know how to agree algoirhtms, modes,
services etc; likewise PKCS7 profiled for PKIX-3 protection, etc) Where a PKIX-3 access
port provides for external protection models, the prevailing security policy text for the certification
system (PKIX-3) should be responsible for stating the reliance upon the particular
exernall security service, and detail how such events shall affect PKIX-3 handling

The above sugegstion would suggest a syntax change to accommodate the OID,
and specification of handling procedures for originator(s) and recipients for that
element of service.

The communication to a relying party of a cert that some std PKI policy was
in effect (using the std extension profiled in PKIX-1)  might be qualified by the fact
that the certiifcation system used, in actual fact, external
protection mechansm "foo" Such type of qualifier values are
inherently local and exist for handling by the application to instrument
reliance upon the cert based on evaulation of the id of that exernal protection
process/control-system. A std qualifier might thus be formulated to satisfy this
requirement. its qyntax might thus be only an organizationally-issued object
identifier serving to discriminate amongnst highly localised external control systems.

(one shoudl remember thath reliance upon a qualifier, to accept a policy, is
an application entity decision, not a requirement of the X.509 std cert evaluation algorithm.
Reliance policies for applications which choose to ignore the list of delivered
qualifiers, are free to do so, as always.

Peter. 

----------
From: 	Stephen Farrell
Sent: 	Monday, January 06, 1997 9:02 AM
To: 	[email-masked]
Subject: 	RE: PKCS#7 in PKIX-3

Hi All,

Given that we want to get another issue of PKIX-3 produced this month, I need
to decide what to write about protection bits this week.

I propose the following:

1. We keep the current protection bits definition and add text mandating
   support for these for some specific algorithm(s). That is,
   conforming implementations must be able to handle PKI messages which 
   are protected using the specified algorithm(s) with the bits carried in 
   the protectionBits field.

2. We add text highlighting the fact that, where available, any other 
   (external) protection mechamism (e.g. S/MIME) may equally be used to 
   protect PKI messages. (Probably the current text gives the impression
   that omitting the protection bits means that there is no protection.)

In short, we mandate the ability to use the protection bits but
do not mandate that every (or indeed, any) protected PKI message use the 
protection bits.

The above allows us to produce a specificiation which supports interop (at
least at the level of message protection) between any pair of implementations 
but which also leaves open the question as to what protection mechanisms are 
suitable for a given environment.

In the absence of further discussion (optimism:-) this is what I'll 
put in the next draft.

Regards,
Stephen.

-- 
==========================================================================
Stephen FARRELL.......................................tel: +353-1-676 9089
Software and Systems Engineering Ltd..................fax: +353-1-676 7984
Fitzwilliam Court............................email: [email-masked]
Leeson Close.....X.400: /c=ie/a=eirmail400/p=sse/o=sse/s=farrell/g=stephen 
Dublin 2...........................................www: http://www.sse.ie/
IRELAND................................................"A Siemens Company"
==========================================================================

To: [email-masked]
Subject: RE: PKCS#7 in PKIX-3
Date: Mon, 06 Jan 1997 17:02:43 +0000
From: Stephen Farrell <[email-masked]>

Hi All,

Given that we want to get another issue of PKIX-3 produced this month, I need
to decide what to write about protection bits this week.

I propose the following:

1. We keep the current protection bits definition and add text mandating
   support for these for some specific algorithm(s). That is,
   conforming implementations must be able to handle PKI messages which 
   are protected using the specified algorithm(s) with the bits carried in 
   the protectionBits field.

2. We add text highlighting the fact that, where available, any other 
   (external) protection mechamism (e.g. S/MIME) may equally be used to 
   protect PKI messages. (Probably the current text gives the impression
   that omitting the protection bits means that there is no protection.)

In short, we mandate the ability to use the protection bits but
do not mandate that every (or indeed, any) protected PKI message use the 
protection bits.

The above allows us to produce a specificiation which supports interop (at
least at the level of message protection) between any pair of implementations 
but which also leaves open the question as to what protection mechanisms are 
suitable for a given environment.

In the absence of further discussion (optimism:-) this is what I'll 
put in the next draft.

Regards,
Stephen.

-- 
==========================================================================
Stephen FARRELL.......................................tel: +353-1-676 9089
Software and Systems Engineering Ltd..................fax: +353-1-676 7984
Fitzwilliam Court............................email: [email-masked]
Leeson Close.....X.400: /c=ie/a=eirmail400/p=sse/o=sse/s=farrell/g=stephen 
Dublin 2...........................................www: http://www.sse.ie/
IRELAND................................................"A Siemens Company"
==========================================================================

Date: Mon, 06 Jan 97 07:59:04 
From: "Housley, Russ" <[email-masked]>
Encoding: 4115 Text
To: [email-masked], [email-masked]
CC: [email-masked]
Subject: Re: On-line revocation checking

Mack:

What protocols are being used for on-line validation?  And, does the private 
extension proposed in PKIX Part 1 provide all of the information necessary to 
perform on-line validation?

Russ

______________________________ Reply Separator _________________________________
Subject: On-line revocation checking
Author:  "G. Mack Hicks, VP Bank of America" <[email-masked]>
Date:    1/3/97 11:33 AM

For: IETF-PKI mail list
     CommerceNet PKI Mail list

Allow me to add to Francisco's question regarding on-line revocation.

There is a persistent belief that directories (repositories) will 
deliver to any user upon any request the CRL of designated CA's 
(designated by the CA as an 'official' repository) signed by the CA. The 
directory will also deliver all certificates for a particular 
Distinguished Name (DN) and there will be many for particular users like 
SSLv3 certs, S/MIME certs, signature certs, encryption certs, and so on.

I believe this flies in the face of the reality of on-line transaction 
cost structures and business models.

The CommerceNet PKI task force has several business models that are to 
be demonstrated. None of these provide for the model that is proposed by 
IETF. There is a "Relationship Validation Model" <URL: 
http://www.commerce.net/work/taskforces/pki/output.html#business> that 
provides for subscribers of a CA to request the repository for that CA 
for on-line certificate validation. It is the responsibility of the 
subscriber's repository to contact the repository of the subject 
certificate to validate the certificate. Repositories may exchange CRLs 
if the volume of traffic is sufficient.

To the point: It seems unreasonable to ask that a subscriber's 
repository provide unlimited service upon request from anyone with its 
remuneration provided by the subscriber. Rather, the subscriber should 
have contractual relationship with its CA and associated repository to 
provide certificate validation within the community of interest.

The futility of the current model (for free) allows for the following 
situation:

a) Subscriber sends a message to every member of the US
   congress (over 500 copies)
b) Each member of congress goes to the repository of the
   subscriber and asks for
   1) all certificates for the DN of the subscriber 
   2) latest CRL for the CA of the subscriber

The repository ends up with over messages for each single message of the 
subscriber. In addition, the receiver (who is the party that must rely 
on the message) has no contractual relationship with the CA of the 
subscriber and no contractual relationship with the repository.

Further, the receiver's system (browser, mailer, ...) must process -- 
Certificate list - finding the right one for this particular message. 
(Could be two - signature cert and encryption cert.) Then must grind 
through the CRL for to make sure the cert(s) are still good. This is 
quite a bit of work to do and proposes that all receiving software is 
able to determine the validation process for all certs within the 
community of interest.

Both IETF PKIX and NIST MISPC "allow" for on-line validation of 
certificates. <URL: http://csrc.nist.gov/pki/welcome.html#mispc> It is 
my impression of the business community that on-line validation is what 
is called for by business doing open commerce.

Finally, the work with NIST MISPC and IETF PKIX seems to be focused on 
the functions of the CA strictly. Therefore most of the heavy lifting 
(replys to messages, etc) is put to the repository and receiving 
software (emailer, browser, ...). To demonstrate interoperability and 
functionality, the easiest model is to have the repositories operate 
"for free" (i.e. without authentication). I agree, this facilitates 
testing; it does not enable electronic commerce.

For an implementation of a "relationship validation model" see the Zion 
Data Systems implementation for the repository for the state of Utah. (I 
have no URL reference, maybe someone can provide to the lists.)

Date: Mon, 06 Jan 97 07:59:13 
From: "Housley, Russ" <[email-masked]>
Encoding: 782 Text
To: [email-masked] (Francisco Fernandez Massaguer), [email-masked], Warwick Ford <[email-masked]>
Subject: Re: On-line revocation checking

I agree with Warwick that the protocol to be standardized for on-line 
validation is a subject for PKIX Part 2.  However, the private extension 
must include the necessary information to properly invoke the on-line 
validation protocol.  To this end, we need someone who is using the on-line 
validation approach to carefully review PKIX Part 1.

Russ

______________________________ Reply Separator _________________________________
Subject: Re: On-line revocation checking
Author:  Warwick Ford <[email-masked]> at internet
Date:    1/3/97 3:08 PM

Francisco:

I would consider on-line revocation checking an operational protocol, 
therefore, a topic for coverage in PKIX Part 2.  Nobody has yet stepped 
forward to start development of Part 2.

Warwick

From: <[email-masked]>
Date: Fri, 3 Jan 1997 22:55:21 -0500 (EST)
To: [email-masked]
Reply-To: [email-masked]
Subject: Is Your Web Site A Secret?

     Is your web site the best kept secret on the Internet?

     We'll promote it to 50 search engines and indexes for $85
     and complete the job in 2 business days.  Satisfaction is
     guaranteed!

If you have a great product, but are not getting many inquiries from
your Web site, you may not be adequately listed on the Web's search
engines and indexes.

Millions of viewers daily use these facilities to find the products
and services they are looking for.  But if your site is not listed, no
one will see it.

Listings on most of these services are free.  However, locating and
filling out the forms required to get a listing can take several days,
and most people just don't have the time to do it.

That is why we offer a web site promotion service.

WHAT'S THE DEAL?

We will submit your site to 50 indexes and search engines for $85.  We
will accept the return of this E-mail, with the form below filled out,
as an order.  We will bill you upon completion of the promotion.  Our
terms are net 15 days from date of invoice.  Satisfaction guaranteed!

HOW LONG WILL IT TAKE?

Generally, we complete the submissions within 48 hours of
receiving your order.  It can take any individual search engine or
index up to three weeks to process your submission, although most are
much faster.

WHAT SEARCH ENGINES AND INDEXES ARE INCLUDED IN THE
PROMOTION?

The list changes from time to time.  This is our current list:

Abaweb!, All Business Network, Alta Vista, Big Yellow, BizWeb, BizWiz,
Brian's Revised Internet Yellow Pages, Central Source Yellow Pages,
E!Net Galaxy, Enterpreneurs on the Web, Excite, Homecom's Global
Village, I-Network, I-Systems Spiral Business Directory, Infoseek,
Inktomi, Innovator's Network Yellow Pages, Internet Addressbook Yellow
Pages, Internet Mall, ISP Internet Yellow Pages, Jumpcity, Jumper Hot
Links, Linkmaster, Lycos, Magellan-McKinley Yellow Pages, NCSA What's
New, Net-Happenings, NetMall, New Virtual Yellow Pages, NTG's List,
OnLine's WWWeb Index, Open Market's Commercial Sites Index, Open Text
Web Index, Rex, Spider's Pick of the Day, Starting Point, The Source,
URL Tree, Web Central, Web Venture Hotlist, Webcrawler, Websurf, World
Wide Yellow Pages, Worldwide Announce Archive, WWW Business Yellow
Pages, WWW Worm, YelloWWWeb.

HOW WILL I KNOW THAT YOU HAVE PROMOTED MY SITE?

When we have completed the promotion, we will send you an HTML
file as an attachment to your E-mail bill.  Save this file to your
disk, and view it through your Web browser.  It provides links to the
search engine we submitted your site to, plus any comments we received
from them when we did it.

ARE THERE ANY GUARANTEES?

We do not require prepayment.  Your satisfaction is guaranteed or
you don't pay the bill.

WHO IS OWL'S EYE PRODUCTIONS?

We are a web site promotion company located at:

   Owl's Eye Productions, Inc.
   260 E. Main Street
   Brewster, NY 10509
   Phone: (914) 278-4933
   Fax:     (914) 278-4507
   Email: [email-masked]

HOW DO I ORDER?

The easiest way to order is by e-mail.  Just hit the REPLY button on
your e-mail program and fill out the following information. (This
information will be posted to the search engines/indexes):

Your name: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 
URL:  http://
Site Title: 
Description (about 25 words): 
Key words (maximum of 25, in descending order of importance):

If  billing a different address, please complete the following:

Addressee: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 

We will bill via Email. (6D14)

Terms:  By returning this document via Email, you agree as follows:
You have the authority to purchase this service on behalf of your
company.    Terms are net 15 days.  Accounts sent to collections will
be liable for collection costs.  You agree to protect and indemnify
Owl's Eye Productions, Inc. in any claim for libel, copyright
violations, plagiarism, or privacy and other suits or claims based on
the content or subject matter of  your site.

WHAT HAPPENS NEXT?

When we receive your order, we will input the information into
our system, and send you a proof.

After we process any corrections, we will run your promotion, capturing
any comments from search engines as we go.  We will incorporate these
into an HTML-formatted report to you, which we will attach to
your bill.
===Web Promotions=====Press Releases=====Link Exchanges=========
                 Owl's Eye Productions, Inc.
                   260 E. Main Street
                   Brewster, NY 10509
Ph: 914-278-4933  Fx: 914-278-4507  E-mail: [email-masked]

Date: Fri, 03 Jan 1997 16:17:24 -0500
To: Francisco Fernandez Massaguer <[email-masked]>, [email-masked]
From: David Solo <[email-masked]>
Subject: Re: On-line revocation checking

At 05:38 PM 1/3/97 +0100, Francisco Fernandez Massaguer wrote:
> 
> In the  Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document, 
>(end of 3.3 section) it is considered the possibility of (future ?) on-line 
>recovation checking approaches.
>
>I have reviewed:
>
>        draft-ietf-pkix-ipki-part1-03.txt (Part I), 
>        draft-ietf-pkix-polfmwk-00.txt (Policy), and  
>        draft-ietf-pkix-ipki3cmd-02.txt (Part III)
>
>and apart from the mentioned 3.3 section in Part I and a little note in 
>section 6.6.1 in the Policy document, I haven't found anything more about 
>this theme. 
>
>Is or will be this point considered in greater detail on some other of the 
>various draft parts or versions of PKIX ?.

The original (and still current) plan was to have a number of parts.  Part 2
is intended to cover client access protocols for other people's certificates
(cert and crl retrieval, online validation, etc.) (as opposed to part 3
which include client protocols for one's own cert).  Work on this hasn't
started in any significant way yet.  Since some work is going on now in
piloting online validation mechanisms, I would hope that based on the
results of such efforts we would attempt to capture a successful effort in
part 2 rather than try to invent from paper.  I'll admit there's no clear
timetable for the document (we're looking for volunteers).

>Thanks.
>Francisco Fernandez.
>------------------------------------------------------------------------
>Francisco Fernandez Massaguer            E-mail: [email-masked]
>ETSI Telecomunicacion Vigo                  Tel: +34-86-812181
>Vigo, SPAIN                                 Fax: +34-86-812116
>------------------------------------------------------------------------
>

Thanks,
Dave Solo

Date: Fri, 03 Jan 1997 16:18:35 -0800
From: Peter Yeatrakas <[email-masked]>
Organization: WesPay
To: "G. Mack Hicks, VP Bank of America" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: On-line revocation checking

Anyone who wants a copy of the Zions Bank implementation document 
referenced by Mack Hicks near the end of the posting below, can e-mail 
their snail-mail address to mailto:[email-masked] for a hard copy 
(not available in electronic format).

G. Mack Hicks, VP Bank of America wrote:
> 
> +----------------------------------------------------------------------+> This message was addressed to:  [email-masked]
> +----------------------------------------------------------------------+> 
> --------------------------------- Francisco Wrote on 01/03/97
> From: (Francisco Fernandez Massaguer)
> 
>  In the  Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document,
> (end of 3.3 section) it is considered the possibility of (future ?) on-line
> recovation checking approaches.
> 
> I have reviewed:
> 
>         draft-ietf-pkix-ipki-part1-03.txt (Part I),
>         draft-ietf-pkix-polfmwk-00.txt (Policy), and
>         draft-ietf-pkix-ipki3cmd-02.txt (Part III)
> 
> and apart from the mentioned 3.3 section in Part I and a little note in
> section 6.6.1 in the Policy document, I haven't found anything more about
> this theme.
> 
> Is or will be this point considered in greater detail on some other of the
> various draft parts or versions of PKIX ?.
> 
> Thanks.
> Francisco Fernandez.
> ------------------------------------------------------------------------> Francisco Fernandez Massaguer            E-mail: [email-masked]
> ETSI Telecomunicacion Vigo                  Tel: +34-86-812181
> Vigo, SPAIN                                 Fax: +34-86-812116
> ------------------------------------------------------------------------> --  end of quote from Francisco ----------
> 
> For: IETF-PKI mail list
>      CommerceNet PKI Mail list
> 
> Allow me to add to Francisco's question regarding on-line revocation.
> 
> There is a persistent belief that directories (repositories) will
> deliver to any user upon any request the CRL of designated CA's
> (designated by the CA as an 'official' repository) signed by the CA. The
> directory will also deliver all certificates for a particular
> Distinguished Name (DN) and there will be many for particular users like
> SSLv3 certs, S/MIME certs, signature certs, encryption certs, and so on.
> 
> I believe this flies in the face of the reality of on-line transaction
> cost structures and business models.
> 
> The CommerceNet PKI task force has several business models that are to
> be demonstrated. None of these provide for the model that is proposed by
> IETF. There is a "Relationship Validation Model" <URL:
> http://www.commerce.net/work/taskforces/pki/output.html#business> that
> provides for subscribers of a CA to request the repository for that CA
> for on-line certificate validation. It is the responsibility of the
> subscriber's repository to contact the repository of the subject
> certificate to validate the certificate. Repositories may exchange CRLs
> if the volume of traffic is sufficient.
> 
> To the point: It seems unreasonable to ask that a subscriber's
> repository provide unlimited service upon request from anyone with its
> remuneration provided by the subscriber. Rather, the subscriber should
> have contractual relationship with its CA and associated repository to
> provide certificate validation within the community of interest.
> 
> The futility of the current model (for free) allows for the following
> situation:
> 
> a) Subscriber sends a message to every member of the US
>    congress (over 500 copies)
> b) Each member of congress goes to the repository of the
>    subscriber and asks for
>    1) all certificates for the DN of the subscriber
>    2) latest CRL for the CA of the subscriber
> 
> The repository ends up with over messages for each single message of the
> subscriber. In addition, the receiver (who is the party that must rely
> on the message) has no contractual relationship with the CA of the
> subscriber and no contractual relationship with the repository.
> 
> Further, the receiver's system (browser, mailer, ...) must process --
> Certificate list - finding the right one for this particular message.
> (Could be two - signature cert and encryption cert.) Then must grind
> through the CRL for to make sure the cert(s) are still good. This is
> quite a bit of work to do and proposes that all receiving software is
> able to determine the validation process for all certs within the
> community of interest.
> 
> Both IETF PKIX and NIST MISPC "allow" for on-line validation of
> certificates. <URL: http://csrc.nist.gov/pki/welcome.html#mispc> It is
> my impression of the business community that on-line validation is what
> is called for by business doing open commerce.
> 
> Finally, the work with NIST MISPC and IETF PKIX seems to be focused on
> the functions of the CA strictly. Therefore most of the heavy lifting
> (replys to messages, etc) is put to the repository and receiving
> software (emailer, browser, ...). To demonstrate interoperability and
> functionality, the easiest model is to have the repositories operate
> "for free" (i.e. without authentication). I agree, this facilitates
> testing; it does not enable electronic commerce.
> 
> For an implementation of a "relationship validation model" see the Zion
> Data Systems implementation for the repository for the state of Utah. (I
> have no URL reference, maybe someone can provide to the lists.)
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Anyone who wants a copy of the Zions Bank implementation document can 
e-mail snail-mail address to mailto:[email-masked] for a hard copy 
(not available on the net).
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++> -- 
Best Regards
Pete Yeatrakas WESPAY 1111 Bayhill Dr #150 
San Bruno CA 94066-3035  http://www.wespay.com
PH: 1-415/871-8762    FAX 1-415/871-9326

Date: Fri, 03 Jan 97 15:02:08 
From: "Housley, Russ" <[email-masked]>
Encoding: 1707 Text
To: [email-masked], [email-masked] (Francisco Fernandez Massaguer)
Subject: Re: On-line revocation checking

The private extension tells a certificate user how to contact the on-line 
service for revocation checking.  After the last IETF meeting, this appears 
to be the only function that requires the private extension.  The other 
features are provided by the URI form of GeneralName.

No one has suggested a protocol for on-line revocation checks.  Perhaps the 
USPS would like to share the one they plan to use?

Russ

______________________________ Reply Separator _________________________________
Subject: On-line revocation checking
Author:  [email-masked] (Francisco Fernandez Massaguer) at internet
Date:    1/3/97 8:25 AM

 In the  Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document, 
(end of 3.3 section) it is considered the possibility of (future ?) on-line 
recovation checking approaches.

I have revised
        draft-ietf-pkix-ipki-part1-03.txt (Part I), 
        draft-ietf-pkix-polfmwk-00.txt (Policy), and  
        draft-ietf-pkix-ipki3cmd-02.txt (Part III)

and apart from the mentioned 3.3 section in Part I and a little note in 
section 6.6.1 in the Policy document, I haven't found anything more about 
this theme. 

Is or will be this point considered in greater detail on some other of the 
various draft parts or versions of PKIX ?.

Thanks.
Francisco Fernandez.
------------------------------------------------------------------------ 
Francisco Fernandez Massaguer            E-mail: [email-masked] 
ETSI Telecomunicacion Vigo                  Tel: +34-86-812181
Vigo, SPAIN                                 Fax: +34-86-812116 
------------------------------------------------------------------------

Date: Fri, 03 Jan 1997 17:13:20 -0800
To: [email-masked] (Francisco Fernandez Massaguer), [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: On-line revocation checking

Francisco:

I would consider on-line revocation checking an operational protocol,
therefore, a topic for coverage in PKIX Part 2.  Nobody has yet stepped
forward to start development of Part 2.

Warwick

At 04:34 PM 1/3/97 +0100, Francisco Fernandez Massaguer wrote:
> 
> In the  Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document, 
>(end of 3.3 section) it is considered the possibility of (future ?) on-line 
>recovation checking approaches.
>
>I have revised
>        draft-ietf-pkix-ipki-part1-03.txt (Part I), 
>        draft-ietf-pkix-polfmwk-00.txt (Policy), and  
>        draft-ietf-pkix-ipki3cmd-02.txt (Part III)
>
>and apart from the mentioned 3.3 section in Part I and a little note in 
>section 6.6.1 in the Policy document, I haven't found anything more about 
>this theme. 
>
>Is or will be this point considered in greater detail on some other of the 
>various draft parts or versions of PKIX ?.
>
>Thanks.
>Francisco Fernandez.
>------------------------------------------------------------------------
>Francisco Fernandez Massaguer            E-mail: [email-masked]
>ETSI Telecomunicacion Vigo                  Tel: +34-86-812181
>Vigo, SPAIN                                 Fax: +34-86-812116
>------------------------------------------------------------------------
>
> 
>
>
>
>
>
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

X400-Received: by /c=US/admd=attmail/; Relayed; 03 Jan 97 11:33:07 -0800
X400-Received: by mta BofA-MTA in /c=US/admd=attmail/; Relayed;  03 Jan 97 11:33:07 -0800
X400-Mts-Identifier: [/c=US/admd=attmail/; 0644032CD5EF300D-attmail]
Content-Identifier: 0644032CD5EF300D
Content-Return: Allowed
X400-Content-Type:  P2-1984 ( 2 )
Conversion: Allowed
Conversion-With-Loss: Allowed
Priority: normal
Disclose-Recipients: Prohibited
Alternate-Recipient: Allowed
X400-Originator: [email-masked]
X400-Recipients: non-disclosure;
Date: 03 Jan 97 11:33:07 -0800
From: "G. Mack Hicks, VP Bank of America" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: On-line revocation checking

--------------------------------- Francisco Wrote on 01/03/97
From: (Francisco Fernandez Massaguer)

 In the  Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document,
(end of 3.3 section) it is considered the possibility of (future ?) on-line
recovation checking approaches.

I have reviewed:

        draft-ietf-pkix-ipki-part1-03.txt (Part I),
        draft-ietf-pkix-polfmwk-00.txt (Policy), and
        draft-ietf-pkix-ipki3cmd-02.txt (Part III)

and apart from the mentioned 3.3 section in Part I and a little note in
section 6.6.1 in the Policy document, I haven't found anything more about
this theme.

Is or will be this point considered in greater detail on some other of the
various draft parts or versions of PKIX ?.

Thanks.
Francisco Fernandez.
------------------------------------------------------------------------
Francisco Fernandez Massaguer            E-mail: [email-masked]
ETSI Telecomunicacion Vigo                  Tel: +34-86-812181
Vigo, SPAIN                                 Fax: +34-86-812116
------------------------------------------------------------------------
--  end of quote from Francisco ----------

For: IETF-PKI mail list
     CommerceNet PKI Mail list

Allow me to add to Francisco's question regarding on-line revocation.

There is a persistent belief that directories (repositories) will
deliver to any user upon any request the CRL of designated CA's
(designated by the CA as an 'official' repository) signed by the CA. The
directory will also deliver all certificates for a particular
Distinguished Name (DN) and there will be many for particular users like
SSLv3 certs, S/MIME certs, signature certs, encryption certs, and so on.

I believe this flies in the face of the reality of on-line transaction
cost structures and business models.

The CommerceNet PKI task force has several business models that are to
be demonstrated. None of these provide for the model that is proposed by
IETF. There is a "Relationship Validation Model" <URL:
http://www.commerce.net/work/taskforces/pki/output.html#business> that
provides for subscribers of a CA to request the repository for that CA
for on-line certificate validation. It is the responsibility of the
subscriber's repository to contact the repository of the subject
certificate to validate the certificate. Repositories may exchange CRLs
if the volume of traffic is sufficient.

To the point: It seems unreasonable to ask that a subscriber's
repository provide unlimited service upon request from anyone with its
remuneration provided by the subscriber. Rather, the subscriber should
have contractual relationship with its CA and associated repository to
provide certificate validation within the community of interest.

The futility of the current model (for free) allows for the following
situation:

a) Subscriber sends a message to every member of the US
   congress (over 500 copies)
b) Each member of congress goes to the repository of the
   subscriber and asks for
   1) all certificates for the DN of the subscriber
   2) latest CRL for the CA of the subscriber

The repository ends up with over messages for each single message of the
subscriber. In addition, the receiver (who is the party that must rely
on the message) has no contractual relationship with the CA of the
subscriber and no contractual relationship with the repository.

Further, the receiver's system (browser, mailer, ...) must process --
Certificate list - finding the right one for this particular message.
(Could be two - signature cert and encryption cert.) Then must grind
through the CRL for to make sure the cert(s) are still good. This is
quite a bit of work to do and proposes that all receiving software is
able to determine the validation process for all certs within the
community of interest.

Both IETF PKIX and NIST MISPC "allow" for on-line validation of
certificates. <URL: http://csrc.nist.gov/pki/welcome.html#mispc> It is
my impression of the business community that on-line validation is what
is called for by business doing open commerce.

Finally, the work with NIST MISPC and IETF PKIX seems to be focused on
the functions of the CA strictly. Therefore most of the heavy lifting
(replys to messages, etc) is put to the repository and receiving
software (emailer, browser, ...). To demonstrate interoperability and
functionality, the easiest model is to have the repositories operate
"for free" (i.e. without authentication). I agree, this facilitates
testing; it does not enable electronic commerce.

For an implementation of a "relationship validation model" see the Zion
Data Systems implementation for the repository for the state of Utah. (I
have no URL reference, maybe someone can provide to the lists.)

Date: Fri, 3 Jan 1997 17:38:27 +0100
From: [email-masked] (Francisco Fernandez Massaguer)
To: [email-masked]
Subject:  On-line revocation checking

 In the  Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document, 
(end of 3.3 section) it is considered the possibility of (future ?) on-line 
recovation checking approaches.

I have reviewed:

        draft-ietf-pkix-ipki-part1-03.txt (Part I), 
        draft-ietf-pkix-polfmwk-00.txt (Policy), and  
        draft-ietf-pkix-ipki3cmd-02.txt (Part III)

and apart from the mentioned 3.3 section in Part I and a little note in 
section 6.6.1 in the Policy document, I haven't found anything more about 
this theme. 

Is or will be this point considered in greater detail on some other of the 
various draft parts or versions of PKIX ?.

Thanks.
Francisco Fernandez.
------------------------------------------------------------------------
Francisco Fernandez Massaguer            E-mail: [email-masked]
ETSI Telecomunicacion Vigo                  Tel: +34-86-812181
Vigo, SPAIN                                 Fax: +34-86-812116
------------------------------------------------------------------------

Date: Fri, 3 Jan 1997 16:34:44 +0100
From: [email-masked] (Francisco Fernandez Massaguer)
To: [email-masked]
Subject:  On-line revocation checking

 In the  Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document, 
(end of 3.3 section) it is considered the possibility of (future ?) on-line 
recovation checking approaches.

I have revised
        draft-ietf-pkix-ipki-part1-03.txt (Part I), 
        draft-ietf-pkix-polfmwk-00.txt (Policy), and  
        draft-ietf-pkix-ipki3cmd-02.txt (Part III)

and apart from the mentioned 3.3 section in Part I and a little note in 
section 6.6.1 in the Policy document, I haven't found anything more about 
this theme. 

Is or will be this point considered in greater detail on some other of the 
various draft parts or versions of PKIX ?.

Thanks.
Francisco Fernandez.
------------------------------------------------------------------------
Francisco Fernandez Massaguer            E-mail: [email-masked]
ETSI Telecomunicacion Vigo                  Tel: +34-86-812181
Vigo, SPAIN                                 Fax: +34-86-812116
------------------------------------------------------------------------

Date: Fri, 3 Jan 1997 13:33:51 +0100
From: [email-masked] (Francisco Fernandez Massaguer)
To: [email-masked]
Subject: Re: Re:  standard docs. availability

>  
>	> 
>	> I would wish to revise the following documents:
>	>  
>	>   *   ISO/IEC DIS 13888-3 (JTC 1 / SC 27)
>	>       Information technology -- Security techniques -- 
>	> Non-repudiation 
>	>       -- Part 3: Using asymmetric techniques 
>	> 
>	>   *   X9.57 -- Certificate Management
>	> 
>	> The first is at draft status and is not yet available from ISO; it is 
>	> a different (?) document than ISO 10181-4 also on non-repudiation.
>	> The second is not yet available from ANSI.
>	>   
>	> Can anyone in this list tell me how to get these documents ?.
>	> 
>
> Try www.iso.ch.  I tried to connect this evening but was unsuccesful.
> I suspect that you will have to buy the ISO/IEC doc. 

Thanks Luc for your answer,

I had already contacted ISO organization. His response was that 
ISO/IEC 13888-3 wasn't yet available, because it is in CD (Committee Draft) 
status.

Regards

From: <[email-masked]>
To: [email-masked]
Subject: X.509 guide/notes available
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 3 Jan 1997 04:34:26 (NZDT)

I've now made the X.509 notes I posted here some time ago available online at
http://www.cs.auckland.ac.nz/~pgut001/x509guide.txt.  They carry the rather 
pretentious title "X.509 Style Guide" because they started out as an attempt 
to clarify some rather unclear X.509 implementation issues and provide hints 
on potential problem spots.  Here's the introduction:
 
>There seems to be a lot of confusion out there about how to implement and work
>with X.509 certificates, mainly due to either ASN.1 encoding issues, or becaus
>the general non-presence of X.500 means people have to take guesses at what
>some of the X.500-related fields are supposed to look like.  For this reason I
>decided to put together some guidelines which people could follow when creatin
>software to work with X.509 certificates, CRL's, and other ASN.1-encoded data
>types. The document is intended to be a collection of the experiences of
>developers and implementors to help developers new to the area create
>interoperable implementations.
 
Before people point this out, I've just noticed that the comments about Y2K 
problems are out of date, I'll change that section of the text within the next 
few days.
 
Peter.

Date: Thu, 02 Jan 97 07:03:56 
From: "Housley, Russ" <[email-masked]>
Encoding: 1728 Text
To: [email-masked]
CC: [email-masked]
Subject: Re: validity dates in latest draft-ietf-pkix-ipki-part1-03

Anil:

The CHOICE proposal has been submitted to the ISO/ITU-T folks working on 
Directory standards.  We see no reason why the change to the syntax will 
not be accepted.  If it is not accepted, a paragraph pointing out the 
difference will be added to the profile.

At the PKIX Working Group meeting in San Jose, several people raised 
concerns about the "sliding window" approach.  It was agreed to change this 
portion of the profile.  It was agreed that dates with years before 2051 
will be encoded as UTCTime, and dates with years after 2050 will be encoded 
as GeneralizedTime.  Thus, there will be only one way to encode any 
particular date.

Russ

______________________________ Reply Separator _________________________________
Subject: validity dates in latest draft-ietf-pkix-ipki-part1-03.txt
Author:  [email-masked]
Date:    12/25/96 3:12 AM

The document presents the proposed validity date 
CHOICE UTCTime/GeneralizedTime as if it were part of 
the X.509 v3 definition.

Did this in fact make it into the latest X.509 v3 Amendments? 
If this is in fact not in the X.509 v3 spec, the document needs 
to call this out as a IETF/IPKI difference.

In addition, the following should be noted:

- Between 2005 and 2015 one cannot obtain a DER encoding by knowing
  the (abstract) time values alone.  (Two choices are possible.) This 
  breaks DER principles (though most current usage does not rely on this 
  stringent value-implies-encoding property).  You need to have a
  single changeover date if you want to preserve this property.

- The section on GeneralizedTime should be numbered 4.1.2.5.2.
  (There are two sections currently numbered 4.1.2.6)

-anil.

Date: Thu, 2 Jan 1997 16:00:20 +0100
From: [email-masked] (Francisco Fernandez Massaguer)
To: [email-masked]
Subject: Standard documents availability.

I would wish to revise the following documents:
 
  *   ISO/IEC DIS 13888-3 (JTC 1 / SC 27)
      Information technology -- Security techniques -- Non-repudiation 
      -- Part 3: Using asymmetric techniques 

  *   X9.57 -- Certificate Management

The first is at draft status and is not yet available from ISO; it is 
a different (?) document than ISO 10181-4 also on non-repudiation.
The second is not yet available from ANSI.
  
Can anyone in this list tell me how to get these documents ?.

Thanks 
-------------------------------------------------------------------------------
Francisco Fernandez Massaguer                  E-mail: [email-masked]
ETSI Telecomunicacion Vigo                        Tel: +34-86-812181
Vigo, SPAIN                                       Fax: +34-86-812116
-------------------------------------------------------------------------------