Subject: Jazz It Up
From: [email-masked]
To: [email-masked]
Date: 30 May 98 8:54:12 PM

LET US DO YOUR BULK E-MAIL ADVERTISING!!!

$600 PER MILLION (5 MILLION OR MORE $500 PER MILLION)
$450 PER 1/2 MILLION
These prices are non-targeted.

THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS!

Let our company do mailing for your product/service, 
newsletter/report or client list.

Addresses are extracted 24 hours a day 7 days a week, 
scanning the net for new addresses.  Estimated 
150-200,000 addresses extracted daily.  They are fresh!  
Over 55 million addresses on file.

No more than 2 pages (50 lines), no porn, no sexual 
relative material and no foul language.  Each ad must 
be no more than 50 characters wide by 50 lines deep.

***Targeted mailings: 
$200 per 50,000 addresses or less extracted.
$125 per 25,000 addresses or less extracted.
We can extract by city, country, occupation, 
organizations, associations, product, website, state, 
megatags (keywords), etc.  If we can not search and 
extract what you need, then nobody can.  No one can 
target your mailing for less.

***AND NOW WE CAN EXTRACT BY CITY!

If interested in purchasing targeted addresses:
$10 per 1,000 up to 100,000 (min. 10,000)
$7.50 per 1,000 over 100,000 & up to 500,000
$5.00 per 1,000 over 500,000

***SPECIAL*** Targeted US ADDRESSES ONLY $750 per 1/2 
million.  A savings of $1,250.  We have over 10 million 
addresses, non AOL, and collecting more each day.

There are no lower prices on the net.  Your mailing 
can be done in a matter of hours, instead of days.  

For the fastest service, cheapest prices and cleanest
mailings call our processing and new accounts department
at 904-282-0945, Monday - Friday 9 - 5 EST.  If the line 
is busy or no answer, please keep trying, as bulk mailing 
is growing fast.  We do want to work with you to advertise 
your product.  Check out our prices and compare with 
other bulk emailers, you will find we have the BESt prices 
anywhere.  In fact, we do bulk mailings for many other 
bulk emailers.

To have yourname@domain removed, call our processing 
department.  Any negative responses will be dealt with 
accordingly.

Date: Fri, 29 May 1998 11:10:13 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: INFORMATION SECURITY COMMITTEE MEETING NOTICE
Sender: [email-masked]

For the information of list subscribers...

------------------
INFORMATION SECURITY COMMITTEE MEETING NOTICE
                                      June 16-18, 1998
                                        Linthicum, MD

Please correspond with: 
     Michael S. Baum, Esq. 
     1390 Shorebird Way
      Mountain View, CA  94043
      V: +1 650-4293444 
      F: +1 617-961-7300 
      N: [email-masked] 

Dear Committee Member and Prospective Members: 

     You are cordially invited to participate in a meeting of the
Information Security Committee, Section of Science & Technology, American
Bar Association, on June 16-18 1998 (Tuesday through Thursday). Sponsored
by the National Security Agency, the meeting will be held at the Double
Tree Guest Suites Hotel BWI and the Merchant Institute in Linthicum,
Maryland (by the Baltimore-Washington Airport). The Committee will continue
its advancement of public key infrastructure legal and control issues, and
will include further work on CA accreditation, commercial key recovery
guidelines, PKI evidentiary issues, certificate policy, and user liability,
among other matters. 

     Consistent with Section policy, ISC meeting participants must be
members of both the ABA and the ABA Section of Science and Technology.
Please contact Ann Kowalsky, Manager Section of Science & Technology, at
ABA headquarters in Chicago by phone: +1 (312) 988.5599, fax: +1 (312)
988.5628, or email:  [email-masked] for membership information. You
can become a paid member of the ABA and the ISC at the June 16-18 meeting
-- and associate ABA membership is available for non-lawyers. 

     Special thanks to Jan Manning and Theresa Wheeler of the NSA's
Security Management Infrastructure Office (X3), Network Security Group (X)
for their efforts to coordinate this meeting, including the planned social
at the NSA's Cryptologic Museum, and their facilitation of the NSA
sponsorship. It is greatly appreciated.

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

     Sincerely, 

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

                                                  Proposed Agenda
                           INFORMATION SECURITY COMMITTEE
                              Section of Science & Technology, ABA
                                                   16-18 June 1998

     Proposed Agenda (in extended sessions, breaks will be taken as needed.) 

     16 June 1998	 Tuesday (business attire recommended for all sessions) 
     08:30 - 09:00	Greetings, coffee, administrative matters (note: all
times are "local") 
     09:00 - 09:30	Introductions, meeting logistics, general announcements 
     09:30 - 1030	Working Group updates 
     10:30 - 12:00	WG breakouts 
     12:00 - 13:00	Lunch speaker: Jim Wallner, Sr. Security Analyst, NSA
"Threat and Vulnerability Model
 for A Public Key Infrastructure"(tentative)
     13:00 - 17:00	WG breakouts 
     17:00 - ????	Watering hole discussions; possible continuation of WG
meetings 

     17 June1998 - Wednesday 
     08:30 - 09:00 Greetings, coffee, administrative matters 
     09:00 - 09:30 Updates -- logistics, administrative, WG related, etc. 
     09:30 - 12:00 WG breakouts 
     12:00 - 13:00 Lunch speaker: TBD
     13:00 - 17:00 WG breakouts 
     18:30 - 20:20  Social event: Reception at the NSA Cryptologic Museum,
hosted by the National Security 
Agency. Bus transportation to the Museum provided from/to the Doubletree.
Bus departs
 from the hotel at ~18:30 and departs from the Museum at 20:30.

     18 June 1998 - Thursday 
     08:30 - 09:00 Greetings, coffee, administrative matters 
     09:00 - 09:30 Updates -- logistics, administrative, WG related, etc. 
     09:30 - 12:00 WG breakouts 
     12:00 - 13:00 Lunch speakers: Dean Adams, The Open Group; John
Nagengast, Chief Network Security
Group, NSA, "The DoD's Information Assurance Program" 
     13:00 - 15:00 WG wrap-ups 
     15:00 - 16:00 WG presentations 
     16:00 - 16:30 Path Forward, close 

     Additional proposed agenda items and speakers should be E-mailed to
Michael Baum ([email-masked]). 

                                            Working Groups
                                 Information Security Committee
          Electronic Commerce Division, Section of Science and Technology
                                      MEETING DETAILS
                                         16-18 June 1998

     Members are urged to participate in at least one of the Working Groups
that will be presenting/meeting during the ISC's meeting. Please contact
Ruven Schwartz, committee vice chair, or a working group co-chair directly,
for further information. 

     **Accreditation Working Group 
     Contacts: Bill Burr ([email-masked]) 
     Charlie Merrill, Esq. ([email-masked]) 
     Lynn McNulty ([email-masked]) 

     The Accreditation WorkGroup will continue work on its draft document,
with a view toward distributing a draft on the Internet for industry
comments by year-end.  An ad hoc editorial group recently met in NYC to
restructure the material and suggest a more descriptive title for the work
as follows: "PKI Evaluation Guidelines--A Process to Assure Trustworthy PKI
by Developing Certificate Policies and Accreditation Guidelines for
Evaluators of CAs and other PKI Components."  The editorial group also
considered a suggested extension to Section 2 of the Chokhani-Ford
Framework, providing more detail for treatment of legal issues, as well as
certain other adjustments to reflect the life-cycle of a certificate.  At
and prior to the June meeting, members of the Accreditation WG will have
the opportunity to review the editorial group's suggestions and continue
drafting assigned sections following the structure of the Framework and
some model provisions which will be distributed in advance.

     **Audit and Controls Working Group
     Contact: Kevin Coleman ([email-masked])
     Charles Le Grand ([email-masked])

     The Audit and Controls Working Group will continue to focus on the
requirements for the audit of certificate authorities, defining the audit
scope, model audit program, extent of test work and form of reporting.

     **Certificate Services Agreements Working Group 
     Contacts: Kevin O'Neill ([email-masked]) 
     Stephen Wu ([email-masked]) 

     The Certification Services Agreements Work Group is charged with
writing "Certification Services Agreements," which is an outgrowth of the
ISC's accreditation and cert. policies activity. The purpose of
"Certification Services Agreements" is to assist the authors of a
certificate policy definition, certification practice statement, subscriber
agreement, relying party agreement, or other agreement relating to
certification services by providing model forms and a menu of alternative
legal wording for use in particular clauses of such documents. The document
will include comments and annotations to the Guidelines for Certificate
Policies and Accreditation Criteria. The group will review the current
draft of the document and discuss plans for further development.  The group
will also advance their draft "Cross-Certification" Agreement."

     **Comparative Law Working Group 
     Contacts: Serge Parisien, Esq. ([email-masked]) 
     Suzanne Thibodeau ([email-masked])

     The Comparative Law work group will continue its exploration of the
requirements for PKI in civil law and other legal jurisdictions. It will
also continue efforts to harmonize legal infrastructure with the common law. 

     **Digital Signatures Laws & Regulations Working Group 
     Contacts: Kenneth Allen, Esq. ([email-masked]) 
     David Danner, Esq. ([email-masked]) 
     Dan Greenwood, Esq. ([email-masked]) 

     The Legislative and Regulatory Working Group will hold its periodic
conference call, to discuss updates to legislation and regulation regarding
electronic authentication. The Leg./Reg. Working Group will
continue/finalize its study of a need for model regulations to support the
electronic and digital signature legislative laws enacted in several states
to date. 

     **Evidentiary Working Group 
     Contacts: Gary Fresen, Esq. ([email-masked]) 
     Serge Parisien, Esq. ([email-masked]) 

     The Evidentiary Work Group will continue its drafting of the judicial
tutorial (a tutorial for judges to admit technology into evidence) and
report on its coordination activities with record management standards
authorities. The working group members will also assist the other working
groups on their evidentiary issues. 

     **Global Trade Working Group 
     Contacts: Joseph Alhadeff, Esq. ([email-masked]) 
     Lisa Kinard ([email-masked]) 
     Linda Macintosh ([email-masked]) 

     The Global Trade Work Group identifies and collaborates with trade
groups whose work influences secure global trade and reports critical
issues back to the ISC. The WG is developing an overall framework to
structure and analyze secure trade issues; and is preparing an issues
statement concerning cooperation between legal, business and technological
professionals to reduce secure electronic international trade barriers. 

     **Key Recovery Working Group (KRWG) 
     Contacts: Emily Frye, Esq. ([email-masked]) 
     Dwight Olson, Esq. ([email-masked]) 
     Randy Sabett, Esq. ([email-masked]) 

     The KRWG monitors proposed legislation and regulations, both here and
abroad, that address key recovery, and offers comments where appropriate.
The KRWG's major initiative documents the framework and operation of a key
recovery center. Work is in the advanced outline stage and will focus on
fleshing out draft text. In addition, a Task Group convened by Ken Bass,
Esq. will develop and propose general criteria for "trustworthy entities"
to expand the current BXA limitations to banks and certain financial
institutions.

     **Liability Working Group 
     Contacts: Maureen Adamache, Esq. ([email-masked]) 
     Elise Reed, Esq. ([email-masked]) 

     The Liability Work Group will continue its work with the Accreditation
Group on the liability issues, including preparing liability policy
statements and also suitable clauses for inclusion in PKI/CA-user and
PKI/CA cross-certification agreements. It will also continue its analyses
of the liability of application software providers, and for other
(non-digital signature, non-confidentiality encryption) applications of
public key cryptography. Finally, it will consider technical methods of
solving the legal problem of binding relying parties. 

     Logistics

     Recommended attire: business attire at all times.

     First-time participants planning to attend the June 16-18 meeting:
Please contact Ruven Schwartz, ISC ViceChair, at 612-687-8095 or
[email-masked] to coordinate meeting work-product
contributions. 

     Meeting Location: 
June 16 - Doubletree Guest Suites BWI Hotel 
June 17 - Maritime Institute (transportation provided from the Doubletree)
June 17 - Doubletree Guest Suites BWI Hotel

     Meals: Lunches will be provided at cost.

Lodging:  The primary hotel for the Information Security Committee's
meeting is the:

Doubletree Guest Suites BWI Hotel
1300 Concourse Drive
Linthicum, MD  21090
Tel. +1 410-850-0747
Fax. +1 410-850-0895

Free hourly transportation is available to/from the BWI airport.

A block of rooms have been reserved (all rooms in the hotel are suites) for
the evenings of June 15-17. The rooms will be held ONLY until May 25th --
so please reserve immediately!   The one bedroom suites/single cost $126.00
per night, plus tax (the hotels regular published rates are $150.00/suite).
 We recommend that you stay at the Doubletree because the first and third
day of our meeting will be held *in* the hotel (that is, on June 16th and
18th). Request the "American Bar Association's - ABA ISC" special rate.

There will be a one-time ~ $ 95 fee to cover transportation to/from the
Maritime Institute, the Cryptologic Museum, food at the reception, and
lunch for each day of our meeting. 

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

     See you in Linthicum.

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

From: "Peter Lipp" <[email-masked]>
To: "PKIX Mailinglist" <[email-masked]>
Subject: question on Subject Key Identifier ipki-part1-07
Date: Fri, 29 May 1998 10:17:00 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0036_01BD8AEA.EB898300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This document sais:

>The hash shall  be calculated over the value (excluding tag and length) of
the BIT
>STRING subjectPublicKey in the certificate.

I assume that excluding tag and length comes from the fact that this was the
same
in PEM - and PKCS. Currently, PKCS#7 specs changed this behaviour and
tag and length get included into the hash. Wouldn't it make sense to do the
same here
or is there any specific reason not to?

Peter

------=_NextPart_000_0036_01BD8AEA.EB898300
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0036_01BD8AEA.EB898300--

From: "Robert Klerer" <[email-masked]>
To: <[email-masked]>
Subject: comment on draft-ietf-pkix-ipki2opp-07
Date: Thu, 28 May 1998 13:52:36 -0400
Sender: [email-masked]

The concept of "reading" a certificate from a repository as described in
section 6 is insufficient for accommodating the use of alternate names.

In order for an application, such as e-mail, to find the certificate using
it's natural alternate name (RFC822 address or labeledURI), would require a
"search" (section 7).

Why is the classifying a read as a search a problem?  The read SHOULD be
allowed via anonymous access.  (Some current version e-mail clients can
operate only with anonymous access).  The search MAY require authenticated
access, depending of the perception of the propriety of the information.

This misfit of the standard verses the reality, is understandable given the
desire to adhere to ldapv2.  But, this issue forces the implementers to go
through hoops trying to restrict the search to the appropriate information
appropriately.  For example, I feel that it is inappropriate to allow a
wildcard search of my repository on RFC822 address using anonymous access.
I believe that a junk mail mass marketer could easily use this hole to
gather mailing lists and swamping them with junk mail.

Hence my customers who want to use secure mail, would not be happy to be
subjected to a deluge of junk mail.  The widespread availability of
certificates is critical to the success of the pki.

The reason the correction should be made here is to give guidance so that
the certificate requestors would use the same message set (subsets) for the
read by alternate name.  If no action is taken then the risk of the
multiplicity of how requestors execute the read exists and has already
occurred.  So limiting anonymous access to read, reserving search for
authenticated access becomes an insurmountable task.

Date: Thu, 28 May 1998 13:42:05 -0400
From: Gene Passarelli <[email-masked]>
Subject: signoff ietf-pkix
Cc: [email-masked]
Sender: [email-masked]

signoff ietf-pkix

Date: Thu, 28 May 98 13:40:38 EDT
From: Gene Passarelli <[email-masked]>
To: [email-masked]
Subject: signoff ietf-pkix
Sender: [email-masked]

signoff ietf-pkix

From: "Peter Lipp" <[email-masked]>
To: "Ed Gerck" <[email-masked]>, "Tony Bartoletti" <[email-masked]>
Cc: "Carl Ellison" <[email-masked]>, "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Date: Thu, 28 May 1998 17:34:38 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_01DA_01BD8A5E.E38E13A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>>The point being, such paper is at heart "not to be relied upon"
>>in the pure mathematical sense, and yet we do rely upon it, and
>>it works for us "most" of the time.
Yes - and thats what I claim should hold for certificates as well.
If their issuing is based on passports, they obviously must be
less-or-equally reliable though.

>transfer. Further, they are being developed into a useful set of
>protocols which will not be patented (strange as it may seem) but
>available to anyone, under copyright protection and worldwide
>non-partisan development/distribution by a neutral group (MCG) with
>participants from 26 countries.

Will these be solving the same problems inherent in passports as well :-)
There are some basic problems that cannot be overcome with any system
using central authorties and claiming to set up trust chains leading to
people
I, as a user, do not know personally, except by adding personal information,
like signed keys ala PGP or relative names from SDSI, or by flawing
privacy issues. And if you try to redefine trust you might have difficulties
explaining that to the users....... correction, YOU won't have any
difficulties
explaining anything, they just might not be able to understand..... :-)

Peter

------=_NextPart_000_01DA_01BD8A5E.E38E13A0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_01DA_01BD8A5E.E38E13A0--

Date: Thu, 28 May 1998 15:52:10 +0200
To: Santosh Chokhani <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ipki-part4-03.txt
Sender: [email-masked]

Hi Santoch, Thank you for your reply.

I know that the structure allows definitions for CAs, RAs, Subscribers
etc. The problem is how to include general exceptions for RAs versus
the requirements on CA. Many times this is differing depending on what
kind of services the RA is involved in and I need a place to define these 
provisions.

It comes to my mind that it might be better to include general
exceptions and provisions regarding the divisions of duties between
the CA and its RAs, in the top section of the topic instead of creating
a new subsection. I.e. including my 5.1.9 under 5.1, 5.2.1.2
under 5.2.1 and 5.3.9 under 5.3. Thus avoiding un logic changes
in the structure.

The drawback of this is of course to start defining exceptions before
the actual requirements are presented in the subsections. This may
feel the wrong way round, but I'm not sure.

My main question about "2.10 Contractual Agreements" remain unanswered.

Again I higly welcome every view on this topic since I only have a few
days left to finalise this policy before approval.

Stefan 

At 08.58 1998-05-28 -0400, Santosh Chokhani wrote:
>Please note that the PKIX Part 4 allows for the security controls,
>roles, etc. to be defined for the various PKI entities, including
>issuing CA, subject CAs, RAs, subscribers, repositories, etc (see
>section 4.5 and 4.6 of the framework)
>
>Thus, all of Stefan's inclusions  in Section 5 are within the scope of
>the framework.
>
>> -----Original Message-----
>> From:	Stefan Santesson [SMTP:[email-masked]]
>> Sent:	Wednesday, May 27, 1998 5:48 PM
>> To:	[email-masked]
>> Subject:	Comments on draft-ietf-pkix-ipki-part4-03.txt
>> 
>> I'm project leader of a joint Swedish project with the
>> purpose to form a certificate policy for a Swedish national 
>> "bas-ID" certificate.
>> 
>> The project is formed by the Swedish non-profit organization
>> SEIS (Secured Electronic Information in Society) which is 
>> formed by members from Government, Banking, Industry, Military,
>> Post and Health care sectors.
>> 
>> The policy can be obtain from SEIS WWW at:
>> 
>> http://www.seis.se/regler/normer/S10_v093.doc
>> 
>> This policy is now ready for official approval on June 16
>> by the SEIS board.
>> 
>> The policy almost follows the structure of
>> draft-ietf-pkix-ipki-part4-03.txt 
>> We have, however, been forced to expand the structure with the 
>> following sections.
>> 
>> 2.10 Contractual agreements.
>> In the policy we state requirements on the CA to establish a 
>> number of contractual agreements according to some minimum 
>> standards. This is contracts with the subscriber, employer of the 
>> subscriber with which the subscriber is affiliated in the 
>> certificate, Subcontractors (such as RA:s), etc. We could not find 
>> any suitable sections in the PKIX draft to put such requirements.
>> 
>> 5.1.9 Physical Security Controls for Registration Authorities
>> A section like this was originally formed by ABA. We know that 
>> physical security for RA:s can be defined in sections 5.1 to 5.8 
>> but it is much easier to define some general exception rules for 
>> RA:s in a section of its own.
>> 
>> 5.2.1.2 Trusted Roles for Registration Authorities
>> This section was formed by the same reason as 5.1.9 above.
>> 
>> 5.3.9 Personal Security Controls for Registration Authorities
>> The same as for 5.1.9
>> 
>> 
>> Could someone comment on this. Have we misunderstood anything.
>> Should we have acted differently or should the PKIX draft be 
>> expanded.
>> 
>> Thank you in advance.
>> 
>> Stefan
>> 
>> 
>> 
>> ----------------------------------------------------------------
>> Stefan Santesson                <[email-masked]>
>> Accurata Systemsäkerhet AB     
>> Lotsgatan 27 D                  Tel. +46-40 152211              
>> 216 42  Malmö                   Fax. +46-40 150790              
>> Sweden                        Mobile +46-70 5247799
>> ----------------------------------------------------------------
>
>
----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

From: Santosh Chokhani <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, [email-masked]
Subject: RE: Comments on draft-ietf-pkix-ipki-part4-03.txt
Date: Thu, 28 May 1998 08:58:17 -0400
Sender: [email-masked]

Please note that the PKIX Part 4 allows for the security controls,
roles, etc. to be defined for the various PKI entities, including
issuing CA, subject CAs, RAs, subscribers, repositories, etc (see
section 4.5 and 4.6 of the framework)

Thus, all of Stefan's inclusions  in Section 5 are within the scope of
the framework.

> -----Original Message-----
> From:	Stefan Santesson [SMTP:[email-masked]]
> Sent:	Wednesday, May 27, 1998 5:48 PM
> To:	[email-masked]
> Subject:	Comments on draft-ietf-pkix-ipki-part4-03.txt
> 
> I'm project leader of a joint Swedish project with the
> purpose to form a certificate policy for a Swedish national 
> "bas-ID" certificate.
> 
> The project is formed by the Swedish non-profit organization
> SEIS (Secured Electronic Information in Society) which is 
> formed by members from Government, Banking, Industry, Military,
> Post and Health care sectors.
> 
> The policy can be obtain from SEIS WWW at:
> 
> http://www.seis.se/regler/normer/S10_v093.doc
> 
> This policy is now ready for official approval on June 16
> by the SEIS board.
> 
> The policy almost follows the structure of
> draft-ietf-pkix-ipki-part4-03.txt 
> We have, however, been forced to expand the structure with the 
> following sections.
> 
> 2.10 Contractual agreements.
> In the policy we state requirements on the CA to establish a 
> number of contractual agreements according to some minimum 
> standards. This is contracts with the subscriber, employer of the 
> subscriber with which the subscriber is affiliated in the 
> certificate, Subcontractors (such as RA:s), etc. We could not find 
> any suitable sections in the PKIX draft to put such requirements.
> 
> 5.1.9 Physical Security Controls for Registration Authorities
> A section like this was originally formed by ABA. We know that 
> physical security for RA:s can be defined in sections 5.1 to 5.8 
> but it is much easier to define some general exception rules for 
> RA:s in a section of its own.
> 
> 5.2.1.2 Trusted Roles for Registration Authorities
> This section was formed by the same reason as 5.1.9 above.
> 
> 5.3.9 Personal Security Controls for Registration Authorities
> The same as for 5.1.9
> 
> 
> Could someone comment on this. Have we misunderstood anything.
> Should we have acted differently or should the PKIX draft be 
> expanded.
> 
> Thank you in advance.
> 
> Stefan
> 
> 
> 
> ----------------------------------------------------------------
> Stefan Santesson                <[email-masked]>
> Accurata Systemsäkerhet AB     
> Lotsgatan 27 D                  Tel. +46-40 152211              
> 216 42  Malmö                   Fax. +46-40 150790              
> Sweden                        Mobile +46-70 5247799
> ----------------------------------------------------------------

Date: Thu, 28 May 1998 04:27:26 -0300 (EST)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: Bud <[email-masked]>
cc: Tony Bartoletti <[email-masked]>, Peter Lipp <[email-masked]>, Carl Ellison <[email-masked]>, E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: RE: [E-CARM] Pseudonyms
Sender: [email-masked]

On Wed, 27 May 1998, Bud wrote:

>> You are aware, perhaps, that dialectic is a non-word... but, I have
>> tried to answer to the best of my abilities. I am sorry if they are
>> less than what you expect and I sure welcome your help!

>Merriam-Webster would disagree - sorry
>

Bud:

It is always amusing to watch "hollier than thou" attitudes -- just
supports my thesis already expressed here: "Funny enough, when
emotions are lacking, we fill them in...perhaps to a larger extent. 
We overshoot the control target, fearing that our voice might not
carry enough strength to the other side!" 

However, there is nothing for you to feel sorry about ;-)

My phrase that "dialectic is a nonword" is:

(i) an inside joke, because in a recent past it was stated in some
lists that "trust is a nonword", as some said: "I dislike the use of
trust because so many meanings have been associated with trust that
trust has lost any possible meaning -- it can be anything you want".
However, paradoxically, I have shown that trust turns out to be ...
the basis for meaning. In other words, trust is that which allows you
to link references to referents. 

(ii) a fact, in some contexts. Just look at Socrates' meaning for it
and then compare with Hegel's. Socrates is pure logic, Hegel is pure
presumption -- as history has shown rather tragically. 

(iii) a teaser, in pure Socratic dialectic.

Cheers,

Ed Gerck

>Main Entry: di·a·lec·tic
>Pronunciation: "dI-&-'lek-tik
>Function: noun
>Etymology: Middle English dialetik, from Middle French dialetique, from
>Latin dialectica, from Greek dialektikE, from feminine of dialektikos of
>conversation, from dialektos
>Date: 14th century
>1 : LOGIC 1a(1)
>2 a : discussion and reasoning by dialogue as a method of intellectual
>investigation; specifically : the Socratic techniques of exposing false
>beliefs and eliciting truth b : the Platonic investigation of the eternal
>ideas
>3 : the logic of fallacy
>4 a : the Hegelian process of change in which a concept or its realization
>passes over into and is preserved and fulfilled by its opposite; also : the
>critical investigation of this process b (1) usually plural but singular or
>plural in construction : development through the stages of thesis,
>antithesis, and synthesis in accordance with the laws of dialectical
>materialism (2) : the investigation of this process (3) : the theoretical
>application of this process especially in the social sciences
>5 usually plural but singular or plural in construction a : any systematic
>reasoning, exposition, or argument that juxtaposes opposed or contradictory
>ideas and usually seeks to resolve their conflict b : an intellectual
>exchange of ideas
>6 : the dialectical tension or opposition between two interacting forces or
>elements
>
>

______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

From: "Bud" <[email-masked]>
To: "Ed Gerck" <[email-masked]>, "Tony Bartoletti" <[email-masked]>
Cc: "Peter Lipp" <[email-masked]>, "Carl Ellison" <[email-masked]>, "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: RE: [E-CARM] Pseudonyms
Date: Wed, 27 May 1998 23:39:09 -0700
Importance: Normal
Sender: [email-masked]

> You are aware, perhaps, that dialectic is a non-word... but, I have
> tried to answer to the best of my abilities. I am sorry if they are
> less than what you expect and I sure welcome your help!
Merriam-Webster would disagree - sorry

Main Entry: di·a·lec·tic
Pronunciation: "dI-&-'lek-tik
Function: noun
Etymology: Middle English dialetik, from Middle French dialetique, from
Latin dialectica, from Greek dialektikE, from feminine of dialektikos of
conversation, from dialektos
Date: 14th century
1 : LOGIC 1a(1)
2 a : discussion and reasoning by dialogue as a method of intellectual
investigation; specifically : the Socratic techniques of exposing false
beliefs and eliciting truth b : the Platonic investigation of the eternal
ideas
3 : the logic of fallacy
4 a : the Hegelian process of change in which a concept or its realization
passes over into and is preserved and fulfilled by its opposite; also : the
critical investigation of this process b (1) usually plural but singular or
plural in construction : development through the stages of thesis,
antithesis, and synthesis in accordance with the laws of dialectical
materialism (2) : the investigation of this process (3) : the theoretical
application of this process especially in the social sciences
5 usually plural but singular or plural in construction a : any systematic
reasoning, exposition, or argument that juxtaposes opposed or contradictory
ideas and usually seeks to resolve their conflict b : an intellectual
exchange of ideas
6 : the dialectical tension or opposition between two interacting forces or
elements

Date: Wed, 27 May 1998 23:08:12 -0300 (EST)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: Tony Bartoletti <[email-masked]>
cc: Peter Lipp <[email-masked]>, Carl Ellison <[email-masked]>, E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: Re: [E-CARM] Pseudonyms
Sender: [email-masked]

On Wed, 27 May 1998, Tony Bartoletti wrote:

>Ed,
>
>Sometimes your helpfulness is diminished by obtuse dialectic;)
>

You are aware, perhaps, that dialectic is a non-word... but, I have
tried to answer to the best of my abilities. I am sorry if they are
less than what you expect and I sure welcome your help!

>You never properly answered Peter Lipp's comparison to the driver's
>license or passport.  Although perhaps more trouble to forge, they
>are also essentially references, where one must trust (a) that the
>paper is not forged, i.e., the "apparent issuer" is indeed the issuer,
>and (b) the issuer is indeed trusted to have established a proper
>assignment of reference to referent.
>

So I answered, to the best of my abiliy, to Peter's question

>
>As the passport is a piece of paper without trust in the issuer.

with:

 I hope not! The US customs service surely must trust the issuer of
 Austrian passports if they are going to rely upon them. 

 You must always trust the issuing service -- otherwise you are
 saying that the cert is just a string of symbols without any sense.
 This is "common misconception #14", a new one on the series:

 Common misconception #14:
 
 A certificate is not magically infused with trust or effectiveness
 just because it is signed. A certificate is trusted because it is
 expected to be correct *and* effective, which trust depends on the
 issuer, the subject, the network, the certificate protocol and all
 other operational assumptions, beliefs and risks -- including the
 verifier's.

Which is in essential agreement with your own terms above: If you
don't trust the issuer (as the argument went) then you can't do
anything with it. But, it does NOT stop there: you must trust the
WHOLE chain of events -- including your own platform and your ability
to verify. 

>The point being, such paper is at heart "not to be relied upon"
>in the pure mathematical sense, and yet we do rely upon it, and
>it works for us "most" of the time.
>

I agree that mathematics is useful as a tool, not as a totem. And, I
also agree that, in that case, semantics (ie, in mathematics) shows
that you have no other reason but trust, to rely upon that paper. 

You can't "measure" it directly, thus you must "measure" it at a
distance -- ie, trust (see the given URL, pls).

>It would be most helpful to offer "OK, your scheme gets you _this_
>much, which is not very far.  Now to get further, one can securely
>assign referents to reference by doing, for instance, X", where "X"
>is devoid of references to an MCG-science-of-meaning and devoid as
>well of pontifications about Frege.
>

Perhaps, Tony. But, I cannot really say how he can solve that, nor
could I say to anyone how that could be done! That would require a
degree of evangelism which, clearly, would only be useful in a small
parish -- and with which I do not intellectually agree.

What I feel is ethical and fine is to say: "Look, what you are saying
does not get you very far and there is really no way out in that
direction. Better and clever people than myself have shown that for
100 years -- so, you can imagine how much more clever they were. Now,
based on my own scientific musings, I have found a way out. If you
want, please take a look at it and decide by yourself. This is a work
in progress and if you think you can contribute with your own $0.02
worth then please do, otherwise please wait while we finish it. 
Thanks." 

Maybe, that's why I am not  a traveling salesman...

>If the existing "trust in references" is flawed, as you plainly argue,
>why not give a reasonable example that demonstrates this flaw, and then
>show, as a point of comparison, the steps that would (in essence) be
>taken in the MCG methodology to obviate the flaw.
>

I think that you have four points here: 

1. The reasonable example that demonstrates "the flaw" is exactly to
be seen when a certificate is used for its face value as may be
"understood" by one person, and not as a reference that may have all
sorts of values to anyone else (even though it is signed). The second
flaw is to think that you are safe when you do that, and even
protected by a supposed issuer-warranty.

2. When a procedure is proved wrong, it is not necessary to show how
to do it right in order to "kill it twice". Procedures are not like
cats...;-) once dead, that is it -- even though they do have a
tendency to be zombies ;-) living their half-dead lives for awhile...

3. The procedures that obviate the flaw have been proved to exist by
myself -- and so published with full detail, which I agree takes a
few pages to explain. It was shown that they need not only intrinsic
information (names, keys, etc) transfer but also intrinsic trust
transfer. Further, they are being developed into a useful set of
protocols which will not be patented (strange as it may seem) but
available to anyone, under copyright protection and worldwide
non-partisan development/distribution by a neutral group (MCG) with
participants from 26 countries.

4. The procedures do break some new ground, specially at the
conceptual level of trust, which needs to be well understood in order
not to fall victim to one's ignorance (ie, mine included).

>After awhile, the seeming inability to offer a concrete "MCG-style"
>counter-example becomes a glaring feature of these discussions.
>

Counter-examples are always offered. For example, UK law that allows
names to be changed at will -- so that no name is less your own than
another. Or, what do you do with a CRL that did not arrive? Or, is
that really ...?

What you mean is perhaps not counter-examples, but a working example.

However, such working examples exist in the given URLs although they
may take a few pages of context. To exemplify an example ;-) see
http://www.mcg.org.br/trustdef.htm#A.4.11

Better yet, to follow-up on it I am preparing a series of short
communications, called "Intrinsic certification at a glance". The
first part was publshed last week and is available at
http://www.mcg.org.br/icert1.htm

I hope that the series will be useful -- again, as I can and within
my own limitations, which are not few perhaps.

Thanks,

Ed

______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

Date: Wed, 27 May 1998 17:04:21 -0700
To: Ed Gerck <[email-masked]>, Peter Lipp <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Cc: Carl Ellison <[email-masked]>, E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Sender: [email-masked]

Ed,

Sometimes your helpfulness is diminished by obtuse dialectic;)

You never properly answered Peter Lipp's comparison to the driver's
license or passport.  Although perhaps more trouble to forge, they
are also essentially references, where one must trust (a) that the
paper is not forged, i.e., the "apparent issuer" is indeed the issuer,
and (b) the issuer is indeed trusted to have established a proper
assignment of reference to referent.

The point being, such paper is at heart "not to be relied upon"
in the pure mathematical sense, and yet we do rely upon it, and
it works for us "most" of the time.

It would be most helpful to offer "OK, your scheme gets you _this_
much, which is not very far.  Now to get further, one can securely
assign referents to reference by doing, for instance, X", where "X"
is devoid of references to an MCG-science-of-meaning and devoid as
well of pontifications about Frege.

If the existing "trust in references" is flawed, as you plainly argue,
why not give a reasonable example that demonstrates this flaw, and then
show, as a point of comparison, the steps that would (in essence) be
taken in the MCG methodology to obviate the flaw.

After awhile, the seeming inability to offer a concrete "MCG-style"
counter-example becomes a glaring feature of these discussions.

___tony___

At 06:16 PM 5/27/98 -0300, Ed Gerck wrote:
>On Wed, 27 May 1998, Peter Lipp wrote:
>
>>>However, isn't there a problem with your privacy laws in having the
>>Austrian
>>>SSN revealed in a public document like a certificate?  I don't know
>>Austrian
>>>laws, but under German law I was told that the national ID number is
>>>protected from being used by non-official entities.
>>Definitely, and I was not intending to promote this. I was just intending to
>>counter
>>the - adding references makes things worse - argument.
>
>and, it just proved otherwise from the point of view of privacy. 
>
>This is due to a corollary to what I have called the CA-paradox, when
>it is viewed by a user as already briefly mentioned. It may be
>interesting to view it under preciser words:
>
> If enough subscriber's privacy-concerned references are provided in
> a public certificate so that a relying-party (eg, the user) can
> consider them "enough" and proceed to verify them independently
> (two known principles in auditing) then the subscriber's privacy
> and independency is jeopardized. However, if such data is denied,
> either in extent or in significance, then the relying-party's
> security and independence suffers.
>
>However, my argument that adding references over references makes
>things worse was just not only based on privacy and is much more
>general (for example, it also works for the relationship between a
>spymaster and spies). My main argument depends on the fact that any
>reference is overly-variable in sense (as Frege showed), which means
>that you cannot define who or what is *the* referent for *a*
>reference just by looking at the reference. If you add more
>references you may be just adding more indeterminacy: 
>  
> Since different observers may assign any number of different 
> referents to the same reference, increasing the number of references
> may increase the total number of possibly assigned referents.
>
>In other words, the problem may diverge with increasing reference
>terms -- not converge. 
>
>Thus, the problem of calculating the average value of a series of
>measurements of a property, which variance is expected to decrease
>with increased terms, is not equivalent to the case at hand (why
>not?).
>
>
>Where is then the link between *the* referent and *a* referent?  Is
>there one? The answer is affirmative and the link can be found, but
>it is NOT to be found in the certificate itself, as discussed in
>http://www.mcg.org.br/trustdef.htm#A.4.3
>
>which opens the discussions with:
>
> However, if we ask the question:  "what is a name in a digital
> certificate?" then we can see that the name is a reference (i.e.,
> Frege's Bedeutung) which can be wholly contained in the certificate
> even down to any desired minute data in any language or form ... and
> thus wholly transferred in the cert -- which corresponds to "a=b" and
> the cert is informational regarding such reference. However, the
> name's sense (i.e., Frege's Sinn or meaning) cannot be contained in
> the certificate at all and cannot thus be transferred.  If it could,
> then the cert would be self-referential to that referent, which is
> not informational and represents "a=a" -- "I am myself". Thus, sense
> cannot even be partially contained in a cert, otherwise that part
> would provide a self-reference to some part of the referent. 
>
>and then proceeds to the requirements to answer the above questions
>and to define the desired link from reference (yes, even one
>reference is enough) to referent.
>
>Cheers,
>
>Ed
> 
>______________________________________________________________________
>Dr.rer.nat. E. Gerck                     [email-masked]
>http://novaware.cps.softex.br
>    --- Meta-Certificate Group member, http://www.mcg.org.br ---
>
>
>

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Wed, 27 May 1998 23:27:26 +0100
To: Nilsson Hans <[email-masked]>, "'Phillip M Hallam-Baker'" <[email-masked]>, [email-masked]
From: "Frank O'Dwyer" <[email-masked]>
Subject: Re: Key Usage
Sender: [email-masked]

At 19:49 27/05/98 +0100, Nilsson Hans wrote:
>(at least not until the private key is kept on
>a smart card, where a new PIN presentation is required by the card OS for
>every private key encryption).

Not even then. For that the smart card would need to have 
a trusted path to its own display and keyboard. Even such
cards would still be too small to display much more than 
payment amounts. (And maybe payee, if you're lucky.) For 
anything more substantial you still wind up trusting the 
OS to present the right data to the card for signature,
and for displaying the right data to the user for 
confirmation.

Smart cards aren't even all that good at keeping secrets,
truth be told.  See Schneier's stuff on 'side-channels'
and Kocher's stuff on timing channels. There was also
some research done on prising secrets out of cards by
inducing faults.

[Apologies for being off-topic here, but I think it's
time we stopped treating smart cards as if they were
the last word in security even though not much
research has been done yet, and already serious 
problems are evident.]

Cheers,
Frank.

Date: Wed, 27 May 1998 23:47:56 +0200
To: <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Comments on draft-ietf-pkix-ipki-part4-03.txt
Sender: [email-masked]

I'm project leader of a joint Swedish project with the
purpose to form a certificate policy for a Swedish national 
"bas-ID" certificate.

The project is formed by the Swedish non-profit organization
SEIS (Secured Electronic Information in Society) which is 
formed by members from Government, Banking, Industry, Military,
Post and Health care sectors.

The policy can be obtain from SEIS WWW at:

http://www.seis.se/regler/normer/S10_v093.doc

This policy is now ready for official approval on June 16
by the SEIS board.

The policy almost follows the structure of draft-ietf-pkix-ipki-part4-03.txt 
We have, however, been forced to expand the structure with the 
following sections.

2.10 Contractual agreements.
In the policy we state requirements on the CA to establish a 
number of contractual agreements according to some minimum 
standards. This is contracts with the subscriber, employer of the 
subscriber with which the subscriber is affiliated in the 
certificate, Subcontractors (such as RA:s), etc. We could not find 
any suitable sections in the PKIX draft to put such requirements.

5.1.9 Physical Security Controls for Registration Authorities
A section like this was originally formed by ABA. We know that 
physical security for RA:s can be defined in sections 5.1 to 5.8 
but it is much easier to define some general exception rules for 
RA:s in a section of its own.

5.2.1.2 Trusted Roles for Registration Authorities
This section was formed by the same reason as 5.1.9 above.

5.3.9 Personal Security Controls for Registration Authorities
The same as for 5.1.9

Could someone comment on this. Have we misunderstood anything.
Should we have acted differently or should the PKIX draft be 
expanded.

Thank you in advance.

Stefan

----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

Date: Wed, 27 May 1998 18:16:54 -0300 (EST)
From: Ed Gerck <[email-masked]>
To: Peter Lipp <[email-masked]>
cc: Carl Ellison <[email-masked]>, E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: Re: [E-CARM] Pseudonyms
Sender: [email-masked]

On Wed, 27 May 1998, Peter Lipp wrote:

>>However, isn't there a problem with your privacy laws in having the
>Austrian
>>SSN revealed in a public document like a certificate?  I don't know
>Austrian
>>laws, but under German law I was told that the national ID number is
>>protected from being used by non-official entities.
>Definitely, and I was not intending to promote this. I was just intending to
>counter
>the - adding references makes things worse - argument.

and, it just proved otherwise from the point of view of privacy. 

This is due to a corollary to what I have called the CA-paradox, when
it is viewed by a user as already briefly mentioned. It may be
interesting to view it under preciser words:

 If enough subscriber's privacy-concerned references are provided in
 a public certificate so that a relying-party (eg, the user) can
 consider them "enough" and proceed to verify them independently
 (two known principles in auditing) then the subscriber's privacy
 and independency is jeopardized. However, if such data is denied,
 either in extent or in significance, then the relying-party's
 security and independence suffers.

However, my argument that adding references over references makes
things worse was just not only based on privacy and is much more
general (for example, it also works for the relationship between a
spymaster and spies). My main argument depends on the fact that any
reference is overly-variable in sense (as Frege showed), which means
that you cannot define who or what is *the* referent for *a*
reference just by looking at the reference. If you add more
references you may be just adding more indeterminacy: 
  
 Since different observers may assign any number of different 
 referents to the same reference, increasing the number of references
 may increase the total number of possibly assigned referents.

In other words, the problem may diverge with increasing reference
terms -- not converge. 

Thus, the problem of calculating the average value of a series of
measurements of a property, which variance is expected to decrease
with increased terms, is not equivalent to the case at hand (why
not?).

Where is then the link between *the* referent and *a* referent?  Is
there one? The answer is affirmative and the link can be found, but
it is NOT to be found in the certificate itself, as discussed in
http://www.mcg.org.br/trustdef.htm#A.4.3

which opens the discussions with:

 However, if we ask the question:  "what is a name in a digital
 certificate?" then we can see that the name is a reference (i.e.,
 Frege's Bedeutung) which can be wholly contained in the certificate
 even down to any desired minute data in any language or form ... and
 thus wholly transferred in the cert -- which corresponds to "a=b" and
 the cert is informational regarding such reference. However, the
 name's sense (i.e., Frege's Sinn or meaning) cannot be contained in
 the certificate at all and cannot thus be transferred.  If it could,
 then the cert would be self-referential to that referent, which is
 not informational and represents "a=a" -- "I am myself". Thus, sense
 cannot even be partially contained in a cert, otherwise that part
 would provide a self-reference to some part of the referent. 

and then proceeds to the requirements to answer the above questions
and to define the desired link from reference (yes, even one
reference is enough) to referent.

Cheers,

Ed
 
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

Date: Wed, 27 May 1998 22:49:20 +0200
To: <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Key Usage for for Authentication and digitalSignature
Sender: [email-masked]

The only problem I have with the PKIX draft is the sentence
Hans Nilsson wrote about:

 "For example, when an RSA key should be used only for signing, 
 the digitalSignature and nonRepudiation bits would be asserted."

This is a bad example which makes people think in wrong directions.

We can't say that "the digitalSignature and nonRepudiation bits 
would be asserted" if we don’t no the purpose of the "signing",
and the example says nothing about that.

I now many people that has drawn wrong conclusions thanks to this
peace of text.

Apart from this I think that the actual definition of the key
usage bits later in the text is very clear.

 "The digitalSignature bit is asserted when the subject public key
 is used to verifying digital signatures that have purposes other
 than non-repudiation"

Bearing this in mind, I think the example above should be changed
to an example which more clearly demonstrates the difference between
the digitalSignature and nonRepudiation bits and also implies that 
the normal case is to have a separate key for nonRepudiation.

Stefan

----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Nilsson Hans" <[email-masked]>, <[email-masked]>
Subject: RE: Key Usage
Date: Wed, 27 May 1998 16:16:19 -0400
Importance: Normal
Sender: [email-masked]

> I think this mess regarding key usage is very much due to the misleading
> writing in X.509. After all, according to my ISO security definitions,
> Digital Signature is a Security Mechanism that can be used to provide the
> three Security Services Authentication, Data Integrity and 
> Non-repudiation.
> This is not at all reflected in the X.509 key usage bits, where most key
> usages are mechanisms, except non-repudiation which is a service.

This is why I am suggesting that this duty should really lie on the 
specifications based on PKIX. That is the point at which the use
issue can be adequately addressed.

In other words Outlook, Communicator and Notes should all agree on the
interpretation of these bits wrt S/MIME. The best way of ensuring this
is for the S/MIME spec to explicitly state what key usages are and
are not acceptable for each purpose.

The alternative of having each S/MIME implementor interpret PKIX for
themselves opens up precisely the problem you suggest. Same for the
various other standards.

		Phill

Date: Wed, 27 May 1998 16:50:14 -0300 (EST)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: Peter Lipp <[email-masked]>
cc: E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: Misconceptions #14, #15, was Re: [E-CARM] Pseudonyms
Sender: [email-masked]

On Wed, 27 May 1998, Peter Lipp wrote:

> Ed Gerck wrote:
>
>>This means that CAs (for good and
>>valid reasons, basically pertaining to lack of adequate trust on the
>>subscriber's declarations) explicitly exclude any warranty, assurance
>>or liability for the *data* contained in supplied certs -- except
>>data generated by the CA itself (eg, the cert signature).
>
>For simplicity, I assume the propsed European Proposal was valid (and
>this was one of the reasons for me asking). It sais:

Peter:

In all fairness, I will try to summ up some issues already discussed
and you will see that the Guidelines you mention do not go very far. 

Before I show that, let me ask: do we need more law or less law? 
Clearly, we share the same global network ...but a global law does
not seem to be praticable and fair to all. 

Now, what would happen if the EC and everyone just recognizes what is
plain to see and finally decide to make it clear, in clear language,
in what I might call the "FAIR CPS":

FAIR CPS:

 Certificates are secure references signed by someone. If you rely 
 upon that someone to have at least the competence and good-will
 to sign it in a secure way, then you can use those references as
 if they were tamper-proof for all practical purposes. What you do
 with them is up to you. If that someone wants, you may have to pay
 for those references but, be warned, they are still references.

To fraudsters and hackers, the situation would not change with the
above declaration. But it has much improved to the public, since they
at least know what they have in their hands; they may indeed trust
the issuer to provide tamperproof references that they can use at
their own risk -- as it is today anyway. However, if it ends in blue
smoke, "OK -- I was not sure and I just risked $50.00 anyway". 

So, we see that "truth in Engineering" pays off.

And, as technology progresses, we keep working to really solve the
problem -- not just shove it ;-)

But, the proof of the pudding is on the eating -- so let me show you
what is being shoved nowadays... 

>
>>>Liability
>>>
>>>1. Member States shall ensure that by issuing a qualified certificate,
>>>a certification service provider is liable to any person who reasonably
>>>relies on the certificate for:
>>>
>>>(a) accuracy of all information in the qualified certificate as of the
>date
>>>it was issued, unless the certification service provider has stated
>>>otherwise in the certificate;

This does not take you very far... it just takes you to the next day!

It also exemplifies the about-face attitude of some legislation: 
they seem to provide a solution but when you get close to it such
solution is a mirage ...  that disapears.

If you were a technology based firm, specificaly dealing with
Internet/computer security, would you guarantee anything? With the
over-abundance of lawyers in the US alone, and the growing attitude
of "I got burned by being stupid so someone else needs to be
punished" it would be suicidal to guarantee much of anything. Even
organizations like the WheelGroup, who charge as much as $75,000 for
site security evaluations, don't guarantee anything ....  they just
make it harder to get in. To quote one of their employees, "The only
secure computer is one that's turned off, locked in a safe, and
buried 20 feet down in a secret location - and I'm not completely
confident of that one either".

So, CAs -- in order to be a viable business -- cannot guarantee what
they cannot verify for sure.. and even if they can verify if your
passport is indeed correct (in which assessment the US Customs
acknowledges that it also errs), they cannot say if you are really
the person named in that passport, for example, or if you had the
right to use the birth certificate that allowed that passport to be
issued and so on...

Which takes us to common misconception #12 (pls see archives): 

 CAs are supposed to be legally responsible for subscriber's data
 verification in certificates. However: (i) CAs MUST verify only to
 the extent of X.509, which only mandates public-key verification;
 (ii) CAs MAY verify only to the extent of their particular CPS and
 certificate class; and (iii) CAs CAN verify only to the extent that
 the subscriber provides them with all data that the CA may feel
 needed, according to the CA's independent and unemcumbered
 requirements, without any privacy limit arguments, IF such data
 was supplied without fraud and WITH a valid communication. 

I call attention to three perhaps subtle points above:

- "MAY": The verb "MAY" was used in the CPS case to signify that such
verification is defined by the CA in the CA's own terms, which MAY
not express what anyone else feels should be verified or expressed,
inlcuding you.

- "IF": The conditional "IF" is used in the verification of personal
data because a CA cannot be held responsible if a CA accepts an ID
that looks like an ID, quacks like an ID and walks like an ID (to use
a popular metaphor often quoted here). Even public officials are
fooled by physical false entrance vistas all around the world, daily
(this is public knowledge), so a CA cannot be required to do more -- 
they are also subject to the benefits of the law!.

- "WITH": Clearly, anything that the CA may verify depends on the
absence of viruses, hacker attacks and fraud. Even the US Pentagon
cannot declare its computers safe from hackers, so CAs cannot be
expected to be above that -- as everyone knows and is public
knowledge. 

Thus, your first point above is answered in the negative -- with
full justification -- technically, legally and litigationwise. 

>>> .....
>>>    2. Member States shall ensure that a certification service provider is
>>>not liable for errors in the information in the qualified certificate that
>has
>>>been provided by the person to whom the certificate is issued, if it can
>>>demonstrate that it has taken all reasonably practicable measures to
>>>verify that information.
>

;-) The law also agrees that it can't push the technology envelope!
This is a further about-face attitude -- which shows that paragraph
#1 was a nice Gendakenexperiment but nothing else when you try to
reach for the liabilities.

Think of it for a moment. CAs cannot be held responsible for what
they can't verify. And they can'y verify what you don't give them,
what someone may fraud them into believing and what networks may
infect them with.  In all three cases, YOU are in for the problem and
they are out of the liability. 

Anything else is for the moot courts. 

>Any CA working under these guidelines will have to provide some warranty.

In the US and in other countries, the conditions for the provision of
information processing services (ie, CAs) are similar to the ones
being discussed for the UCC (Uniform Commercial Code), which
specifies that "for data processing and design or consultation work,
the basic focus for gauging liability centers on the process, rather
than on a guaranty of correct result". 

Thus, sure. I entirely agree that, certainly, a CA is responsible for
upholding the practices disclosed in its CPS, which cover several
issues and includes correct use of cryptography.

For example, if the CPS undertakes a CA to have the correctness of
its use of cryptography audited, then the CA is responsible for this
act of auditing, and meeting the performance standards.

However, the "relying party" is unlikely to get any guaranty of
correctness of audit result from the auditing party. It will receive
a recommendation, or "assurance", in all probablity. 

This is the spirit of the law: information processing works with
references which cannot be properly measured with "certainty" --
unlike a kilogram of gold in a Bank, which must **exactly** weigh 1.0
Kg within the applicable standard for measuring gold for finnancial
purposes.

However, there is a further point here, also already discussed. This
is common misconception #4. Contract Liability to Users: Zero.

 Since the certificate's users (ie, historically known as the
 relying-parties) are not the ones that paid for the certificate to
 the CA (ie, the certificate was paid for by the subscriber), this
 means that the CA has no responsiblity or contractual obligation
 whatsoever to the certificate's users, hence zero liability. 

What does this mean? That user must also pay attention to "common
misconception #10": 

  CAs have subscribers and users. Users have no contract to
  CAs and are specifically excluded from any warranty or liability
  by commercial CAs very well-written an public CPSs -- even though
  users are called "relying-parties" in such CPSs. However, users
  must understand that they are a "relying-party"  of their own due
  dilligence.

Clearly, all users are excluded from any EC Guidelines because the
CAs can legally negate that and it would be suicidal to do otherwise. 
The few CA warranties apply to subscribers, not users.

However, who needs to rely upon a certificate? The user.

>
>>Thus, without trust on the issuer *and* (often forgotten) on the
>>subscriber a certificate is just a bag of bytes sent over the wire
>>and which has no meaning by itself -- which is "common misconception
>>#2", already cited:
>
>As the passport is a piece of paper without trust in the issuer.

I hope not! The US customs service surely must trust the issuer of
Austrian passports if they are going to rely upon them. 

You must always trust the issuing service -- otherwise you are saying
that the cert is just a string of symbols without any sense.
This is "common misconception #14", a new one on the series:

Common misconception #14:
 
 A certificate is not magically infused with trust or effectiveness
 just because it is signed. A certificate is trusted because it is
 expected to be correct *and* effective, which trust depends on the
 issuer, the subject, the network, the certificate protocol and all
 other operational assumptions, beliefs and risks -- including the
 verifier's.

> Nothing new here. 

Indeed, they are rather common misconceptions and can be frequently
found -- that's why I published the "Overview of Certification
Systems"  paper and that is why I am numbering this series, to
simplify future references to them. 

In that regard, I presume that governments are correct when they try
to legislate on certificates and digital signatures -- because the
public is indeed at risk (eg, the "biscotti paradigm"). However, they
miss the mark when they try to legislate based on *assumptions* and
not on fact. However often repeated, assumptions remain assumptions.

To quote a message from Ben Wright on another forum:

<quote>

I have a question about one aspect of the Paper.  Under Part 2
Evidence, the Paper avers that "currently only digital signature
technology meets the test of a secure electronic signature . . ." 
What is the real-world basis for that conclusion?  Have you
investigated any operational systems that in fact (not just in
theory) demonstrate all of the requirements of a digital system that
leads to an effective legal signature?  

...[snip]

The reason I ask this question is that I have not been able to
confirm that such a system exists.  If it does exist, I suspect that
it lives in a very limited and controlled environment, among highly
sophisticated parties.  I believe that anyone who diligently works
through this question will conclude that it is not easy to say that
"digital signature meets the test of a secure electronic signature." 
Experience shows that it is a real challenge -- maybe to the point of
impracticality -- to pay for and implement all the required features. 

</quote>

>
>> non-cryptographic meaning of each of its atomic parts -- for each of
>> the names that it may contain, such as common names, keys, hashes,
>> etc.
>
>Same thing as for passports. The only difference is that latter have been
>used
>for a while, and certificates are something people are not used to.
>

My statement has nothing to do with certs -- just with the data in
the certs. Surely, you trust the cert issuer and then you know that
the signature is secure (eg, the issuer keeps its private-keyt safe)
but you can't say a yod about the data in the cer that came from the
user because the *same* trusted issuer told you that it provides no
assurances, no liablities and no warranties on them. So, in the same
way that you trusted its key you should trust its lack of reliance on
the user's data in the cert, no?

>>2. each of the data sources for each data fields contained in the
>>cert -- including the CA *and* the subscriber.
>As the passport is based on a birth certificate which is based on
>a statement by some doctor that a child actually exists .... but you
>(or the officers at some border) still accept the passport .....
>

;-) as a reference is based on a reference, which is based on another
reference, and so on... then you must trust it?

This is common misconception #15 (a new one in the series):

 That the US INS accepts UK birth (naming) certificates in order to
 certify immigration status for its own policy of regulation, does not
 mean that the INS is acting to "confirm" the legitimacy of the name,
 or organise the UK namespace. So, the conclusion is that acceptance
 of a document by a recipient does not make the information in the
 document more veritable to others ...  though it is often interpreted
 so, especially when a third document is issued by the recipient and
 publicly known. Sure, there is a bar on the standard of the {UK,...}
 authorities who the INS respects sufficiently for its own activities.
 But INS confirmation (or rather "use") confers no status on the
 original document unless the INS policy wished to make such
 representation explicit -- which CAs explicitly deny.

>>The basic misconception here is to think that CAs warrant or
>>"endorse" the data that they copy in a cert -- they do not.

>Ed, what I am not sure (not having had the time to read all your
>contributions) is what you are aiming at. Claiming that CA's don't
>warrant anything - which might or might not be true today -seems to aim
>at making the concepts of CA's per se invalid, but I don't see what
>you are up to.
>

Contrary to some CA detractors ;-) I basically confirm that CAs are a
mechanism to provide for secure references. However, what is "secure"
and what is "references"? What are their meanings as the CA
understands them and as subscribers *and* users must either accept or
reject but never change?

The full report is in  http://www.mcg.org.br/cert.htm paper and a
summary is available in the E-CARM (and other, such as mcg-talk)
archives under "RE: Is there a business for CAs? Yes!".

To make it even shorter, it all hinges basically upon the difference
between what a user may expect versus what is actually legally
warranted in the full CA/subscriber/user relationship. 

Clearly, for any CA the majority of relationships is, albeit
indirectly, defined by CA/user. The number of CA/subscriber cases is
much smaller. This highlights the importance of this issue, since
users are also the ones that must primarily weigh potential losses.

Further, it is also clear that users may hold the subscribers to be
responsible. However, as a function also of the same issues -- if the
subscriber publicly denies any liability to anyone in the world, then
a user may also have only its own due dilligence to rely upon.  

The CA/user and CA/subscriber relationships are governed by that CA
CPS -- which is legally included in the cert's "four corners" by
documental reference. What do CPSs in general say about such
relationships? A CPS does not say that CA X has no warranty on its
services or that it does not take any liability on them. It only says
that CA X has no warranties and accepts no liability for services
that CA X does not recognize it provides.

Clear, clever and effective.

The fact that CA X does not provide what perhaps the majority may
think they provide (eg, you) is another point altogether. The
solution is, perhaps, much more to educate the majority than to
expect a company to do what is technically unfeasible in X.509 terms.

Thus, I have often expressed the opinion that CAs' CPSs are not at
all at odds with X.509 or legislation and that for any generic
CA one might expect a similar reasoning. 

Indeed, if the only thing that a CA does (as per X.509) is to
challenge the subscriber's private-key in order to bind the
corresponding public-key with the subscriber's DN and, if it signs
the certificate with a CPS that says that any other data are being
copied as received but have not been verified (and have thus no
warranty) then the CA has no responsibility for the contents of the
certificate -- save the positive acknowledgement that the public-key
did have a counterpart when it was linked to that DN (where the CPS
could further provide exceptions for frauds, virus, MITM attacks,
etc.

Here, my suggestion is thus perhaps made more plausible: Use the
"FAIR CPS" wording (given above, at the top of this msg) and do not
try to use about-face attitudes which will just create a sense of
false security in the public and which will actually only increase
the security of fraudsters and hackers.

>>References (ie, names) cannot convey meaning. For example, suppose I
>>would write that I am sending a Gift to you? Is that a present (as
>>written in the US) or a poison (as read in Austria)?
>This depends. If you include in an extension that you are using the english
>or german language, this becomes much better. If a certificate would contain
>a universially accepted unique identifier, this would make things easier.
>Sure,
>I know that lot's of Peter Lipp's exist, so the individual corresponding to
>this
>name (which is the meaning of the name) is not clearly defined by Peter Lipp
>alone. What else is new? Does this make the concept of certificates invalid?
>

A certificate is only valid as a secure transport for references --
which have no sense per se. The concept of certificates being
meaningful or trusted per se is what is invalid (see CM #14, above).

Let us think of it. What travels over the wire? Bytes. What do these
bytes mean? They are simply uninterpreted strings of symbols.
What can an observer (eg, you) say about the meaning of these
bytes? That depends on "what body of knowledge do you rely upon to
interpret them" -- which is called trust:

"Trust is that which an observer can rely upon to some known extent
in regard to a subject matter", see Webster for example. 

Thus, without trust on the issuer you cannot assign meaning to the
cert's signature and, thus, cannot even verify the cert's signature
(and, thereby, its authenticity). Without trust on the subject you
cannot assign meaning to the cert data either.

So, a cert is a secure reference. This is valid. Anything else is
interpretation by you, based on that which you trust -- which may be
valid or not and which warrants a quantitative treatment, not simply
"I trust".

>>So, the conclusion may be that while it is bad to try to use
>>references to convey meaning, it is worse to use even more references
>>to try "harder"....
>I dont see that. If the certificate adds another reference, like my austrian
>social security number, this might make the reference unique, but might
>not help the user of the certificate resolve his problems, agreed. It might,
>e.g. if the user is actually able to use that information, like an Austrian
>doctor
>or our social security services. What does this mean? Not every certificate
>is equally useable for all purposes. Nothing new, I suppose.
>

First, a large number of references does not increase security --
references have no meaning, no sense by themselves. They are only
good as bags of bytes. "What do they mean?" is the question -- which
answer is NOT to be found in the references themselves --as Frege
pointed out and proved in 1910, when what we call modern semantics
was born. Please see my comments on that, above and my already given
URL on the subject. So, indeed, there is nothing new on this
subject -- since 1910 ;-)

Further, this is a bit into common misconception #12, already
mentioned above -- thus it is indeed not new, it is rather common. It
hinges on the basic paradox that if a CA is allowed to plunge into
your records everywhere so as to be able to verify your information,
then your privacy suffers -- BUT, if the CA is denied such means (eg,
yopur Austrian SSN, full name and address) then they can't act as
independent verifiers and your security will suffer. 

Thus, with the X.509/CA system you have a "choice": either privacy or
security. You can't have both.., so, you can't demand privacy and
then sue for lack of security! 

There is also corollary to the above CA paradox. How can you (a CA
user) rely on B's cert (ie, B is a CA subscriber)  if you cannot
verify who B is? Thus, the corollary is:
 
if you (ie, you are a user that needs to verify B's CA cert, as the
CA CPS says users must do) have the pointers and are allowed to
plunge into B's records everywhere so as to be able to verify if the
information contained in B's cert is correct (as you, users, must
do), then B's privacy suffers -- BUT, if you are are denied such
means (eg, B's Date-of-Birth, full name and address) by B then you
can't verify B's data and your security will suffer. 

So, the CA user also has a "choice" with the X.509/CA system:  either
the user respects the other party's need for privacy or his security
will suffer. You can't have both.., so, you can't accept his privacy
and then sue for lack of your security! 

>I believe that there is no such thing as the general certificate that is a
>catch all.

Amen!

In that note of agreement I am happy to close this message!

Cheers,

Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

From: Nilsson Hans <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>, [email-masked]
Subject: Re: Key Usage
Date: Wed, 27 May 1998 19:49:45 +0100
Sender: [email-masked]

Phill,

We do not want to "stop the user from hurting himself" by separating
non-repudiation from everything else. We want to stop the user from hurting
a Relying Party by later denying his signature (as a non-native English
person, this is what I understand non-repudiation means).

What I guess we want to do, as in all countries where they are trying to
make digital signatures binding in court, is to take away any possible
loophole that gives the signer a chance to later say: "I did not sign that
document willfully". That is why we want to restrict the usage of the key as
much as possible. But I guess he always has a loophole available by saying:
"There must have been some malicous software in my PC that signed the hash,
while the key was open for usage. After all, Windows95 is not C2-level". It
may just be like fixing one small hole, when there is another large one
nearby which can not be fixed (at least not until the private key is kept on
a smart card, where a new PIN presentation is required by the card OS for
every private key encryption).

I think this mess regarding key usage is very much due to the misleading
writing in X.509. After all, according to my ISO security definitions,
Digital Signature is a Security Mechanism that can be used to provide the
three Security Services Authentication, Data Integrity and Non-repudiation.
This is not at all reflected in the X.509 key usage bits, where most key
usages are mechanisms, except non-repudiation which is a service.

I think there is a great need for common interpretation of what the key
usages "digital signature" and "non-repudiation" REALLY mean. So far, every
project or standardization body has its own.

Hans

> -----Ursprungligt meddelande-----
> Från:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Skickat:	 den 27 maj 1998 18:28
> Till:	David P. Kemp; [email-masked]
> Ämne:	RE: Key Usage for for Authentication and digitalSignature
> 
> I agree up to the point where David states:
> 
> > It is highly unlikely that any specific piece of software is both
> > dumb enough to sign data presented to it and smart enough to understand
> > and enforce the keyUsage extension.  It is also impossible to prevent
> > the same key from being certified twice, once for each keyUsage bit.
> > Therefore, I don't believe that the proposed restriction on keyUsage
> > bit combinations is warranted.
> 
> I think it very likely. I would put the probability at very close to
> 1 in fact. I just don't know of anything that can be done to prevent it. 
> 
> I think the wider problem lies in the signing infrastructure. Rather
> than attempt to tag the key as 'nonRepudiation', the _usage_ should
> be tagged in that manner. After all there are limits to the extent 
> to which non repudiation is established in a given protocol.
> 
> For example consider the case in which two parties want to communicate
> in such a manner that the FACT of a communication could not be 
> repudiated but the CONTENT could be. This is effectively what is 
> established in a perfect forward secrecy protocol in which the parties
> exchange signed DH keysets to establish a secure channel.
> 
> To what extent is such residual non-repudiation of data to be
> prohibited? Come to that what key usage bits would be appropriate
> for this particular case? I would see the application as being 
> principally a digitalSignature one but if someone was being overly
> picky it is perhaps arguable that there is an element of nonRepudiation.
> 
> 
> Given these constraints the current regime in which the user is told
> what they can do with a particular key seems the best approach. I
> don't think it is very productive to try to specify restrictions to
> stop the user from hurting themselves. After all we do not insist on
> separating encryption from signing. It seems odd therefore to start
> insisting on a separation between non-repudiation and authentication only.
> 
> 
> Rather than attempt to discuss the gory details of this issue in
> terms of abstract, hypothetical protocols how about putting a
> responsibility on protocols relying on the specification to
> state the required key usage bits for each operation?
> 
> How about a 'relying specification requirements' section that
> would list this and any other constraint which we would wish to 
> place on a relying spec such as S/MIME, IPSEC etc??
> 
> 		Phill

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: RE: Key Usage for for Authentication and digitalSignature
Date: Wed, 27 May 1998 13:27:59 -0400
Importance: Normal
Sender: [email-masked]

I agree up to the point where David states:

> It is highly unlikely that any specific piece of software is both
> dumb enough to sign data presented to it and smart enough to understand
> and enforce the keyUsage extension.  It is also impossible to prevent
> the same key from being certified twice, once for each keyUsage bit.
> Therefore, I don't believe that the proposed restriction on keyUsage
> bit combinations is warranted.

I think it very likely. I would put the probability at very close to
1 in fact. I just don't know of anything that can be done to prevent it. 

I think the wider problem lies in the signing infrastructure. Rather
than attempt to tag the key as 'nonRepudiation', the _usage_ should
be tagged in that manner. After all there are limits to the extent 
to which non repudiation is established in a given protocol.

For example consider the case in which two parties want to communicate
in such a manner that the FACT of a communication could not be 
repudiated but the CONTENT could be. This is effectively what is 
established in a perfect forward secrecy protocol in which the parties
exchange signed DH keysets to establish a secure channel.

To what extent is such residual non-repudiation of data to be
prohibited? Come to that what key usage bits would be appropriate
for this particular case? I would see the application as being 
principally a digitalSignature one but if someone was being overly
picky it is perhaps arguable that there is an element of nonRepudiation.

Given these constraints the current regime in which the user is told
what they can do with a particular key seems the best approach. I
don't think it is very productive to try to specify restrictions to
stop the user from hurting themselves. After all we do not insist on
separating encryption from signing. It seems odd therefore to start
insisting on a separation between non-repudiation and authentication only.

Rather than attempt to discuss the gory details of this issue in
terms of abstract, hypothetical protocols how about putting a
responsibility on protocols relying on the specification to
state the required key usage bits for each operation?

How about a 'relying specification requirements' section that
would list this and any other constraint which we would wish to 
place on a relying spec such as S/MIME, IPSEC etc??

		Phill

From: Ingmar Camphausen <[email-masked]>
Date: Wed, 27 May 98 18:33:08 +0200
To: [email-masked]
Subject: AuthorityInfoAccess extension revisited
Reply-To: [email-masked]
Organization: GMD - German National Research Center for Information Technology
Sender: [email-masked]

I had made the following remarks re draft-ietf-pkix-ipki-part1-06. As  
the typo has not been fixed in part1-07, and the other text remained  
unchanged as well, I guess they have been overlooked or the mail did not  
reach the list, so I'll have another try:

To sum it up, it seems to me as if in draft-ietf-pkix-ipki-part1-07, the  
entire section 4.2.2 is not consistent in itself with regard to the  
changes that were made within that section during the different drafts.

For me, this is obvious from the numbering, where there is a subsection  
4.2.2.1 but no further subsection 4.2.2.2 (hence making it unnecessary to  
insert a *sub*section 4.2.2.1, IMHO).

Furthermore, something else supports that impression that 4.2.2 is  
somewhat "out of sync": The first paragraph of 4.2.2 reads

   "[...] As the information may be available in multiple forms, each
   extension is a sequence of IA5String values, each of which represents
   a URI. [...]"

This may have been in line with the definition of `authorityInfo' in  
draft version 4 of part 1 which defined it as

   AuthorityInfoAccessSyntax  ::=  SEQUENCE  {
        authorityInfo     [0] SEQUENCE OF GeneralName OPTIONAL,
        certStatus        [1] SEQUENCE OF GeneralName OPTIONAL }

but this was replaced (in part 1 draft #5) by the more generic

   AuthorityInfoAccessSyntax  ::=
           SEQUENCE SIZE (1..MAX) OF AccessDescription

   AccessDescription  ::=  SEQUENCE {
           accessMethod          OBJECT IDENTIFIER,
           accessLocation        GeneralName  }

For that (recent) definition, the sentence "each extension is a sequence  
of IA5String values" quoted above from 4.2.2 seems inadequate to me, as  
it obviously refers to the *outdated* definition of  
AuthorityInfoAccessSyntax.

The end of section 4.2.2.1 (Authority Information Access) on page
37 describes how a pathname for certificate retrieval via URI-based
services might (should?) be constructed:

  "Other parts of the PKIX specifications [PKIXOCSP] [PKIXLDAP]
   establish requirements on certificate retrieval mechanisms. It is
   expected that applications using the URI form of the authorityInfo
   field for such a purpose will:

   1.  Prepend a suitable HTTP retrieval primitive to the URL (e.g.
   "GET").

   2.  Append a filename to the URL.

   3.  Use the result to retrieve a file containing the requested
   certificate.
   [...]"

(1) IMHO, this is somewhat too fixed on HTTP as transport service. As  
the URI form is not limited to HTTP URLs but might also include FTP, LDAP  
etc., I would like to suggest a more generic description like

  "... It is expected that applications using the URI form of the
   authorityInfo field for such a purpose will:

   1.  Prepend a suitable retrieval primitive to the URI (e.g.
   "GET" in the case of an HTTP URL).

   2.  Append a filename to the URI.

   3.  Use the result to retrieve a file containing the requested
   certificate.
   ..."

BTW: Shouldn't the words `authorityInfo field' from the second sentence
of the quoted section rather read `accessLocation field'? (This, too,  
seems to stem from the old definition of AuthorityInfoAccessSyntax, as  
mentioned above.)

(2) 4.2.2.1 continues:

  "[...]
   3.  Use the result to retrieve a file containing the requested
   certificate.

   4.  Use the authorityInfoAccess extension in that and subsequent
   certificates to complete a certificate path.

   The filename will be formed as the IA5string representation of
   SHA1(Issuer DN | certificate serial number) concatenated with ".cer."
   The IA5String representation will display the SHA1 result as a
   hexidecimal number using digits and the lowercase letters 'a' through
   'f.'  The SignerInfo syntax of PKCS 7 provides the necessary
   information as issuerAndSerialNumber.

   The specified file will contain a single DER encoded certficate."

[...hexadecimal...]
       =

Does that apply to *all* URI access methods, including FTP, or only to
HTTP as retrieval protocol? (Or was the complete section only related to
the situation where it is a *PKCS#7 message* one has to deal with?)

--
Ingmar Camphausen   [email-masked]   PGP key on server
GMD FOKUS  =  Research Institute for Open Communication Systems
++49.30.3463-7357  *  Kaiserin-Augusta-Allee 31, D-10589 Berlin

Date: Wed, 27 May 1998 11:35:19 -0400
To: [email-masked]
From: "David M. Balenson" <[email-masked]>
Subject: CFP: 1999 Network & Distributed System Security Symposium (NDSS '99)
Cc: [email-masked]
Sender: [email-masked]

--=====================_896297719==_
Content-Type: text/plain; charset="us-ascii"

--=====================_896297719==_
Content-Type: text/plain; charset="us-ascii"

	    C  A  L  L       F  O  R       P  A  P  E  R  S

			  The Internet Society
	1999 Network and Distributed System Security Symposium
			       (NDSS'99)

Where: Catamaran Resort, San Diego, California
When: February 3-5, 1999

GOAL: The symposium will foster information exchange among hardware and
  software developers of network and distributed system security
  services.  The intended audience includes those who are interested in
  the practical aspects of network and distributed system security,
  focusing on actual system design and implementation, rather than
  theory.  A major goal of the symposium is to encourage and enable the
  Internet community to apply, deploy, and advance the state of
  available security technology.  The proceedings of the symposium will
  be published by the Internet Society.

  Topics for the symposium include, but are not limited to, the
  following:

* Security in malleable systems: mobile code, mobile agents, active
  networks, dynamic policy updates, etc.
* Special problems: e.g. interplay between security goals and other
  goals such as efficiency, usability, reliability, interoperability,
  resource sharing, and cost.
* Integrating security services with system and application security
  facilities and with application protocols, including message handling,
  file transport, remote file access,  directories, time synchronization,
  data base management, routing, voice and video multicast, network
  management, boot services, and mobile computing.
* Fundamental services:  authentication, integrity, confidentiality,
  authorization, non-repudiation, and availability.
* Supporting mechanisms and APIs: key management and certification
  infrastructures, audit, and intrusion detection.
* Telecommunications security, especially for emerging technologies --
  very large systems, e.g., the Internet, high-speed systems, e.g., the
  gigabit testbeds, wireless systems, personal communication systems,
  and large-scale, heterogeneous distributed systems.

* Controls: firewalls, packet filters, application gateways
* Object security and security objects
* Network information resources and tools such as World Wide Web (WWW),
  Gopher, archie, and WAIS.
* Electronic commerce: payment services, fee-for-access, EDI, notary
  services; endorsement, licensing, bonding, and other forms of
  assurance; rights management and other forms of intellectual property
  protection
* Implementation and management of network security policy 
* Security for voice over IP
* Security for routing

GENERAL CHAIR:
  Stephen Welke, Trusted Computer Solutions

PROGRAM CHAIRS:
  Stephen Kent, BBN Technologies
  Gene Tsudik, USC/Information Sciences Institute

TUTORIAL CHAIR:
  Doug Maughan, National Security Agency

PROGRAM COMMITTEE:
  David Balenson, TIS Labs at Network Associates
  Steve Bellovin, AT&T Labs -- Research
  Matt Bishop, University of California at Davis
  Bob Blakley, IBM
  Doug Engert, Argonne National Laboratories
  Warwick Ford, VeriSign
  Li Gong, Sun Microsystems
  Rich Graveman, Bellcore
  Ari Juels, RSA Laboratories
  Tom Longstaff, CERT
  Doug Maughan, National Security Agency
  Dan Nessett, 3Com Corporation
  Michael Roe, Cambridge University
  Jeffrey Schiller, MIT
  Wolfgang Schneider, GMD Darmstadt
  Christoph Schuba, Purdue University
  Win Treese, Open Market
  Jonathan Trostle, Cisco

LOCAL ARRANGEMENTS CHAIR:
  Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
  John Kochmar, SEI

PUBLICITY CHAIR:
  David Balenson, TIS Labs at Network Associates

LOGISTICS CHAIR:
  Carla Rosenfeld, Internet Society

REGISTRATIONS CHAIR
  Beth Strait, Internet Society

SUBMISSIONS: The committee invites technical papers and panel proposals,
  for topics of technical and general interest.  Technical papers should
  be 10-20 pages in length.  Panel proposals should be two pages and
  should describe the topic, identify the panel chair, explain the
  format of the panel, and list three to four potential panelists.
  Technical papers will appear in the proceedings.  A description of
  each panel will appear in the proceedings, and may at the discretion
  of the panel chair, include written position statements from each
  panelist.

  Each submission must contain a separate title page with the type of
  submission (paper or panel), the title or topic, the names of the
  author(s), organizational affiliation(s), telephone and FAX numbers,
  postal addresses, Internet electronic mail addresses, and must list a
  single point of contact if more than one author.  The names of authors,
  affiliations, and other identifying information should appear only on
  the separate title page.

  Submissions must be received by 31 July 1998, and must be made via
  electronic mail in either PostScript or ASCII format.  If the
  committee is unable to print a PostScript submission, it will be
  returned and hardcopy requested.  Therefore, PostScript submissions
  must arrive well before 31 July.

  All submissions and program related correspondence (only) should be
  directed to the program chair:  
	Stephen Kent
	c/o BBN Technologies
	70 Fawcett Street
	Cambridge, Mass. 02138
	Email:[email-masked]
	Phone: +1 (617) 873-1996
	FAX: +1 (617) 873-4086

  Dates, final call for papers, advance program, and registration
  information will be available at the URL: http://www.isoc.org/ndss99.

  Each submission will be acknowledged by e-mail.  If acknowledgment is
  not received within seven days, please contact the program chair as
  indicated above.  Authors and panelists will be notified of acceptance
  by 18 September 1998.  Instructions for preparing camera-ready copy
  for the proceedings will be sent at that time.  The camera-ready copy
  must be received by 16 October 1998.

--=====================_896297719==_
Content-Type: text/plain; charset="us-ascii"

----------------------------------------------------------------------------
David M. Balenson, Publicity Chair, NDSS '99
TIS Labs at Network Associates, Inc.
3060 Washington Road, Glenwood, MD 21738  USA
[email-masked]; 301-854-5358; fax 301-854-5363
--=====================_896297719==_--

Date: Tue, 26 May 1998 13:01:09 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Key Usage for for Authentication and digitalSignature
Sender: [email-masked]

> From: Nilsson Hans <[email-masked]>
> 
> Because of this threat, we have in Sweden come to the conclusion that the
> nonRepudiation usage bit never may be combined with any other key usage. Is
> this correct (and PKIX-part1-07 wrong), or have we misunderstood something
> along the way?

There are two ways to protect against the described scenario:

  1) Clients never blindly sign a value sent by another party, or

  2) Clients always understand and enforce the keyUsage extension,
     CAs always mark the extension as critical, and the nonRepudiation
     bit is not set in combination with other bits.

For the particular case of TLS (SSL) client authentication, the client
does not sign a hash value sent by the server.  Instead, the
certificate verify message is a signature over all prior handshake
messages which have occurred in the the current handshake exchange -
this includes both random and predictable data generated by both the
server and the client.

For the general (non-TLS) case, a hypothetical authentication protocol
is BROKEN if it specifies that the server sends a value and the client
signs it!

It is highly unlikely that any specific piece of software is both
dumb enough to sign data presented to it and smart enough to understand
and enforce the keyUsage extension.  It is also impossible to prevent
the same key from being certified twice, once for each keyUsage bit.
Therefore, I don't believe that the proposed restriction on keyUsage
bit combinations is warranted.

NOTE:  I agree that it is highly desirable for CAs to use separate keys
for nonRepudiation and other purposes.  But that is a matter of policy,
not something which the PKIX profile can mandate.

From: "Peter Lipp" <[email-masked]>
To: <[email-masked]>, "Stefan Santesson" <[email-masked]>
Subject: Re: CRL issuing
Date: Wed, 27 May 1998 16:13:32 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00B0_01BD898A.648E4720
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>The CA is by this procedure linked to the CRL by certifying the
>public key with which the CRL can be checked.

Which implementations currently can handle this and which don't?

More precisely, which implementations currently can handle CRL's at all
and which of them can handle these special public key properly?

I guess not too many.....

Peter

------=_NextPart_000_00B0_01BD898A.648E4720
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00B0_01BD898A.648E4720--

From: "Peter Lipp" <[email-masked]>
To: "Carl Ellison" <[email-masked]>
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Date: Wed, 27 May 1998 16:11:04 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00A4_01BD898A.0CB71860
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>However, isn't there a problem with your privacy laws in having the
Austrian
>SSN revealed in a public document like a certificate?  I don't know
Austrian
>laws, but under German law I was told that the national ID number is
>protected from being used by non-official entities.
Definitely, and I was not intending to promote this. I was just intending to
counter
the - adding references makes things worse - argument.

Peter

------=_NextPart_000_00A4_01BD898A.0CB71860
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00A4_01BD898A.0CB71860--

From: "Peter Lipp" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: CRL issuing
Date: Wed, 27 May 1998 16:07:41 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_009C_01BD8989.938E3FE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>(Whether anything actually supports this functionality is another question.
I
> know of several implementations which specifically *don't* support it, and
> just use the first key they find).

Thats what I fear.

Peter

------=_NextPart_000_009C_01BD8989.938E3FE0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_009C_01BD8989.938E3FE0--

From: "Peter Lipp" <[email-masked]>
To: "Ed Gerck" <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Date: Wed, 27 May 1998 15:53:58 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0065_01BD8987.A95D82B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

> I would like to remind of the use of a Certificate policy here.
No doubt about that. But that is not my point.

>I don’t think any strict rules regarding use of attributes or extensions
can
>change that.

I agree. But: nonetheless, I would like to have a standard "behaviour" of
CA's
if there is one topic many such CA's must behave somehow. If there would be
many many Pseudonym-Certificates around, maybe application programmers
would like to make this obvious to their users, and then a standard
attribute
within a certificate would come in handy.

Peter

------=_NextPart_000_0065_01BD8987.A95D82B0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0065_01BD8987.A95D82B0--

Date: Wed, 27 May 1998 09:43:35 -0400
To: "Peter Lipp" <[email-masked]>
From: Carl Ellison <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 12:30 PM 5/27/98 +0200, Peter Lipp wrote:
>Sure,
>I know that lot's of Peter Lipp's exist, so the individual corresponding to
>this
>name (which is the meaning of the name) is not clearly defined by Peter Lipp
>alone. What else is new? Does this make the concept of certificates invalid?

This lack of name uniqueness makes (name,key) certificates dangerous and 
puts the wisdom of using (name,key) certificates into doubt.  The danger is 
that we are so accustomed to using names as valid identifiers of people in 
our daily lives (thanks to our living, in the 3D world, in small communities 
of friends, family, coworkers, ...), that we are tempted to believe that all 
names are valid identifiers.  In a national, continental or global 
namespace, those names are not valid identifiers and a careful security 
design would not allow people to believe they are.  The current (name,key) 
certificate design and more especially the verbiage surrounding (name,key) 
certificates (including the texts of laws) not only allows people to believe 
names are valid identifiers but also seems to suffer from that mistake itself.
The danger of this belief mismatch is that someone looking for the certified
key of an old friend (or co-worker or customer or merchant or ...) is led
to guess whether the name in the certificate belongs to the entity that
user things it might -- based on name match.  This process is a human guess
and there is no room in security procedures for human guesses...at least
not when we are trying to keep mistakes in the process down to a probability
of less than 2^{-90}.

>>So, the conclusion may be that while it is bad to try to use
>>references to convey meaning, it is worse to use even more references
>>to try "harder"....
>I dont see that. If the certificate adds another reference, like my austrian
>social security number, this might make the reference unique, but might
>not help the user of the certificate resolve his problems, agreed. It might,
>e.g. if the user is actually able to use that information, like an Austrian
>doctor
>or our social security services. What does this mean? Not every certificate
>is equally useable for all purposes. Nothing new, I suppose.
>
>I believe that there is no such thing as the general certificate that is a
>catch all.

Amen.

However, isn't there a problem with your privacy laws in having the Austrian 
SSN revealed in a public document like a certificate?  I don't know Austrian 
laws, but under German law I was told that the national ID number is 
protected from being used by non-official entities.

As you add more such fields to a general certificate (to make it useful to
other people who care about other things about the keyholder), that 
certificate becomes a dossier.  [This is the main reason SPKI chose to issue 
a large number of certificates to a keyholder, each holding only one fact.]

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison  [email-masked]   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+

Date: Wed, 27 May 1998 14:29:57 +0200
To: Ferdinando Ricchiuti <[email-masked]>, Nilsson Hans <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Key Usage for for Authentication and digitalSignature
Cc: [email-masked]
Sender: [email-masked]

At 10.53 1998-05-27 +0200, Ferdinando Ricchiuti wrote:
>Actually in the SSL-v3.0 client-autentication phase, the client
>generates a MAC in this way:
>	1-the received data (master key) are padded and hashed
>	2-the resulting stream is then padded again and rehashed
>	3-this finaly stream is encrypted with client's private key
>This mean that the MAC sent to the server, is not a digital signature 
>as defined in X.509 specification.
>Thus we think there are not security leack using both digitalSignature
>and nonRepudation bits.
>
>Regards.
>
>F.Ricchiuti  [email-masked]
>R.D'Altoe'   [email-masked]
>

This is not only a question of protocols.

There are more differences between non-repudiation and authentication to be 
considered.

The most important difference is the way the key holder uses the private key, 

- how the use of the key is combined with a warning that using this key
includes
  responsibilities and liabilities 
- how the information to be signed is presented and accepted by the key
holder.
- how the key is protected from being used without the key holders conscious
  participation.

Many authentication processes is automatic and frequent while non-repudiation
is conscious and more infrequent. This makes it hard to use the same key
for both purposes.

In order to make the key holder liable for a signature, exclusive use of
the key for non-repudiation is of great value in court. This includes
exclusive mechanisms (PINs and codes) to activate the key.

Separated private keys requires separated certificates. Bad or
good protocols is not the most important consideration here.
---

What I want to propose is NOT to forbid the non-repudiation to be
combined with any other use. I think that is a question for the certificate
policy.

What I would like, is to clearly define the use of the bits. The best would be
to change the name from "digital signature" to "Authentication", thus to
identify
a service instead of a mechanism. As it is now it's difficult to understand
the
difference between "non-repudiation" and "digital signatures" and I believe
that
the PKIX definition is very unclear here.

The most important task is to make it possible to clearly distinguish te
use of 
keys for digital signatures as part in an authentication process, from the
case 
when it's used in digital signatures for non repudiation purposes.

/Stefan

----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

Date: Wed, 27 May 1998 13:41:12 +0200
To: "Peter Lipp" <[email-masked]>, "Ed Gerck" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I would like to remind of the use of a Certificate policy here.

At 22.08 1998-05-26 +0200, Peter Lipp wrote:
>Now, if a CA issues standard X.509 claimed-identity certificates,
>representing
>the CA's authentication management act, as well as pseudonym certificates,
>this CA most likely will want to make the difference explicit, because it
>does not
>want to risk somebody declaring their certificates useless.
>
>With current user-side technology, the only way to make this easily visible
>by the
>user seems to be to change the DN by adding e.g. "Pseudonym:" to CN.
>
>While this might not be necessary with "Pseudonym: Fritz the Cat", it
>definitely would be
>in the case of "Pseudonym: Ed Gerck" - both certificates issued to myself.
>This will work,
>and the user will more likely realize the fact that this is a pseudonym,
>that in the case there
>is no such hint.

The certificate policy is a perfect place to declare rules and regulations
concerning naming and interpretation of naming attributes.

This is handled both in section 3 and 7 of the PKIX certificate policy 
framework.

Trust by a relying party in a certificate and its included naming attributes 
must include an acceptance of the stipulations in the identified certificate 
policy. In fact, the certificate policy IS the main difference between a 
"driving-license" type of certificate and a "local membership" type of 
certificate.

I don’t think any strict rules regarding use of attributes or extensions can
change that.

/Stefan

----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

From: "Peter Lipp" <[email-masked]>
To: "Ed Gerck" <[email-masked]>
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Date: Wed, 27 May 1998 12:30:56 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_001D_01BD896B.4C098440
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Ed,

>I think that your comment mixes two issues, and I would like to pick
>them appart.

I think your response is based on assumptions, that may or may not be
true.

>This means that CAs (for good and
>valid reasons, basically pertaining to lack of adequate trust on the
>subscriber's declarations) explicitly exclude any warranty, assurance
>or liability for the *data* contained in supplied certs -- except
>data generated by the CA itself (eg, the cert signature).

For simplicity, I assume the propsed European Proposal was valid (and
this was one of the reasons for me asking). It sais:

>>Liability
>>
>>1. Member States shall ensure that by issuing a qualified certificate,
>>a certification service provider is liable to any person who reasonably
>>relies on the certificate for:
>>
>>(a) accuracy of all information in the qualified certificate as of the
date
>>it was issued, unless the certification service provider has stated
>>otherwise in the certificate;
>> .....
>>    2. Member States shall ensure that a certification service provider is
>>not liable for errors in the information in the qualified certificate that
has
>>been provided by the person to whom the certificate is issued, if it can
>>demonstrate that it has taken all reasonably practicable measures to
>>verify that information.

Any CA working under these guidelines will have to provide some warranty.

>Thus, without trust on the issuer *and* (often forgotten) on the
>subscriber a certificate is just a bag of bytes sent over the wire
>and which has no meaning by itself -- which is "common misconception
>#2", already cited:

As the passport is a piece of paper without trust in the issuer. Nothing new
here.

> non-cryptographic meaning of each of its atomic parts -- for each of
> the names that it may contain, such as common names, keys, hashes,
> etc.

Same thing as for passports. The only difference is that latter have been
used
for a while, and certificates are something people are not used to.

>2. each of the data sources for each data fields contained in the
>cert -- including the CA *and* the subscriber.
As the passport is based on a birth certificate which is based on
a statement by some doctor that a child actually exists .... but you
(or the officers at some border) still accept the passport .....

>The basic misconception here is to think that CAs warrant or
>"endorse" the data that they copy in a cert -- they do not.
Ed, what I am not sure (not having had the time to read all your
contributions) is what you are aiming at. Claiming that CA's don't
warrant anything - which might or might not be true today -seems to aim
at making the concepts of CA's per se invalid, but I don't see what
you are up to.

>References (ie, names) cannot convey meaning. For example, suppose I
>would write that I am sending a Gift to you? Is that a present (as
>written in the US) or a poison (as read in Austria)?
This depends. If you include in an extension that you are using the english
or german language, this becomes much better. If a certificate would contain
a universially accepted unique identifier, this would make things easier.
Sure,
I know that lot's of Peter Lipp's exist, so the individual corresponding to
this
name (which is the meaning of the name) is not clearly defined by Peter Lipp
alone. What else is new? Does this make the concept of certificates invalid?

>So, the conclusion may be that while it is bad to try to use
>references to convey meaning, it is worse to use even more references
>to try "harder"....
I dont see that. If the certificate adds another reference, like my austrian
social security number, this might make the reference unique, but might
not help the user of the certificate resolve his problems, agreed. It might,
e.g. if the user is actually able to use that information, like an Austrian
doctor
or our social security services. What does this mean? Not every certificate
is equally useable for all purposes. Nothing new, I suppose.

I believe that there is no such thing as the general certificate that is a
catch all.

Peter

------=_NextPart_000_001D_01BD896B.4C098440
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_001D_01BD896B.4C098440--

Date: Wed, 27 May 1998 10:53:59 +0200
From: Ferdinando Ricchiuti <[email-masked]>
To: Nilsson Hans <[email-masked]>
Cc: [email-masked]
Subject: Re: Key Usage for for Authentication and digitalSignature
Sender: [email-masked]

Nilsson Hans wrote:
> 
> In pkix-part1-07, section 4.2.1.3 Key Usage it says:
> 
> "For example, when an RSA key should be used only for signing, the
> digitalSignature and nonRepudation bits would be asserted"
> and also "The digitalSignature bit is asserted when the subject public key
> is used to privde authentication". The same writing can be found in the new
> ISO draft 1572 (Public Key certificates for banking.
> 
> If understand this correctly, this introduces a possible security threat,
> with the following scenario: In a user's certificate, both bits are set.
> When the user is required to logon to a web server using SSL client
> authentication, the server actually sends a the hash value of a false
> message, instead of a random number as a challenge.  The user encrypts with
> the corresponding private key, and has thus unknowingly signed the false
> message.
> 
> Because of this threat, we have in Sweden come to the conclusion that the
> nonRepudiation usage bit never may be combined with any other key usage. Is
> this correct (and PKIX-part1-07 wrong), or have we misunderstood something
> along the way?
> 
> Hans Nilsson
> 
> AU-System Network
> Stockholm Sweden

Hans,

Actually in the SSL-v3.0 client-autentication phase, the client
generates a MAC in this way:
	1-the received data (master key) are padded and hashed
	2-the resulting stream is then padded again and rehashed
	3-this finaly stream is encrypted with client's private key
This mean that the MAC sent to the server, is not a digital signature 
as defined in X.509 specification.
Thus we think there are not security leack using both digitalSignature
and nonRepudation bits.

Regards.

F.Ricchiuti  [email-masked]
R.D'Altoe'   [email-masked]

From: Nilsson Hans <[email-masked]>
To: [email-masked]
Subject: SV: Key Usage for for Authentication and digitalSignature
Date: Wed, 27 May 1998 07:08:57 +0100
Sender: [email-masked]

I agree that the threat is a case of poor protocol design. But there ARE
badly designed protocols out there. And since the function is called
"non-repudiation", we do not want to give the signer any possibility to
later repudiate his signature by saying: "some software I was using must
have had a bad protocol. I did not sign that document".

Hans

> -----Ursprungligt meddelande-----
> Från:	Michael Warner [SMTP:[email-masked]]
> Skickat:	 den 27 maj 1998 00:03
> Till:	[email-masked]; [email-masked]; [email-masked]
> Ämne:	Re: Key Usage for for Authentication and digitalSignature
> 
> 
> While I agree that it may be desirable to separate the use of a 
> non-repudiation key from outher authentication keys, I think the 
> threat described below is a case of poor protocol design.
> 
> The authentication token being signed should be more than just a simple 
> random number, but should be (the hash of) a token which includes the
> identity of the peer to which you are authenticating and possibly other
> information, such as your own random challenge.   This token should be 
> constructed by the signer - not the verifier.
> 
> Cheers,
> 
> Michael Warner
> Telstra Research Laboratories
> 
> > From: Mike Smith <[email-masked]>
> > 
> > Excellent scenario for misuse of DS within SSL or other "signed token"
> authentication 
> > schemas.  Yet another reason to separate the functions from DS purposes.
> > 
> > Michael
> > 
> > >>> Nilsson Hans <[email-masked]> 05/23 4:57 AM >>>
> > In pkix-part1-07, section 4.2.1.3 Key Usage it says:
> > 
> > "For example, when an RSA key should be used only for signing, the
> > digitalSignature and nonRepudation bits would be asserted" 
> > and also "The digitalSignature bit is asserted when the subject public
> key
> > is used to privde authentication". The same writing can be found in the
> new
> > ISO draft 1572 (Public Key certificates for banking. 
> > 
> > If understand this correctly, this introduces a possible security
> threat,
> > with the following scenario: In a user's certificate, both bits are set.
> > When the user is required to logon to a web server using SSL client
> > authentication, the server actually sends a the hash value of a false
> > message, instead of a random number as a challenge.  The user encrypts
> with
> > the corresponding private key, and has thus unknowingly signed the false
> > message.
> > 
> > Because of this threat, we have in Sweden come to the conclusion that
> the
> > nonRepudiation usage bit never may be combined with any other key usage.
> Is
> > this correct (and PKIX-part1-07 wrong), or have we misunderstood
> something
> > along the way?
> > 
> > Hans Nilsson
> > 
> > AU-System Network
> > Stockholm Sweden
> > 
> > 
> > 
> >
> !
>      !
> > !
> > !
> > !
> > !
> >
> 
> > 

Date: Tue, 26 May 1998 11:05:41 -0400
To: [email-masked] (David P. Kemp)
From: Russ Housley <[email-masked]>
Subject: Re: Question about NS cert server
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Dave:

I agree that CAs conforming to the PKIX profile will only generate v3
certificates, because all certificates will include extensions.

Russ

At 02:10 PM 5/22/98 -0400, David P. Kemp wrote:
>> From: Russ Housley <[email-masked]>
>> 
>> In my opinion, a certificate that has no extensions MUST not be a version 3
>> certificate.
>
>
>Part 1 section 4.1.2.1 says "At a minimum, conforming implementations
>shall recognize version 3 certificates."
>
>Section 4.2.1.2 says "This extension MUST appear in all conforming CA
>certificates ..."
>
>Therefore, PKIX-conforming CAs MUST issue only v3 certificate paths and
>PKIX-conforming clients MUST be able to read them.
>
>The only reason PKIX says anything about version 1 is to recommend that
>non-conforming CAs make their certs usable by old non-conforming clients
>whenever possible.  What is the purpose or effect of a MUST requirement
>which applies *only* to non-conforming applications?
>
>Dave Kemp
> 

Date: Wed, 27 May 1998 01:16:25 +0200
To: "Peter Lipp" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: CRL issuing
Sender: [email-masked]

We have studied this phenomena in Swedish trials.

At 21.46 1998-05-26 +0200, Peter Lipp wrote:
>Up to now my image of the world of CRL's was such that the key to
>issue a CRL must be the same key the certificate was signed with.
>Nice and simple.
>
>Now, in discussions with colleagues, one made the proposal to use
>a different key to keep things flexible. Hmm. I began to search, and
>was not able to find any explicit statement anywhere that would dis-
>allow such a solution. Implicitely, there seem to be difficulties though,
>as the CRL itself does not provide meanst to include any certificates
>that link the CA and the CRL-issuer together; the CRL only includes the
>DN of its issuer - i.e. if the key would be different the DN could not, and
>if
>it was how can I know whose certificates where revoked when only a
>serial number was available.
>
>What I'd like to know was if there is something somewhere that I have
>overlooked that made the case clear.

We conclude that:

Using version 1 CRL:s The structure according to PKIX "Certificate management 
protocols" section 2.4 REQUIRES the CRL to be issued with the currently
active 
CA-key and not with the one that was active when issuing the revoked
certificate.

This requires the certificate user to keep track of the current active CA
key for that CA and use it for CRL checking.

Using version 2 CRL:s with a key identifier makes it possible to generalize
the scheme and totally separate the CRL-key from the issuing key. Then of
course the CA has to post a certificate over the public CRL-key in the
appropriate repository.

The CA is by this procedure linked to the CRL by certifying the
public key with which the CRL can be checked.

Last: To my understanding a specific CRL (or equivalent revocation checking
service) must be implicitly or explicitly identified by the certificate
itself. Using version 3 certificates the CRL can be identified in an
extension.
By following this rule there is only need for the certificate serial
number in the CRL. 

Stefan Santesson
Accurata.

>
>Peter
>
>
>
>

----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

Date: Wed, 27 May 1998 09:03:18 +1000
From: Michael Warner <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Key Usage for for Authentication and digitalSignature
Sender: [email-masked]

While I agree that it may be desirable to separate the use of a 
non-repudiation key from outher authentication keys, I think the 
threat described below is a case of poor protocol design.

The authentication token being signed should be more than just a simple 
random number, but should be (the hash of) a token which includes the
identity of the peer to which you are authenticating and possibly other
information, such as your own random challenge.   This token should be 
constructed by the signer - not the verifier.

Cheers,

Michael Warner
Telstra Research Laboratories

> From: Mike Smith <[email-masked]>
> 
> Excellent scenario for misuse of DS within SSL or other "signed token" authentication 
> schemas.  Yet another reason to separate the functions from DS purposes.
> 
> Michael
> 
> >>> Nilsson Hans <[email-masked]> 05/23 4:57 AM >>>
> In pkix-part1-07, section 4.2.1.3 Key Usage it says:
> 
> "For example, when an RSA key should be used only for signing, the
> digitalSignature and nonRepudation bits would be asserted" 
> and also "The digitalSignature bit is asserted when the subject public key
> is used to privde authentication". The same writing can be found in the new
> ISO draft 1572 (Public Key certificates for banking. 
> 
> If understand this correctly, this introduces a possible security threat,
> with the following scenario: In a user's certificate, both bits are set.
> When the user is required to logon to a web server using SSL client
> authentication, the server actually sends a the hash value of a false
> message, instead of a random number as a challenge.  The user encrypts with
> the corresponding private key, and has thus unknowingly signed the false
> message.
> 
> Because of this threat, we have in Sweden come to the conclusion that the
> nonRepudiation usage bit never may be combined with any other key usage. Is
> this correct (and PKIX-part1-07 wrong), or have we misunderstood something
> along the way?
> 
> Hans Nilsson
> 
> AU-System Network
> Stockholm Sweden
> 
> 
> 
>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            !
     !
> !
> !
> !
> !
>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: CRL issuing
Reply-To: [email-masked]
Date: Wed, 27 May 1998 10:18:01 (NZST)
Sender: [email-masked]

>Now, in discussions with colleagues, one made the proposal to use a different
>key to keep things flexible. Hmm. I began to search, and was not able to find
>any explicit statement anywhere that would dis- allow such a solution.
>Implicitely, there seem to be difficulties though, as the CRL itself does not
>provide meanst to include any certificates that link the CA and the CRL-issuer
>together; the CRL only includes the DN of its issuer - i.e. if the key would
>be different the DN could not, and if it was how can I know whose certificates
>where revoked when only a serial number was available.
>
>What I'd like to know was if there is something somewhere that I have
>overlooked that made the case clear.
 
The keyUsage flags.  You can specify that one key only be used for cert 
signing, and one only for CRL signing, so even if they have the same DN you 
could choose the correct key based on keyUsage.
 
(Whether anything actually supports this functionality is another question.  I 
 know of several implementations which specifically *don't* support it, and 
 just use the first key they find).
 
Peter.

Date: Tue, 26 May 1998 15:23:04 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: CRL issuing
Sender: [email-masked]

You may wish to search on "indirect" CRLs.

Michael

>>> "Peter Lipp" <[email-masked]> 05/26 1:46 PM >>>
Up to now my image of the world of CRL's was such that the key to
issue a CRL must be the same key the certificate was signed with.
Nice and simple.

Now, in discussions with colleagues, one made the proposal to use
a different key to keep things flexible. Hmm. I began to search, and
was not able to find any explicit statement anywhere that would dis-
allow such a solution. Implicitely, there seem to be difficulties though,
as the CRL itself does not provide meanst to include any certificates
that link the CA and the CRL-issuer together; the CRL only includes the
DN of its issuer - i.e. if the key would be different the DN could not, and
if
it was how can I know whose certificates where revoked when only a
serial number was available.

What I'd like to know was if there is something somewhere that I have
overlooked that made the case clear.

Peter

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

Date: Tue, 26 May 1998 17:56:20 -0300 (EST)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: Peter Lipp <[email-masked]>
cc: E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: Re: [E-CARM] Pseudonyms
Sender: [email-masked]

On Tue, 26 May 1998, Peter Lipp wrote:

> Ed Gerck wrote:
>> In legal reliance terms, one may trust the confirmation
>> procedures of the CA during certificate reliance, but one cannot rely
>> upon them for other than their value as a representation of the CA's
>> authentication management act expressed in the CA's own terms and
>> rules -- therefore, a X.509 certificate is neither necessarily
>> meaningful nor valid in a user's reference frame or for the user's
>> purposes.
>
>Agreed. Practically however, a X.509 certificate might be meaningful for the
>users purposes in most of the cases, while not 100% guaranteed.
>Statistically,
>most of the passports or drivers licenses used are still valid and fake ones
>or
>so do not make their concept invalid per se. Users "simply" have to be aware
>of their limitations.

Peter:

I think that your comment mixes two issues, and I would like to pick
them appart.

The first issue is about "correctness": is a cert correct? This is
the question behind arguments such as if passports or drivers
licenses are fake or not and *also* whether such fake ids might have
been used to obtain an incorrect (ie, with wrong data) cert. 

To that question, the CA answer is not "not 100% guaranteed" as you
say -- but "100% not guaranteed". This means that CAs (for good and
valid reasons, basically pertaining to lack of adequate trust on the
subscriber's declarations) explicitly exclude any warranty, assurance
or liability for the *data* contained in supplied certs -- except
data generated by the CA itself (eg, the cert signature).

Thus, without trust on the issuer *and* (often forgotten) on the
subscriber a certificate is just a bag of bytes sent over the wire
and which has no meaning by itself -- which is "common misconception
#2", already cited:

 Here, trust is not only essential for the cryptographic meaning
 (i.e., providing for valid origin authentication and data integrity
 authentication) of the certificate but also for the
 non-cryptographic meaning of each of its atomic parts -- for each of
 the names that it may contain, such as common names, keys, hashes,
 etc. 

Thus, to achieve "correctness" you must trust TWO entities, at least: 

1. the issuer for the cert's signature, and

2. each of the data sources for each data fields contained in the
cert -- including the CA *and* the subscriber.

The second issue is about "effectiveness": is the cert effective for
my intended meaning? This question cannot even be asked, except for
the issuing CA *itself* and by *itself*.  That issue is at the heart
of "common misconception #3", already quoted above. 

>
>Now, if a CA issues standard X.509 claimed-identity certificates,
>representing
>the CA's authentication management act, as well as pseudonym certificates,
>this CA most likely will want to make the difference explicit, because it
>does not
>want to risk somebody declaring their certificates useless.
>

Not useless -- afterall, they are tamperproof references. However,
what do they express? You may interpret them as you wish -- which may
be different from what the CA thinks, and the CA may think what it
wishes in its CPS. 

The basic misconception here is to think that CAs warrant or
"endorse" the data that they copy in a cert -- they do not.

As already mentioned here, this is common misconception #9, when
people think that "endorsement"  has to do with verification,
warranties, liabilities.  That is not the case. 

Common misconception #9:

 The word "endorsement" must be viewed with care because it may
 have both a "strong" and a "weak" form -- without the user knowing
 which form is actually used. The strong form means "verified using
 reasonable effort and as such guaranteed". The weak form has the
 meaning "copying as received". In the praxis, all actual protocols
 explicitly or implicitly use the weak form because of specific
 legislation shelters and warranty disclaimers .. This
 corresponds to "endorsement without recourse". For example, in
 English law one can endorse "without recourse" (or, as it used to be
 expressed, "sans recours"), which passes on the benefit of a bill of
 exchange without adding any guarantee. Endorsement in any form does
 not mean that the whole content of the certificate is endorsed,
 normally only the public-key is endorsed -- even though this is not
 usually stated in the certificate itself.

>With current user-side technology, the only way to make this easily visible
>by the
>user seems to be to change the DN by adding e.g. "Pseudonym:" to CN.
>
>While this might not be necessary with "Pseudonym: Fritz the Cat", it
>definitely would be
>in the case of "Pseudonym: Ed Gerck" - both certificates issued to myself.
>This will work,
>and the user will more likely realize the fact that this is a pseudonym,
>that in the case there
>is no such hint.

References (ie, names) cannot convey meaning. For example, suppose I
would write that I am sending a Gift to you? Is that a present (as
written in the US) or a poison (as read in Austria)? 

Gottlob Frege (in 1910) showed that references are just truth-values
-- which have no significance if seen without the corresponding truth
conditions. 

Now, suppose you would send a "cert tutorial" to an average user,
together with the cert, so that users could study that and then hope
to correctly distinguish between pseudonymous, anonymous, named,
implicit and whatever certs, taking also into account a crash course
on (for example) the UK legislation that says that I can legally use
the name John Major if I so wish and a crash course on syntatics
versus semantics -- then... would this increase or decrease
confusion? 

So, the conclusion may be that while it is bad to try to use
references to convey meaning, it is worse to use even more references
to try "harder"....

Here, Marx Brothers fans will possibly recall the scene in "A Day at
the Races": a tip for Sun-up. In this scene, Groucho, intending to
put his money on Sun-up, is induced instead to buy a coded tip from
Chico and is able to establish the identity of the horse only, at
some cost in terms of time and money, by successive purchases from
Chico of the code book, the master code book, the breeders' guide and
various other works of reference, by the end of which the race is
over, Sun-up having won.

Cheers,

Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

From: Cliff Wang <[email-masked]>
To: <[email-masked]>
Subject: X.509 and PKCS#7 and #10
Date: Tue, 26 May 1998 16:50:02 -0400
Sender: [email-masked]

I apologize if this question has been asked before
since I am new to this working group.

Many times I see products supporting X.509 v3 and
PKCS#7 and #10. X.509 v3 is IETF standards and PKCS
are RSA owned standards. Can somebody explain to me
what exactly they differ? If X.509 v3 is sufficient, why PKCS
stuff is still required ?

Thanks!

Cliff Wang
IBM
[email-masked]

Date: Tue, 26 May 1998 14:38:18 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Key Usage for for Authentication and digitalSignature
Sender: [email-masked]

Excellent scenario for misuse of DS within SSL or other "signed token" authentication schemas.  Yet another reason to separate the functions from DS purposes.

Michael

>>> Nilsson Hans <[email-masked]> 05/23 4:57 AM >>>
In pkix-part1-07, section 4.2.1.3 Key Usage it says:

"For example, when an RSA key should be used only for signing, the
digitalSignature and nonRepudation bits would be asserted" 
and also "The digitalSignature bit is asserted when the subject public key
is used to privde authentication". The same writing can be found in the new
ISO draft 1572 (Public Key certificates for banking. 

If understand this correctly, this introduces a possible security threat,
with the following scenario: In a user's certificate, both bits are set.
When the user is required to logon to a web server using SSL client
authentication, the server actually sends a the hash value of a false
message, instead of a random number as a challenge.  The user encrypts with
the corresponding private key, and has thus unknowingly signed the false
message.

Because of this threat, we have in Sweden come to the conclusion that the
nonRepudiation usage bit never may be combined with any other key usage. Is
this correct (and PKIX-part1-07 wrong), or have we misunderstood something
along the way?

Hans Nilsson

AU-System Network
Stockholm Sweden

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 

From: "Peter Lipp" <[email-masked]>
To: "Ed Gerck" <[email-masked]>
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Date: Tue, 26 May 1998 22:08:04 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0109_01BD88F2.C14DDA90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Ed,

>This is trivially fine and if the EC Guidelines require that then
>they are just allowing for a fact -- which is good, instead of
>pretending otherwise as in some other countries.
I have to admit, that these pseudonym certificates are to be issued
on request only, and are not the only certificates a CA can issue. It must
issue one if the user requires that. This was not clear in my message.

> In legal reliance terms, one may trust the confirmation
> procedures of the CA during certificate reliance, but one cannot rely
> upon them for other than their value as a representation of the CA's
> authentication management act expressed in the CA's own terms and
> rules -- therefore, a X.509 certificate is neither necessarily
> meaningful nor valid in a user's reference frame or for the user's
> purposes.
Agreed. Practically however, a X.509 certificate might be meaningful for the
users purposes in most of the cases, while not 100% guaranteed.
Statistically,
most of the passports or drivers licenses used are still valid and fake ones
or
so do not make their concept invalid per se. Users "simply" have to be aware
of their limitations.

Now, if a CA issues standard X.509 claimed-identity certificates,
representing
the CA's authentication management act, as well as pseudonym certificates,
this CA most likely will want to make the difference explicit, because it
does not
want to risk somebody declaring their certificates useless.

With current user-side technology, the only way to make this easily visible
by the
user seems to be to change the DN by adding e.g. "Pseudonym:" to CN.

While this might not be necessary with "Pseudonym: Fritz the Cat", it
definitely would be
in the case of "Pseudonym: Ed Gerck" - both certificates issued to myself.
This will work,
and the user will more likely realize the fact that this is a pseudonym,
that in the case there
is no such hint.

OTOH it is not a technically elegant solution. Personally, I'd prefer to
have an extension defined
that says: This is a pseudonym. I could invent my private extension, which
will buy me nothing
with todays clients. A standardized extension might help, but not now -
better later then never.

So this is a technically solveable problem, that might be solved within e.g.
PKIX, and might
be available to standard software timely for any european guidelines
becoming valid sometimes.
And meta-discussions about this, while being of value, won't help here.

Peter

------=_NextPart_000_0109_01BD88F2.C14DDA90
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0109_01BD88F2.C14DDA90--

From: "Peter Lipp" <[email-masked]>
To: "Carl Ellison" <[email-masked]>
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Date: Tue, 26 May 1998 21:52:53 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00FF_01BD88F0.A2A9FDA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Carl,

>How would you hide the other fields of a certificate?  Encipher them?
Leave them empty as much as possible.

>OTOH, if a certificate issuer means something besides random name
assignment
>by an ID cert, I would like to see that meaning expressed explicitly.  For
>example,
The aim of the digital signature guidelines are definitely to achieve
"meaning" in terms
of identifiabilty.  And it is essential to make a difference between a
pseudonym and a
claim-to-be-a-real-name in such an environment.

And no, issuing SPKI/SDSI certificates for pseudonyms does not seem to be an
option (yet) :-)

I have to add that these guidelines are a draft only, and we will have to
see what will be in
there finally. However, as many (most?) of us here believe that pseudonyms
are good, I bet
these might stay.

Peter

------=_NextPart_000_00FF_01BD88F0.A2A9FDA0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00FF_01BD88F0.A2A9FDA0--

From: "Peter Lipp" <[email-masked]>
To: <[email-masked]>
Subject: CRL issuing
Date: Tue, 26 May 1998 21:46:08 +0200
Sender: [email-masked]

Up to now my image of the world of CRL's was such that the key to
issue a CRL must be the same key the certificate was signed with.
Nice and simple.

Now, in discussions with colleagues, one made the proposal to use
a different key to keep things flexible. Hmm. I began to search, and
was not able to find any explicit statement anywhere that would dis-
allow such a solution. Implicitely, there seem to be difficulties though,
as the CRL itself does not provide meanst to include any certificates
that link the CA and the CRL-issuer together; the CRL only includes the
DN of its issuer - i.e. if the key would be different the DN could not, and
if
it was how can I know whose certificates where revoked when only a
serial number was available.

What I'd like to know was if there is something somewhere that I have
overlooked that made the case clear.

Peter

Date: Tue, 26 May 1998 14:04:01 -0400
From: Bob Masters <[email-masked]>
Organization: GTE Internetworking
To: Carlisle Adams <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-ipki3cmp-08.txt
Sender: [email-masked]

Carlisle,

Page 20 of CMP contains the statement "specification of external protection
using PKCS #7 will be provided in a separate document."  What is this separate
document?  I have looked at CMC, but it does not seem to be compatible with CMP.

Thanks for any help you can give me on this.

Bob Masters
GTE Internetworking

Carlisle Adams wrote:

> Hi all,
>
> For those that are curious, the PKIX-CMP draft has been updated to
> accommodate a change that was necessary for its companion draft CRMF.  The
> request message in CRMF was missing a way to carry an AlgId in one of the
> choices for proof-of-possession syntax (the syntax was borrowed from CMP,
> which didn't need to carry the AlgId because it explicitly used the one
> specified in PKIHeader, but since CRMF does not necessarily have a PKIHeader
> the extra AlgId needed to be included).
>
> The syntax change is on p.26, where publicKeyMAC is now a PKMACValue
> (instead of a BIT STRING), and PKMACValue (defined in CRMF) is a sequence of
> AlgId and BIT STRING.
>
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> [email-masked]
> --------------------------------------------
>
> > ----------
> > From:         [email-masked][SMTP:[email-masked]]
> > Sent:         Tuesday, May 26, 1998 10:16 AM
> > To:   IETF-Announce
> > Cc:   [email-masked]
> > Subject:      I-D ACTION:draft-ietf-pkix-ipki3cmp-08.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Public-Key Infrastructure (X.509) Working
> > Group
> > of the IETF.
> >
> >       Title           : Internet X.509 Public Key Infrastructure
> > Certificate
> >                           Management Protocols
> >       Author(s)       : C. Adams, S. Farrell
> >       Filename        : draft-ietf-pkix-ipki3cmp-08.txt
> >       Pages           : 67
> >       Date            : 22-May-98
> >
> > This document describes the Internet X.509 Public Key Infrastructure
> > (PKI) Certificate Management Protocols. Protocol messages are defined
> > for all relevant aspects of certificate creation and management.  Note
> > that 'certificate' in this document refers to an X.509v3 Certificate as
> > defined in [COR95, X509-AM].
> >

Alternate-recipient: Allowed
Disclose-recipients: Prohibited
Content-return: Allowed
Date: Tue, 26 May 1998 10:36:05 -0700
From: Mack Hicks <[email-masked]>
Subject: attribute certs
To: [email-masked] (Return requested)
Cc: [email-masked] (Return requested)
Content-identifier: 00E9A356AFD85158
Conversion: Allowed
Original-encoded-information-types: IA5-Text
X400-Content-type: P2-1988 ( 22 )
X400-MTS-identifier: [/c=US/admd=attmail/; 00E9A356AFD85158-attmail]
X400-Originator: [email-masked]
X400-Recipients: non-disclosure;
Sender: [email-masked]

Oliver,

Bank of America has implemented OCSP between Bank of America
and Zions Bank.  We have implemented this as part of the
NACHA CA Interoperability pilot in cooperation with Verisign
and CertCo. We have it working. The pilot begins on June 1.

Note that the CA does not sign the OCSP response - rather
the OCSP is the agent of certificate status to the merchants
in this pilot.

See http://internetcouncil.nacha.org/

-   -
Mack Hicks (415) 278-7230  -- Interactive Banking Division
425 1st St m/s3671, SF CA 94105 <[email-masked]>
*** Forwarding note from O3UDISXT--EXTHUB   05/26/98 01:50 ***
To: GMHICKS --ABACIS2  Mack Hicks

From: Oliver Korfmacher
Subject: attribute certs

External Addresses Follow:

From: "Oliver Korfmacher"<[email-masked]>
To: [email-masked]

(sorry if this is a faq)

Could anybody comment on attribute certificates? Are they used in
real-world apps?

And, long ago, somebody asked for implementations of OCSP -- I never
found any answers to this one? Or do I miss it?

We currently consider an OCSP extension to our x.500/ldap dsa -- any
comments welcome.

        Oliver

--
Oliver Korfmacher, Isocor  [email-masked]  Telephone +49.6021/3095-51
Fax  +49.6021/3095-99  Mobile +49.172/3907041  Msg [email-masked]

                                       Privat:   [email-masked]

From: Carlisle Adams <[email-masked]>
To: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-ipki3cmp-08.txt
Date: Tue, 26 May 1998 13:13:50 -0400
Sender: [email-masked]

Hi all,

For those that are curious, the PKIX-CMP draft has been updated to
accommodate a change that was necessary for its companion draft CRMF.  The
request message in CRMF was missing a way to carry an AlgId in one of the
choices for proof-of-possession syntax (the syntax was borrowed from CMP,
which didn't need to carry the AlgId because it explicitly used the one
specified in PKIHeader, but since CRMF does not necessarily have a PKIHeader
the extra AlgId needed to be included).

The syntax change is on p.26, where publicKeyMAC is now a PKMACValue
(instead of a BIT STRING), and PKMACValue (defined in CRMF) is a sequence of
AlgId and BIT STRING.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	Tuesday, May 26, 1998 10:16 AM
> To: 	IETF-Announce
> Cc: 	[email-masked]
> Subject: 	I-D ACTION:draft-ietf-pkix-ipki3cmp-08.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working
> Group 
> of the IETF.
> 
> 	Title		: Internet X.509 Public Key Infrastructure
> Certificate 
>                           Management Protocols
> 	Author(s)	: C. Adams, S. Farrell
> 	Filename	: draft-ietf-pkix-ipki3cmp-08.txt
> 	Pages		: 67
> 	Date		: 22-May-98
> 	
> This document describes the Internet X.509 Public Key Infrastructure
> (PKI) Certificate Management Protocols. Protocol messages are defined
> for all relevant aspects of certificate creation and management.  Note
> that 'certificate' in this document refers to an X.509v3 Certificate as
> defined in [COR95, X509-AM].
> 

Date: Tue, 26 May 1998 17:47:43 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Nilsson Hans <[email-masked]>
CC: [email-masked]
Subject: Re: Key Usage for for Authentication and digitalSignature
Sender: [email-masked]

Nilsson Hans wrote:

> In pkix-part1-07, section 4.2.1.3 Key Usage it says:
> 
> "For example, when an RSA key should be used only for signing, the
> digitalSignature and nonRepudation bits would be asserted"
> and also "The digitalSignature bit is asserted when the subject public key
> is used to privde authentication". The same writing can be found in the new
> ISO draft 1572 (Public Key certificates for banking.
 
> If understand this correctly, this introduces a possible security threat,
> with the following scenario: In a user's certificate, both bits are set.
> When the user is required to logon to a web server using SSL client
> authentication, the server actually sends a the hash value of a false
> message, instead of a random number as a challenge.  The user encrypts with
> the corresponding private key, and has thus unknowingly signed the false
> message.
 
> Because of this threat, we have in Sweden come to the conclusion that the
> nonRepudiation usage bit never may be combined with any other key usage. Is
> this correct (and PKIX-part1-07 wrong), or have we misunderstood something
> along the way?

I fully support your position. Pkix-part1-07 should be corrected.

Denis

N.B. A long time ago, when participating to the ISO work I advocated for
the addition the NR bit.
 
> Hans Nilsson
> 
> AU-System Network
> Stockholm Sweden

-- 
      Denis Pinkas     Bull S.A.          mailto:[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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki3cmp-08.txt
Date: Tue, 26 May 1998 10:16:04 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          Management Protocols
	Author(s)	: C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-ipki3cmp-08.txt
	Pages		: 67
	Date		: 22-May-98
	
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocols. Protocol messages are defined
for all relevant aspects of certificate creation and management.  Note
that 'certificate' in this document refers to an X.509v3 Certificate as
defined in [COR95, X509-AM].

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki3cmp-08.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki3cmp-08.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki3cmp-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Certificate reparenting, version numbers in extensions
Reply-To: [email-masked]
Date: Wed, 27 May 1998 01:48:11 (NZST)
Sender: [email-masked]

In preparation for the next release of the X.509 style guide (I think I've 
given the vendors I've been able to contact about the bug list enough time 
now :-), I have a few questions/issues I'd like to get feedback on.
        
The first one is the problems you encounter with constraint enforcement.  For 
most types of chaining, it's fairly easy to resolve the validity of a cert by 
examining the parent-child relationship and making sure everything is in 
order (parent is a CA, hasn't expired, names chain correctly, etc etc).  
However in some cases it's possible for CA's to plant booby-traps in the 
chaining by specifying a constraint which affects some arbitrary certificate 
an arbitrary distance down the chain.  In general all this does is make 
validation annoyingly difficult, but it can cause reparenting and rerooting to 
fail completely.  For example what happens when both the current subtree and 
the new parent subtree contain conflicting constraints?  One of the reasons 
for having a name-independant key identifier (authority/subjectKeyIdentifier) 
is to allow reparenting, however if almost any kind of constraint is present 
in the path (off the top of my head any of basic constraints, name 
constraints, and policy constraints (which just about covers all the bases 
anyway)) they'll interfere with reparenting).
 
How seriously has this been examined in practice?  It easy enough to specify a 
key identifier to allow a cert to be identified independant of any labelling 
it might have, but since path validation is still bound by the labelling it 
may not do a lot of good in practice.
 
The second problem is that of putting version numbers into extensions.  This 
can interfere with the processing of critical extensions, because it's 
uncertain whether a critical extension which you recognise with a version 
number which you don't recognise counts as a "recognised" (in the sense of 
"don't reject the certificate") extension.  You certainly recognise the 
extension (based on the OID), but you don't recognise it based on the version 
number (this ties in with my earlier complaints about exactly what is meant 
by "recognise an extension").  As I see it having version numbers in an 
extension means the whole thing falls into a logical loophole, because you can 
either accept the cert (you recognise the OID) or reject it (you don't 
recognise the data in the extension).
 
I discussed this problem with someone who has a version number in an extension 
recently, they were of the opinion that knowing what the OID was counted as 
recognising the extension, but I considered it to mean that you were capable 
of processing it in a manner compliant with the semantic intent of the 
extension.  What do others think?
 
Some minor nits from the latest draft, there's a spurious 
CertificatePolicesSyntax present in policyConstraints, and I assume the given 
PolicyConstraints should actually be PolicyConstraintsSyntax.  In addition the 
altName URI is overloaded to double up on the functionality of 
authorityInfoAccess.  I assume this was an attempt to sidestep possible 
patents on the latter?  I think the overloading only appeared in the last 
draft, will this be undone now that the patent situation is cleared up 
(assuming that's what motivated it)?
 
Peter.

Date: Tue, 26 May 1998 12:12:34 +0200
From: Oliver Korfmacher <[email-masked]>
Reply-To: [email-masked]
Organization: ISOCOR GmbH
To: Charles Moore <[email-masked]>
Subject: Re: attribute certs
Sender: [email-masked]

> 
> We currently consider an OCSP extension to our x.500/ldap dsa -- any
> comments welcome.
> 
> > Thats interesting approach, but I dont see how you will manage the
> business side of on-line status from a DSA?
> ( I would want my status signed by the CA that issued the cert?)
hmm. 1) german signature law requires a top level or root ca which
holds  certs of all second level ca, 2) what about cross certification
here? and 3) if there are lets say 5 ca, checking the one who validates
is okay? Of course, this is somehow limited..

In OCSP, all answers are signed by the CA.
We would probably strongly suggest that the request is signed by the
requestor as well. Due to commercial reasons, the CA operator might want
this info for billing purposes..

	Oliver
-- 
Oliver Korfmacher, Isocor  [email-masked]  Telephone +49.6021/3095-51
Fax  +49.6021/3095-99  Mobile +49.172/3907041  Msg [email-masked]

                                       Privat:   [email-masked]

From: [email-masked]
Date: Tue, 26 May 1998 11:33:23 +0200
Subject: RE: Key Usage for for Authentication and digitalSignature
TO: [email-masked], [email-masked]
Sender: [email-masked]

--openmail-part-01132d04-00000001
Content-Type: multipart/alternative; boundary=openmail-part-01132d04-00000002

--openmail-part-01132d04-00000002
Content-Type: text/plain; charset=ISO-8859-1; name="BDY.RTF"
Content-Disposition: inline; filename="BDY.RTF"
Content-Transfer-Encoding: quoted-printable

[email-masked] wrote:
>
>In pkix-part1-07, section 4.2.1.3 Key Usage it says:
>
>"For example, when an RSA key should be used only for signing, the
>digitalSignature and nonRepudation bits would be asserted" =20
>and also "The digitalSignature bit is asserted when the subject public
key
>is used to privde authentication". The same writing can be found in the=

new
>ISO draft 1572 (Public Key certificates for banking. =20
>
> [...]
>

Hi Hans,

I believe this must be a typo, right?
Later in the same section it says:

      The digitalSignature bit is asserted when the subject public key
      is used to verifying digital signatures that have purposes other
                                                                 ^^^^^
      than non-repudiation, certificate signature, and CRL signature.
      For example, The digitalSignature bit is asserted when the subject=

      public key is used to provide authentication.

      The nonRepudiation bit is asserted when the subject public key is
      used to verifying digital signatures used to provide a non-
      repudiation service which protects against the signing entity
      falsely denying some action, excluding certificate or CRL signing.=

IMHO this would indicate that the digitalSignature and non-repudiation
bits may never be used at the same time.

OTOH Section 7.3.1 also states that: =20

  "The use of a single key for both signature and encryption purposes =20
  is not recommended, but is not forbidden."

Since PKIX-1 is not a policy document, it cannot forbid bad combinations=

of key usage bits I believe. However, I'd applaud the adobtion of a =20
statement similar to the one above, that recommend against the =20
combination of the digitalSignature and non-repudiation bits.

Regards,
/Lars Johansson
Sweden Post

--openmail-part-01132d04-00000002
Content-Type: application/rtf; name="BDY.RTF"
Content-Disposition: attachment; filename="BDY.RTF"
Content-Transfer-Encoding: base64

--openmail-part-01132d04-00000002--

--openmail-part-01132d04-00000001
Content-Type: application/x-openmail-1734; name="WINMAIL.DAT"
Content-Disposition: attachment; filename="WINMAIL.DAT"
Content-Transfer-Encoding: base64

--openmail-part-01132d04-00000001--

Date: Tue, 26 May 1998 09:23:39 +0200
From: Oliver Korfmacher <[email-masked]>
To: [email-masked]
Subject: attribute certs
Sender: [email-masked]

(sorry if this is a faq)

Could anybody comment on attribute certificates? Are they used in
real-world apps?

And, long ago, somebody asked for implementations of OCSP -- I never
found any answers to this one? Or do I miss it?

We currently consider an OCSP extension to our x.500/ldap dsa -- any
comments welcome. 

	Oliver

-- 
Oliver Korfmacher, Isocor  [email-masked]  Telephone +49.6021/3095-51
Fax  +49.6021/3095-99  Mobile +49.172/3907041  Msg [email-masked]

                                       Privat:   [email-masked]

Date: Mon, 25 May 1998 23:36:05 -0300 (EST)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: Peter Lipp <[email-masked]>
cc: E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: Re: [E-CARM] Pseudonyms
Sender: [email-masked]

On Mon, 25 May 1998, Peter Lipp wrote:

>The European Commission's Guidelines will most probably require
>CA's to issue semi-anonymous certificates containing a pseudonym
>instead of the subjects real name. This is fine.

Peter:

This is trivially fine and if the EC Guidelines require that then
they are just allowing for a fact -- which is good, instead of
pretending otherwise as in some other countries.

For example, in the UK anyone can use any name without any
formalities for changing names and no name is less legal than any
other. Since the UK is in the EC, I imagine that Mark Twain could
still get his cert in Europe at least by requiring it from a UK CA
... 

Further, DNs in certs express the CA's name assignment (ie, NA to
CA), according to the CA's own rules and understanding as expressed
by each CA's CPS. 

> 
> Now, if a CA want's to issue a pseudonym-certificate, it will
> somehow like to or have to mark this as being a pseudonym. One way
> to do this would be to change the DN. Ideally there should be a
> standard way to do that in any case. Has there been any discussion
> about that - or any opinions on that? 

So, answering your question, pseudonyms can be trivially used in DNs
if and only if the CA accepts them -- the CA *is* the final authority
as the issued certificates are concerned. 

This is unfortunately not always clearly understood and was numbered
here as "common misconception #3", because the data in a certificate
is NEITHER objectively NOR intersubjectively warranted by the CA, but
just subjectively warranted according to the CA's own viewpoint, as
was summarized:

 In legal reliance terms, one may trust the confirmation
 procedures of the CA during certificate reliance, but one cannot rely
 upon them for other than their value as a representation of the CA's
 authentication management act expressed in the CA's own terms and
 rules -- therefore, a X.509 certificate is neither necessarily
 meaningful nor valid in a user's reference frame or for the user's
 purposes. 

as listed in e-carm's archives.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

Date: Mon, 25 May 1998 21:30:09 -0400
To: "Peter Lipp" <[email-masked]>
From: Carl Ellison <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

At 11:39 PM 5/25/98 +0200, Peter Lipp wrote:
>The European Commission's Guidelines will most probably require
>CA's to issue semi-anonymous certificates containing a pseudonym
>instead of the subjects real name. This is fine.
>
>Now, if a CA want's  to issue a pseudonym-certificate, it will somehow
>like to or have to mark this as being a pseudonym. One way to do this
>would be to change the DN. Ideally there should be a standard way to do that
>in any case. Has there been any discussion about that - or any opinions on
>that?
>
>I believe that anything outside the DN would not be visible to the user of
>such a
>cert, while OTOH I'd prefer a special extension technically.

Hi Peter.

How would you hide the other fields of a certificate?  Encipher them?

I'm not sure labeling a pseudonym makes any sense.  It certainly doesn't in 
SDSI.  There is no reason to differentiate between a common name, a pet name 
and a randomly chosen pseudonum in SDSI.  Since I tend to map all X.509 
names into SDSI names in order to make sense of them, the 
indistinguishability of these different kinds of names is carried along with 
that.

OTOH, if a certificate issuer means something besides random name assignment 
by an ID cert, I would like to see that meaning expressed explicitly.  For 
example,

"The information in this certificate should have enabled someone to track 
down the keyholder, as of <issue-date>."

or

"The issuer of this certificate co-signs anything signed by the subject 
keyholder up to a limit of $XXXX."

or

"The issuer of this certificate insures any user of this certificate against 
fraud and abuse by the keyholder, up to a limit of $YYYYYYYYY"

oe

"The issuer of this certificate promises to track down the subject keyholder 
for a fee of $ZZZ, until <expiry-date>, for the purpose of serving legal 
papers on him/her."

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison  [email-masked]   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+

From: "Peter Lipp" <[email-masked]>
To: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Pseudonyms
Date: Mon, 25 May 1998 23:39:33 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00B1_01BD8836.5F408F80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The European Commission's Guidelines will most probably require
CA's to issue semi-anonymous certificates containing a pseudonym
instead of the subjects real name. This is fine.

Now, if a CA want's  to issue a pseudonym-certificate, it will somehow
like to or have to mark this as being a pseudonym. One way to do this
would be to change the DN. Ideally there should be a standard way to do that
in any case. Has there been any discussion about that - or any opinions on
that?

I believe that anything outside the DN would not be visible to the user of
such a
cert, while OTOH I'd prefer a special extension technically.

Ideas, opinions?

Peter

------=_NextPart_000_00B1_01BD8836.5F408F80
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00B1_01BD8836.5F408F80--

From: Charles Moore <[email-masked]>
To: "PKIX (E-mail)" <[email-masked]>
Subject: Previous message
Date: Mon, 25 May 1998 13:20:17 +1000
Sender: [email-masked]

Sorry, wrong list.

Charles Moore 
Signet Systems Pty Ltd 
Phone: +61 7 3256 7465. 

From: Charles Moore <[email-masked]>
To: "'PKIX (E-mail)'" <[email-masked]>
Subject: Recall: ORA v3 Comments on new material
Date: Mon, 25 May 1998 13:19:52 +1000
Expiry-Date: Wed, 27 May 1998 13:19:13 +1000
Sender: [email-masked]

Charles Moore would like to recall the message, "ORA v3 Comments on new
material".

From: Charles Moore <[email-masked]>
To: "PKIX (E-mail)" <[email-masked]>
Subject: ORA v3 Comments on new material
Date: Mon, 25 May 1998 13:13:49 +1000
Sender: [email-masked]

Comment: Delete new material.
Rational: ORA or RA functions do NOT issue CRLs' this si ONLY the
function of the OCA or CA function.
A ORA/RA can process a revocation request to the OCA/CA.

Certificate Revocations
The Registration Function shall on the authenticated request of a
certificate holder send a revocation notice direct to the Certificate
Revocation List of the CA, or else to the appropriate receiver at the
CA.
A request shall be authenticated by
being signed by the secret key corresponding to the public key in the
certificate
the inclusion of secret information agreed at the time of registration
being physically signed by the person that signed the application for
the certificate

Charles Moore 
Signet Systems Pty Ltd 
Phone: +61 7 3256 7465. 

From: Nilsson Hans <[email-masked]>
To: [email-masked]
Subject: Key Usage for for Authentication and digitalSignature
Date: Sat, 23 May 1998 11:57:15 +0100
Sender: [email-masked]

In pkix-part1-07, section 4.2.1.3 Key Usage it says:

"For example, when an RSA key should be used only for signing, the
digitalSignature and nonRepudation bits would be asserted" 
and also "The digitalSignature bit is asserted when the subject public key
is used to privde authentication". The same writing can be found in the new
ISO draft 1572 (Public Key certificates for banking. 

If understand this correctly, this introduces a possible security threat,
with the following scenario: In a user's certificate, both bits are set.
When the user is required to logon to a web server using SSL client
authentication, the server actually sends a the hash value of a false
message, instead of a random number as a challenge.  The user encrypts with
the corresponding private key, and has thus unknowingly signed the false
message.

Because of this threat, we have in Sweden come to the conclusion that the
nonRepudiation usage bit never may be combined with any other key usage. Is
this correct (and PKIX-part1-07 wrong), or have we misunderstood something
along the way?

Hans Nilsson

AU-System Network
Stockholm Sweden

Date: Fri, 22 May 1998 14:10:06 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked]
Subject: Re: Question about NS cert server
Sender: [email-masked]

> From: Russ Housley <[email-masked]>
> 
> In my opinion, a certificate that has no extensions MUST not be a version 3
> certificate.

Part 1 section 4.1.2.1 says "At a minimum, conforming implementations
shall recognize version 3 certificates."

Section 4.2.1.2 says "This extension MUST appear in all conforming CA
certificates ..."

Therefore, PKIX-conforming CAs MUST issue only v3 certificate paths and
PKIX-conforming clients MUST be able to read them.

The only reason PKIX says anything about version 1 is to recommend that
non-conforming CAs make their certs usable by old non-conforming clients
whenever possible.  What is the purpose or effect of a MUST requirement
which applies *only* to non-conforming applications?

Dave Kemp

Date: Fri, 22 May 1998 11:40:33 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Question about NS cert server
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

In my opinion, a certificate that has no extensions MUST not be a version 3
certificate.

Russ

At 03:18 PM 5/22/98 +0000, Peter Gutmann wrote:
>>In our CA implementation we decided to employ KISS methodology and stamp all
>>certificates V3.
> 
>Hmm, I think that might be W.R.O.N.G. rather than K.I.S.S. :-).  X.509v3 is
>silent on this (#include <stdgrumble.h>), but PKIX implies that if you
mark the
>cert v3 it should actually *be* v3 (it says "use version 1" rather than "MUST
>use version 1" or "SHALL use version 1", so I'm not sure whether this is
just a
>recommendation or a "must" rule).  Logic would dictate that it should be a
>"must", because anything which recodes the cert into the canonical form will
>invalidate the signature on it.
> 
>(I've cc'd this to the PKIX list for comment).
> 
>Peter.
> 
> 

Date: Fri, 22 May 1998 10:55:52 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: CHOICE OF OCSP certID syntax
Sender: [email-masked]

At 11:06 AM 5/21/98 -0400, Rich Salz wrote:
>>I still believe that a DN is a better retrieval index than a
>>key hash.

I agree.

Russ

Date: Fri, 22 May 1998 15:54:58 +0200
From: Ferdinando Ricchiuti <[email-masked]>
To: IETF <[email-masked]>
Subject: Time Stamp Protocols
Sender: [email-masked]

This is a multi-part message in MIME format.

--------------ABD31DF237C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello.
I'm developing an implementetion of IETF-PKIX-IPKI5SP (Time Stamp
Protocols) using SSLeay-0.9.0 crypto-api.
I've attached the IPKIX5ts Internet Draft because the IETF hasn't
published the new version yet.

Thanks.

-- 
+-------------------------------------------------------------------+
| Ferdinando Ricchiuti                     Computer Science Student |
+--------------------------------+----------------------------------+
| Politecnico di Torino          | phone:  +39-(0)11-5647090        |
| Dip. Automatica e Informatica  | fax:                             |
| corso Duca degli Abruzzi, 24   | e-mail: [email-masked] | 
| 10129 Torino                   |                                  |
| ITALY                          | http://www.polito.it/~fricchi/   | 
+--------------------------------+----------------------------------+

--------------ABD31DF237C
Content-Type: text/plain; charset=iso-8859-1; name="timestamp.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline; filename="timestamp.txt"

PKIX Working Group                        C. Adams(Entrust Technologies)
Internet Draft                                             P. Cain (BBN)
expires in six months                                   D. Pinkas (Bull)
                                     R. Zuccherato(Entrust Technologies)
                                                           July 29, 1997

                     Internet Public Key Infrastructure
 
                       Part V:  Time Stamp Protocols 

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

Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

This document describes the format of the data returned by a Time 
Stamp Authority and the protocols to be used when communicating with it.  
The time stamping service can be used as a Trusted Third Party (TTP) as 
one component in building reliable non-repudiation services (see 
[ISONR]).  We also give an example of how to place a signature at a 
particular point in time, from which the appropriate CRLs may be 
checked.

1.  Introduction

In order to associate a message with a particular point in time, a
Time Stamp Authority (TSA) may need to be used.  This Trusted Third 
Party provides a proof-of-existence for this particular message at an 
instant in time.  A TSA may also be used when a trusted time reference 
is required and when the local clock available cannot be trusted by all 
parties.  The TSAs role is to time stamp a message to establish 
evidence indicating the time before which the message was generated.  
This can then be used, for example, to verify that a digital signature 
was applied before the key was put on a CRL, to indicate the time of 
submission when a deadline is critical, or to indicate the time of 
transaction for entries in a log.  An exhaustive list of possible uses 
of a TSA is beyond the scope of this document. 

Document Expiration:  Jan. 29, 1998                               Page 1

2. Requirements of the TSA

The TSA is required to:
     1. include a monotonically incrementing value of the time of day 
        into its time stamp token.
     2. produce a time stamp token upon receiving a valid request from
        the requester.
     3. include within each time stamp token an identifier to 
        uniquely determine the trust and validation policy used for this
        signature.
     4. support time stamping of a hash representation of the message 
        from the requester.

3.  TSA Transactions

As the first message of this mechanism, the requesting entity requests a 
time stamping service by sending a request (which is or includes a 
TimeStampReq, as defined below) to the Time Stamping Authority.  As the 
second message, the Time Stamping Authority responds by sending a 
response (which is or includes a TimeStampToken, as defined below) to 
the requesting entity. 

Upon receiving the token, the requesting entity verifies its validity
by verifying the signature in the TimeStampToken and by verifying that
what was time stamped corresponds to what was requested to be time 
stamped.  The requester should verify that the TimeStampToken contains
the correct time, the correct TSA name, the correct data imprint and 
the correct hash algorithm OID.  Since the TSAs certificate may have 
been revoked, the appropriate ARL should be checked to verify that the 
certificate is still valid.  The token can now be used to establish a 
trusted time reference.

4. Request and Token Formats

A time stamping request is as follows.

TimeStampReq ::= SEQUENCE  {
     requester                [0] GeneralName OPTIONAL,
     reqPolicy                [1] PolicyInformation OPTIONAL,
     tsa                          GeneralName,
     messageImprint               MessageImprint  
       --a hash of the data to be time stamped              
}

The reqPolicy field, if included, indicates the policy under which the 
TimeStampToken should be provided.  PolicyInformation is defined in 
Section 4.2.1.5 of PKIX Part 1 [PKIX1].

The tsa field identifies the name of the TSA.  GeneralName is defined
in Section 4.2.1.7 of PKIX Part 1 [PKIX1].

MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }

The hash algorithm indicated in the hashAlgorithm field must be a strong

Document Expiration:  Jan. 29, 1998                               Page 2

hash algorithm.  That means that it must be one-way and collision 
resistant.  It is up to the Time Stamp Authority to decide whether or 
not the given hash algorithm is sufficient (based on the current state 
of knowledge in cryptanalysis and the current state of the art in 
computational resources, for example).  

The hashedMessage field should contain the hash of the message to be 
time stamped.  The hash is represented as an OCTET STRING.

A time stamp token is as follows.  The signature is computed over
tstInfo (encoded using the ASN.1 distinguished encoding rules (DER)).

TimeStampToken ::= SEQUENCE  {
     tstInfo                      TSTInfo,
     signature                    BIT STRING,
       --over the ASN.1 DER encoding of tstInfo   
}

TSTInfo ::= SEQUENCE  {
     policy                       PolicyInformation,
     status                       PKIStatusInfo,
     requester               [0]  GeneralName OPTIONAL,
       --must be present if the requester field is present in 
       --TimeStampReq
     tsa                          GeneralName,
     signatureAlgorithm           AlgorithmIdentifier,
     certId                       CertId,
       --must refer to the TSAs public verification certificate
     certs                        SEQUENCE OF Certificate OPTIONAL,
     genTime                      GeneralizedTime,
     messageImprint               MessageImprint
       --this field must have the same value as the similar field
       --in TimeStampReq                             
}

PKIStatusInfo is defined in Section 3.2.3 of PKIX Part 3 [PKIX3].  The
status field is present to indicate whether or not the time stamping 
request was fulfilled and, if not, the reason it was rejected. A valid 
time stamp token will always have value 0 (granted) in the PKIStatus 
field of PKIStatusInfo.

CertId is defined in Section 3.2.4 of PKIX Part 3 [PKIX3].

5. Time Stamp Protocol Using E-mail

This section specifies a means for conveying ASN.1-encoded messages 
for the protocol exchanges described in Section 4 via Internet mail. 

A simple MIME object is specified as follows.

   Content-Type: application/x-pkix5
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded PKIX-5 message, base64-encoded>>

This MIME object can be sent and received using common MIME processing 

Document Expiration:  Jan. 29, 1998                               Page 3

engines and provides a simple Internet mail transport for PKIX-5 
messages.

7. Security Considerations

When designing a TSA service, the following considerations have been 
identified that have an impact upon the validity or trust in the time 
stamp token.

     1. The TSA private key is compromised and the corresponding 
        certificate is revoked.  In this case, any token signed by the 
        TSA using that private key cannot be trusted.  For this reason, 
        it is imperative that the TSAs private key be guarded with 
        proper security and controls in order to minimize the 
        possibility of compromise.  In case the private key does become
        compromised, an audit trail of all tokens generated by the TSA
        may provide a means to discriminate between genuine and false 
        tokens.

     2. The TSA signing key must be of a sufficient length to allow for 
        a sufficiently long lifetime.  Even if this is done, the key 
        will have a finite lifetime.  Thus, any token signed by the TSA 
        should be time stamped again at a later date to renew the trust 
        that exists in the TSAs signature. 

8. References

[ISONR] ISO/IEC 10181-5:  Security Frameworks in Open Systems.  
Non-Repudiation Framework.

[PKIX1] R. Housley, W. Ford, W. Polk, D. Solo, Internet Public Key
Infrastructure, Part I:  X.509 Certificate and CRL Profile, draft-
ietf-pkix-ipki-part1-0X.txt, 1997 (work in progress).

[PKIX3] C. Adams, S. Farrell, Internet Public Key Infrastructure, Part
III:  Certificate Management Protocols, draft-ietf-pkix-ipki3cmp-
0X.txt, 1997 (work in progress).

9. Authors Addresses

Carlisle Adams                        Pat Cain
Entrust Technologies                  BBN
750 Heron Road, Suite 800             70 Fawcett Street
Ottawa, Ontario                       Cambridge, MA 02138
K1V 1A7                               U.S.A.
CANADA                                [email-masked]
[email-masked]

Denis Pinkas                          Robert Zuccherato
Bull S.A.                             Entrust Technologies
Rue Jean Jaures                       750 Heron Road, Suite 800
B.P. 68                               Ottawa, Ontario
78340 Les Clayes sous Bois            K1V 1A7
FRANCE                                CANADA
[email-masked]                 [email-masked]

Document Expiration: Jan. 29, 1998                                Page 4

APPENDIX A - Storage of Data and Token

A time stamp token is meaningless without its associated data.  Thus, a 
method is required to allow users to store the data and token together 
securely.  They may be stored as a PKCS #7 SignedData object as 
described in [PKCS7].  That is, the contentType is signedData and 
contentInfo is Data, which contains the message associated with the time 
stamp token.  The SignedData object is signed by the person storing the 
data and token.  

For this purpose, we define a PKCS #9 [PKCS9] time stamp token attribute 
type.  This attribute type specifies the time stamp token, which must be 
included as an authenticated attribute of the SignedData object.  The 
time stamp token attribute type has ASN.1 type TimeStampToken (as 
defined in Section 4 of this document).  A time stamp token attribute 
can have a single attribute value.

The object identifier timeStampToken identifies the time stamp token 
attribute type.

timeStampToken ::= { pkcs-9 n <<To be supplied>> }

[PKCS7] RSA Laboratories, The Public-Key Cryptography Standards
(PKCS), RSA Data Security Inc., Redwood City, California, November
1993 Release.

[PKCS9] RSA Laboratories, The Public-Key Cryptography Standards
(PKCS), RSA Data Security Inc., Redwood City, California, November
1993 Release.

APPENDIX B - Placing a Signature At a Particular Point in Time

We present an example of a possible use of this general time stamping
service. It places a signature at a particular point in time, from 
which the appropriate CRLs must be checked.  This application is 
intended to be used in conjunction with evidence generated using a 
digital signature mechanism. 

Signatures can only be verified according to a non-repudiation policy. 
This policy may be implicit or explicit (i.e., indicated in the 
evidence provided by the signer). The non-repudiation policy can 
specify, among other things, the time period allowed by a signer to 
declare the compromise of a signature key used for the generation of 
digital signatures. Thus a signature may not be guaranteed to be valid 
until the termination of this time period.  

To verify a signature that incorporates an untrusted time, the following 
basic technique may be used: 

A) Time stamping information needs to be obtained by the signer or 
a verifier.

     1) The signature is presented to the Time Stamping Authority (TSA).  
        The TSA then returns a TimeStampToken (TST) upon that signature.

Document Expiration: Jan. 29, 1998                                Page 5

     2) The invoker of the service must then verify that the 
        TimeStampToken is correct.

B) The validity of the evidence must be verified :

     1) The date/time indicated by the signer in the signature shall be 
        compared with the date/time in the TST. If they are not close 
        enough (e.g., less than a few hours) the evidence is considered 
        to be invalid.  

2) The certificate included in the signed message should be 
        verified to be valid at the time of the signature. It must 
        first be verified and then the appropriate CRL must be 
        checked.

The signature has now been placed at a particular point in time.  The
appropriate CRLs may be examined to determine the validity of the 
signature at that time.

Document Expiration: Jan. 29, 1998                                Page 6

--------------ABD31DF237C--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Question about NS cert server
Cc: [email-masked]
Reply-To: [email-masked]
Date: Fri, 22 May 1998 15:18:31 (NZST)
Sender: [email-masked]

>In our CA implementation we decided to employ KISS methodology and stamp all
>certificates V3.
 
Hmm, I think that might be W.R.O.N.G. rather than K.I.S.S. :-).  X.509v3 is
silent on this (#include <stdgrumble.h>), but PKIX implies that if you mark the
cert v3 it should actually *be* v3 (it says "use version 1" rather than "MUST
use version 1" or "SHALL use version 1", so I'm not sure whether this is just a
recommendation or a "must" rule).  Logic would dictate that it should be a
"must", because anything which recodes the cert into the canonical form will
invalidate the signature on it.
 
(I've cc'd this to the PKIX list for comment).
 
Peter.

Date: Thu, 21 May 1998 12:31:35 -0700
To: [email-masked] (David P. Kemp), [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: CHOICE OF OCSP certID syntax
Sender: [email-masked]

Dave,

At 10:15 AM 5/21/98 -0400, David P. Kemp wrote:
>As discussed here previously, the cert hash by itself
>may be insufficient to serve as a retrieval index.

I recall Steve discussing a hash of the CA's key:

>While the hash of a CA's key would likely be unique, it also is a terrible
>search key in many instances. One has to be careful about the context in
>which a pointer to a CA cert is being used. In a cert, having a CA "key ID"
>that is based on the hash of the CA is fine, because we already have the CA
>name, and maybe even a locator.  In other protocol context we should have a
>similar level of naming for search purposes, and rely on something like a
>key hash just for disambiguation among multiple possible keys associated
>with the same CA.

but this doesn't speak to a hash of the subject certificate.

Do I take your response to be against the CHOICE generally?  There is
benefit to the installed base of systems that are successfully using the
{Issuer DN, subject serial number} model of certificate identification.

Mike

Date: Thu, 21 May 1998 10:33:35 -0700
To: Michael Myers <[email-masked]>, [email-masked]
From: Deepak Nadig <[email-masked]>
Subject: Re: CHOICE OF OCSP certID syntax
Sender: [email-masked]

Mike,

At 02:13 PM 5/20/98 -0700, Michael Myers wrote:
>All,
>
>We need to close on OCSP certID.  The current level of debate is
>insufficient to measure the consensus of the group.  What I've heard and
>observed so far is that the best path forward would be:
>
>CertID ::= CHOICE {
>   nameKeyAndSerial [0] NameKeyAndSerial,      -- MUST
>   nameAndSerial    [1] IssuerAndSerialNumber, -- SHOULD
>   certHash         [2] OCTET STRING }         -- SHOULD; MUST use SHA-1
>

It seems to me that since a certificate can be identified either by
{IssuerName, SerialNumber} or {IssuerAltName, SerialNumber}, CertID is
better defined as

CertID ::= SEQUENCE {
    issuerNameorAltName	IssuerNameOrAltName,
    serialNumber		CertificateSerialNumber
}

IssuerNameOrAltName ::= CHOICE {
    issuerName	IssuerName,
    issuerAltName	IssuerAltName
}

Also, I understand the CertID to be used to check the revocation status of
a certificate. If the certificate is in hand, it is simpler to use the name
and serial number. I would not recommend using a hash to represent the
certificate.

>
>+ SET uses certificate hashes in several places throughout its architecture.
>

In SET, the hashes are used mainly by the sender to notify the receiver of
the certificates possessed by it. This is more efficiently done by using
hashes, since they can be stored along with the certificates. Using any
data elements in the certificate would require decoding of every certificate.

This brings up a point with OCSP. Section 2.2 says that the response must
be signed by a key corresponding either to 

1. the CA key that issued the certificate, or
2. a key trusted by the OCSP client

How is this guaranteed when either (or both) keys are compromised ? Isn't
it necessary then for the OCSP client to notify the OCSP server of the keys
it trusts ?

Also, is the mechanism of updating the OCSP client with a new trusted key,
when the old one is compromised, within the scope of OCSP ?

Deepak

----------------------------------------------------------------------------
Deepak Nadig							email: [email-masked]
Technology Group						Phone: 408-919-5618
Internet Commerce Division, VeriFone			Fax:   408-919-8807

From: [email-masked] (Gina DePlanche)
Subject: X.509 source for sale
To: [email-masked]
Date: Thu, 21 May 1998 12:14:36 -0400 (EDT)
Sender: [email-masked]

	Hi!

	I hope it's OK to send mail to the group in this way. I'll keep
it short.

	My company is looking to implement X.509 certificates in our
router product. We are weighing the option of purchasing software versus
implementing it in-house.

	If anyone on the list works for a company which sells X.509
source code, or know of a company, I'd appreciate hearing from you.

	Thank you for your time,
	Gina

-- 
Gina M. DePlanche               |       OpenROUTE Networks, Inc.
[email-masked]               |       A subsidiary of Proteon, Inc.
(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
Fax: (508) 836-5347             |       01581-1799  MailStop #23

Date: Thu, 21 May 1998 11:06:31 -0400 (EDT)
From: Rich Salz <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: CHOICE OF OCSP certID syntax
Sender: [email-masked]

>I still believe that a DN is a better retrieval index than a
>key hash.

Me too.
	/r$

Date: Thu, 21 May 1998 10:15:51 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: CHOICE OF OCSP certID syntax
Sender: [email-masked]

> From: Michael Myers <[email-masked]>
> 
> We need to close on OCSP certID.  The current level of debate is
> insufficient to measure the consensus of the group.  What I've heard and
> observed so far is that the best path forward would be:
> 
> CertID ::= CHOICE {
>    nameKeyAndSerial [0] NameKeyAndSerial,      -- MUST
>    nameAndSerial    [1] IssuerAndSerialNumber, -- SHOULD
>    certHash         [2] OCTET STRING }         -- SHOULD; MUST use SHA-1
> 
> IssuerAndSerialNumber ::= SEQUENCE {
>     issuer        Name,
>     serialNumber  SerialNumber }
> 
> SerialNumber ::= INTEGER
> 
> NameKeyAndSerial  ::= SEQUENCE {
>    issuerNameAndKey     IssuerNameAndKey,
>    serialNumber         CertificateSerialNumber }
> 
> IssuerNameAndKey ::= SEQUENCE {
>    issuer			Name,
>    issuerAltName	[0]	EXPLICIT IssuerAltName OPTIONAL,
>    keyIdentifier		KeyIdentifier }

Mike,

I agree with Brian that certHash should be dropped.

The S/MIME discussions have identified certHash as a signed attribute
to provide cryptographic binding between the signed content and the
specific cert used for signing.  However, CMS also includes a mandatory
unprotected issuerAndSerialNumber field which selects the signer's cert
in the first place, before the optional hash attribute is used to
confirm it.  As discussed here previously, the cert hash by itself may
be insufficient to serve as a retrieval index.

With regard to nameKeyAndSerial, I don't see how:

  { issuer Name, [issuerAltName], keyIdentifier, serialNumber }

offers any advantage at all over:

  { issuer Name, [issuerAltName], serialNumber }

In other words, keyIdentifier doesn't provide any selection advantage
when added to issuerAndSerialNumber, and it doesn't provide any
cryptographic advantage either.  So nameKeyAndSerial should be dropped
too.

Since OPTIONAL always makes the developer's job harder, and since
procedures for handling issuer altNames in path processing do not
currently exist, I would prefer to leave out issuerAltName too.  But
I don't want to hold up OCSP until the path processing debate works
itself out, so I'd reluctantly accept an OPTIONAL issuerAltName.

I am very sympathetic to Slava Galperin's proposal that:

  { Hash(IssuerPublicKey), serialNumber }

is sufficient to uniquely identify a cert, neatly sidesteps the altName
debate, and saves space.  I'd also note that it has a very SPKI-like
flavor, which may be regarded as an advantage or a disadvantage :-).
However, I still believe that a DN is a better retrieval index than a
key hash.  I'll defer to the directory experts on how difficult it
would be to implement matches based on the hash of the issuer's public
key.  Conceptually it is simple.  If it is also simple in practice, I
would support this proposal.

Here are three alternatives:

-- Bad

  CertID ::= SEQUENCE {
     issuer            Name,
     issuerAltName [0] EXPLICIT IssuerAltName OPTIONAL,
     serialNumber      CertificateSerialNumber,
     issuerKeyHash     IssuerKeyHash }

-- Better

  CertID ::= SEQUENCE {
     serialNumber    CertificateSerialNumber,
     issuerKeyHash   IssuerKeyHash }

-- Best

  CertID ::= SEQUENCE {
     issuer          Name,
     serialNumber    CertificateSerialNumber,
     issuerKeyHash   IssuerKeyHash }

  IssuerKeyHash ::= SEQUENCE {
     algorithmId     AlgorithmIdentifier,
     hashValue       OCTET STRING }  -- hash of issuer's subjectPublicKeyInfo
                                     -- with applicable parameters present

Date: Wed, 20 May 1998 16:00:20 -0700
To: Brian Korver <[email-masked]>, [email-masked] (Michael Myers)
From: Michael Myers <[email-masked]>
Subject: Re: CHOICE OF OCSP certID syntax
Cc: [email-masked]
Sender: [email-masked]

Brian,

Thanks for the insight into the SET requirements.

Mike

At 02:52 PM 5/20/98 -0700, Brian Korver wrote:
>Mike,
>
>A couple of comments....
>
>Michael Myers writes:
>> 
>> All,
>> 
>> We need to close on OCSP certID.  The current level of debate is
>> insufficient to measure the consensus of the group.  What I've heard and
>> observed so far is that the best path forward would be:
>> 
>> CertID ::= CHOICE {
>>    nameKeyAndSerial [0] NameKeyAndSerial,      -- MUST
>>    nameAndSerial    [1] IssuerAndSerialNumber, -- SHOULD
>>    certHash         [2] OCTET STRING }         -- SHOULD; MUST use SHA-1
>
>Sorry if I haven't been paying close enough attention, but what is the
>argument for not including an algorithm OID for certHash?  It seems
>short-sighted to me to leave it out.
>
>That said, I'm in favor of dropping certHash.
>
>
>> 
>> If you have an opinion on this, if only YES or NO, please put it to the
>> list, although read on a bit before you make up your mind.
>> 
>> The question is not if there *should* be a single, unified method to
>> identify a certificate but rather *will* there be?  I'm coming to doubt it:
>> 
>> + In the good old days, Issuer DN and certificate serial number were
>> sufficient (and still are when operating strictly within a closed PKI).
>> 
>> + SET uses certificate hashes in several places throughout its
architecture.
>
>Sort of.  SET does not use hashes of certificates, but rather hashes
>of the inner content of certificates.  This is a bad idea because it
>requires that the certificate be (at least partially) decoded before
>it can be hashed.  
>
>Having implemented SET, I haven't found the certificate hash construct to
>be any improvement on Issuer+Serial and I would prefer the simplicity of
>fewer choices.  
>
>
>
>> 
>> + The {issuer name, hash of public key, certificate serial number} of the
>> current OCSP draft is on the table.
>> 
>> + Many applications today already display a hash to enable users to
>> directly match a certificate's "fingerprint" to a store of certificates.
>> This speaks to the utility of a manual, cut-and-paste query capability.
>> 
>> + Recent discussions in the S/MIME group have identified a certificate hash
>> as a candidate mechanism for their SigningCertificate attribute (which
>> binds a specific certificate to a signed message).
>> 
>> If somebody believes that all of these contexts will change to a single,
>> unified certificate identification scheme I'd love to hear of it and why
>> you think so.  I'm willing to be convinced.  But, looking at this
>> diversity, it only makes sense to me to put in a CHOICE and let profiling
>> activity govern futher evolution.
>
>Forget about SET -- it uses Issuer+Serial in all the normal places, and
>its certificate hash is unique, I believe, to SET.
>
>
>> 
>> This will allow us to advance OCSP without risking a disconnect between
>> PKIX and other groups or other non-IETF contexts, while at the same time
>> maintaining the current level of consensus on certificate identification.
>> It also benefits potential early adopters of this technology who want to
>> keep their options open while PKI solutions evolve and converge.  Last,
>> there are a few brave souls out there who produced and are operating
>> prototype versions of OCSP-02.  The proposed CHOICE enables them to reuse
>> much of their existing architecture should they wish to advance their
>> existing pilots forward (modulo a bit of ASN.1 wrapping).
>> 
>> The rest of the syntax would look like:
>> 
>> IssuerAndSerialNumber ::= SEQUENCE {
>>     issuer        Name,
>>     serialNumber  SerialNumber }
>> 
>> SerialNumber ::= INTEGER
>> 
>> NameKeyAndSerial  ::= SEQUENCE {
>>    issuerNameAndKey     IssuerNameAndKey,
>>    serialNumber         CertificateSerialNumber }
>> 
>> IssuerNameAndKey ::= SEQUENCE {
>>    issuer			Name,
>>    issuerAltName	[0]	EXPLICIT IssuerAltName OPTIONAL,
>>    keyIdentifier		KeyIdentifier }
>> 
>> Mike
>> 
>> 
>
>
>brian
>[email-masked]
>
>

From: Brian Korver <[email-masked]>
Subject: Re: CHOICE OF OCSP certID syntax
To: [email-masked] (Michael Myers)
Date: Wed, 20 May 1998 14:52:53 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

Mike,

A couple of comments....

Michael Myers writes:
> 
> All,
> 
> We need to close on OCSP certID.  The current level of debate is
> insufficient to measure the consensus of the group.  What I've heard and
> observed so far is that the best path forward would be:
> 
> CertID ::= CHOICE {
>    nameKeyAndSerial [0] NameKeyAndSerial,      -- MUST
>    nameAndSerial    [1] IssuerAndSerialNumber, -- SHOULD
>    certHash         [2] OCTET STRING }         -- SHOULD; MUST use SHA-1

Sorry if I haven't been paying close enough attention, but what is the
argument for not including an algorithm OID for certHash?  It seems
short-sighted to me to leave it out.

That said, I'm in favor of dropping certHash.

> 
> If you have an opinion on this, if only YES or NO, please put it to the
> list, although read on a bit before you make up your mind.
> 
> The question is not if there *should* be a single, unified method to
> identify a certificate but rather *will* there be?  I'm coming to doubt it:
> 
> + In the good old days, Issuer DN and certificate serial number were
> sufficient (and still are when operating strictly within a closed PKI).
> 
> + SET uses certificate hashes in several places throughout its architecture.

Sort of.  SET does not use hashes of certificates, but rather hashes
of the inner content of certificates.  This is a bad idea because it
requires that the certificate be (at least partially) decoded before
it can be hashed.  

Having implemented SET, I haven't found the certificate hash construct to
be any improvement on Issuer+Serial and I would prefer the simplicity of
fewer choices.  

> 
> + The {issuer name, hash of public key, certificate serial number} of the
> current OCSP draft is on the table.
> 
> + Many applications today already display a hash to enable users to
> directly match a certificate's "fingerprint" to a store of certificates.
> This speaks to the utility of a manual, cut-and-paste query capability.
> 
> + Recent discussions in the S/MIME group have identified a certificate hash
> as a candidate mechanism for their SigningCertificate attribute (which
> binds a specific certificate to a signed message).
> 
> If somebody believes that all of these contexts will change to a single,
> unified certificate identification scheme I'd love to hear of it and why
> you think so.  I'm willing to be convinced.  But, looking at this
> diversity, it only makes sense to me to put in a CHOICE and let profiling
> activity govern futher evolution.

Forget about SET -- it uses Issuer+Serial in all the normal places, and
its certificate hash is unique, I believe, to SET.

> 
> This will allow us to advance OCSP without risking a disconnect between
> PKIX and other groups or other non-IETF contexts, while at the same time
> maintaining the current level of consensus on certificate identification.
> It also benefits potential early adopters of this technology who want to
> keep their options open while PKI solutions evolve and converge.  Last,
> there are a few brave souls out there who produced and are operating
> prototype versions of OCSP-02.  The proposed CHOICE enables them to reuse
> much of their existing architecture should they wish to advance their
> existing pilots forward (modulo a bit of ASN.1 wrapping).
> 
> The rest of the syntax would look like:
> 
> IssuerAndSerialNumber ::= SEQUENCE {
>     issuer        Name,
>     serialNumber  SerialNumber }
> 
> SerialNumber ::= INTEGER
> 
> NameKeyAndSerial  ::= SEQUENCE {
>    issuerNameAndKey     IssuerNameAndKey,
>    serialNumber         CertificateSerialNumber }
> 
> IssuerNameAndKey ::= SEQUENCE {
>    issuer			Name,
>    issuerAltName	[0]	EXPLICIT IssuerAltName OPTIONAL,
>    keyIdentifier		KeyIdentifier }
> 
> Mike
> 
> 

brian
[email-masked]

Date: Wed, 20 May 1998 14:13:20 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: CHOICE OF OCSP certID syntax
Sender: [email-masked]

All,

We need to close on OCSP certID.  The current level of debate is
insufficient to measure the consensus of the group.  What I've heard and
observed so far is that the best path forward would be:

CertID ::= CHOICE {
   nameKeyAndSerial [0] NameKeyAndSerial,      -- MUST
   nameAndSerial    [1] IssuerAndSerialNumber, -- SHOULD
   certHash         [2] OCTET STRING }         -- SHOULD; MUST use SHA-1

If you have an opinion on this, if only YES or NO, please put it to the
list, although read on a bit before you make up your mind.

The question is not if there *should* be a single, unified method to
identify a certificate but rather *will* there be?  I'm coming to doubt it:

+ In the good old days, Issuer DN and certificate serial number were
sufficient (and still are when operating strictly within a closed PKI).

+ SET uses certificate hashes in several places throughout its architecture.

+ The {issuer name, hash of public key, certificate serial number} of the
current OCSP draft is on the table.

+ Many applications today already display a hash to enable users to
directly match a certificate's "fingerprint" to a store of certificates.
This speaks to the utility of a manual, cut-and-paste query capability.

+ Recent discussions in the S/MIME group have identified a certificate hash
as a candidate mechanism for their SigningCertificate attribute (which
binds a specific certificate to a signed message).

If somebody believes that all of these contexts will change to a single,
unified certificate identification scheme I'd love to hear of it and why
you think so.  I'm willing to be convinced.  But, looking at this
diversity, it only makes sense to me to put in a CHOICE and let profiling
activity govern futher evolution.

This will allow us to advance OCSP without risking a disconnect between
PKIX and other groups or other non-IETF contexts, while at the same time
maintaining the current level of consensus on certificate identification.
It also benefits potential early adopters of this technology who want to
keep their options open while PKI solutions evolve and converge.  Last,
there are a few brave souls out there who produced and are operating
prototype versions of OCSP-02.  The proposed CHOICE enables them to reuse
much of their existing architecture should they wish to advance their
existing pilots forward (modulo a bit of ASN.1 wrapping).

The rest of the syntax would look like:

IssuerAndSerialNumber ::= SEQUENCE {
    issuer        Name,
    serialNumber  SerialNumber }

SerialNumber ::= INTEGER

NameKeyAndSerial  ::= SEQUENCE {
   issuerNameAndKey     IssuerNameAndKey,
   serialNumber         CertificateSerialNumber }

IssuerNameAndKey ::= SEQUENCE {
   issuer			Name,
   issuerAltName	[0]	EXPLICIT IssuerAltName OPTIONAL,
   keyIdentifier		KeyIdentifier }

Mike

Date: Wed, 20 May 1998 14:20:25 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[email-masked]>
Reply-To: Anne Anderson - Sun Microsystems <[email-masked]>
Subject: Use of URIs in PKIX 1
To: [email-masked]
Sender: [email-masked]

Excuse me if this was hashed to death on an old thread...

I don't understand the PKIX 1 semantics for alternative names that contain
URI's.

4.2.1.7  Subject Alternative Name

   Where the subjectAltName extension contains a uniformResourceIdentif-
   ier, the URI is a pointer to a sequence of certificates issued by
   this CA (and optionally other CAs) to this subject.

Presumably, we are looking at a certificate that has some "issuer" or
"issuerAltName", may have an empty "subject", and has a "subjectAltName"
something like "http://host/x/y/z".

Does "this CA" mean "issuer/issuerAltName"?
 
Why do we want "a pointer to a sequence of certificates" issued by
"issuer/issuerAltName" to "subject/subjectAltName" when we are looking
at just such a certificate?  Is it for getting certificates for other
key usages, more current certificates, a certification path, or what?

And if "subject" is empty, is the "subject/subjectAltName" being certified as
associated with this public key actually "http://host/x/y/z"?

   The URI must be an absolute, not relative, pathname and must specify
   the host. This specification recognizes the following values for the
   URI scheme:  ftp, http, ldap, and mailto.  The mailto scheme indi-
   cates that mail sent to the specified address will generate an elec-
   tronic mail response (to the sender) containing the subject's certi-
   ficates.  No message is required.  If the URI scheme is ftp, then the
   information is available through anonymous ftp.  If the URI scheme is
   http or ldap, then the information may be retrieved using that proto-
   col.
   
So, if my "subjectAltName" is "mailto:[email-masked]", then this is
an alias for obtaining another copy of my certificate(s), but not an
address at which you can send me personally e-mail?

4.2.1.8 Issuer Alternative Name

   Where the issuerAltName extension contains a URI, the following
   semantics shall be assumed: the URI is a pointer to an ASN.1 sequence
   of certificates issued to this CA (and optionally other CAs).  The
   expected values for the URI are those defined in 4.2.1.7. Processing
   rules for other values are not defined by this specification.

"this CA" means the CA represented by "issuerAltName"?  Presumably, the
only certificates for "other CAs" stored there would be certificates in
a certification path leading down to "issuerAltName", right?

Anne Anderson                 Email: [email-masked]
Sun Microsystems Laboratories   Tel: (978) 442-0928
2 Elizabeth Drive, UCHL03-205   Fax: (978) 250-5067
Chelmsford, MA 01824 USA

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: Role names in certificates
Date: Tue, 19 May 1998 12:51:57 -0700
Sender: [email-masked]

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 19, 1998 10:23 AM
> To: [email-masked]
> Subject: Re: Role names in certificates
> 
> Although the use of human-readable role names (i.e. "Sales Director of
> Delta Company") may be somewhat useful when a human is making 
> the access
> decision, coded-field attributes (role 27 = "Sales Director") impose a
> rigor on the definition of a set of roles and what each role is
> intended to authorize.  Coded-field attributes require more up-front
> planning than free-form strings; I regard that as an 
> advantage of using
> attributes instead of names.

One of the considerations for the first cut of the role names was to
have specific strings that mapped into subjectAltName.  Thinking from
the point of view of an S/MIME vendor, the display of the subjectAltName
is correct (that is, S/MIME user agents simply display the exact string,
and the user figures out what to do with it).

A suggestion that has come up in private mail is to use the extended key
usage attribute to define a set of roles (I believe that this is
consistent with the "coded-field attributes" that you mentioned).
Unfortunately, in the event that a user agent does not understand a
particular coded field, the human operator cannot be given context, as
you indirectly point out.

Could this be work for both humans and non-humans by using a hybrid --
specifying human-readable information in the subjectAltName, and then
providing extendedKeyUsage OIDs to match?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Tue, 19 May 1998 13:23:02 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Role names in certificates
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
>
> At 05:18 PM 5/15/98 -0700, Denis Pinkas wrote:
> >I wonder why should we attach such an attribute in this way. I
> >believe/believed that AC (Attribute Certificates) should be used for
> >that. 
> 
> AC's could be used for this, but I think it would be good to have the
> option for clients and servers that do not understand ACs to understand
> semantics in these names.

The question is really the use of Attributes to enable Role Based
Access Control (RBAC), as opposed to using special forms of subject
Name (or altName) for RBAC, and as opposed to using Name in conjunction
with Access Control Lists (ACLs) for Identity Based Access Control
(IBAC).

Discussing Attribute Certificates is a red herring at this point.
Attributes may be contained only in a directory, or may be included in the
user's Certificate, or may be included in Attribute Certificates; the
choice of where to carry the attribute is "just" a management issue.

Although the use of human-readable role names (i.e. "Sales Director of
Delta Company") may be somewhat useful when a human is making the access
decision, coded-field attributes (role 27 = "Sales Director") impose a
rigor on the definition of a set of roles and what each role is
intended to authorize.  Coded-field attributes require more up-front
planning than free-form strings; I regard that as an advantage of using
attributes instead of names.

Dave Kemp

From: [email-masked]
To: Stephen Kent <[email-masked]>
cc: [email-masked]
Date: Tue, 19 May 1998 07:30:10 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Stephen Kent <[email-masked]> writes (in response to Bob Jueneman):

>>Another point of view, which I know that VeriSign supports, and
>>in particular Michael Baum, their VP for Practices and also the
>>chairman of the ABA group that wrote the Digital Signature Guidelines,
>>is that the definition of what is verified and what is not verified in a
>>certificate
>>can and should be defined in the CA's Certification Practice Statement.
>>And certainly VeriSign's current practices allow the user to add
information
>>(such as SSN, DOB, etc.) that may be of questionable utility, but cannot
>>reasonably be verified by the CA.
>
>I respect Mike, and he's a good friend, but this approach is not amenable
>to easy automatic processing of certs.  It is a lawyers approach, and the
>approach that a public CA, which is authoritative for nothing, would be
>expected to adopt.

No - it can be processed automatically, provided there's a distinction made
in the certificate between non-verified identification information and
verified names, suitable for being used for chaining purposes.  I think
this is Bob's position - he's advocating treating all altName stuff as
non-chaining, and requiring the presence of a DN to be used to build the
trust chain.  Under this model, the altNames are only used in the subject
field of the last certificate in a trust chain (which can be a CA, if
that's where your chain leads), and are considered notarized by the final
CA but not verified (unless that CA's CPS says they have been verified).

It's a different model from the one I think you are proposing, but it's no
less amenable to automated processing.

Now, if nobody wants to put "hints" or other non-chaining identification
data in a cert, and only wants strongly verified names, there's no need for
Bob's approach (assuming we can sort out the semantics of verified
altNames), but I've certainly heard people expressing a desire to put
things like personal e-mail addresses (things that wouldn't necessarily be
verifiable by a CA) in their certs.  The PKIX-1 document's description of
the URI name-type sounds as though it would be impossible for a CA for
verify properly, and is more intended as a hint to the verifying party as
to where to go to find more certificates.  I don't see how we can support
both sets of semantics with a single altName extension.

John

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Patent 5745574 on PKI
Reply-To: [email-masked]
Date: Tue, 19 May 1998 16:06:27 (NZST)
Sender: [email-masked]

>Fyi  ... fairly new patent on PKI.  See attachement and URL:
>
>      http://www.patents.ibm.com/details?patent_number=5745574
>
>Security infrastructure for electronic transactions (Assignee -- Entegrity 
>Solutions Corporation)
 
>From the claims it looks like they're trying to patent the PEM infrastructure 
model, several years too late (filing date December 1995, "inventor" is Sead 
Muftic).  The patent gives the latest PEM RFC's and "RGP 2.6.2" as a 
reference, but nothing much else.  I know the USPTO will allow you to patent 
anything regardless of novelty or prior art, but given that the claims match 
the RFC's given in the references which predate the patent by some years, you 
have to wonder how they got away with this one.
 
Peter.

From: "Paul Lambert" <[email-masked]>
To: [email-masked]
Date: Mon, 18 May 1998 17:20:47 -0700
Subject: Patent 5745574 on PKI
Sender: [email-masked]

Fyi  ... fairly new patent on PKI.  See attachement and URL:

      http://www.patents.ibm.com/details?patent_number=5745574

Another interesting older one covers hierarchical key management :

       http://www.patents.ibm.com/details?patent_number=4888801

Paul
------
Security infrastructure for electronic transactions (Assignee -- Entegrity
Solutions Corporation)

May 15, 1998

U.S. Patents via NewsEdge Corporation : Abstract:
A plurality of certification authorities connected by
an open network are interrelated through an
authentication and certification system for providing
and managing public key certificates. The
certification system with its multiple certification
and its policies constitute a public key infrastructure
facilitating secure and authentic transactions over
an unsecure network. Security services for
applications and users in the network are facilitated
by a set of common certification functions
accessible by well-defined application programming
interface which allows applications to be developed
independently of the type of underlying hardware
platforms used, communication networks and
protocols and security technologies.

Date: Mon, 18 May 1998 11:11:17 -0400
To: "Bob Jueneman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Bob,

	<snip>

>
>One point of view, which Steve apparently reflects, is that a CA should be
>absolutely responsible/liable for every single element contained in the
>certificate. In that case, of course, a CA would be compelled to do its
>due diligence to verify the contents, and would strongly resist including
>anything it couldn't reasonably verify, for fear of unwanted and
>unwarranted liability.
>
>Another point of view, which I know that VeriSign supports, and
>in particular Michael Baum, their VP for Practices and also the
>chairman of the ABA group that wrote the Digital Signature Guidelines,
>is that the definition of what is verified and what is not verified in a
>certificate
>can and should be defined in the CA's Certification Practice Statement.
>And certainly VeriSign's current practices allow the user to add information
>(such as SSN, DOB, etc.) that may be of questionable utility, but cannot
>reasonably be verified by the CA.

I respect Mike, and he's a good friend, but this approach is not amenable
to easy automatic processing of certs.  It is a lawyers approach, and the
approach that a public CA, which is authoritative for nothing, would be
expected to adopt.

>My own point of view is in the middle.  If I feel the need to include my
>height,
>weight, hair color, skin color, JPEG photo, fingerprint classification,
>etc., because
>I believe that will be beneficial to me in my own use of my certificate, that
>should be my business, at least within reason.
>
>>From a legal standpoint, I am making a representation to the CA, and hence to
>relying parties, in the expectation that someone may rely on the
>information. And
>therefore, if I misrepresent that information I might be liable for any
>damages
>encurred by someone who relied on it. So I, the subscriber/subject of the
>certificate, am on the hook.

Again, a lawyers perspective, and specvifically one based on a
"liability-empowered" CA model, as opposed to a CA model based on who
really is authoritative for name spaces.

>On the other hand, the CA shouldn't have to choose between honoring their
>customer's wishes (generally a poor business practice!) and becoming
>unnecessarily liable in their own right for apparently endorsing some
>"fact" which the subscriber represented to them if it turns out not to be
>true.
>
>At least part of the motivation for alternate subject names, therefore,
>was the
>recognition of the utility of "informational" names and/or other
>attributes, which
>the CA might or might not choose to independently validate.
>
>In retrospect, the semantics of these name forms was not thought through
>carefully
>enough, and now we have this argument.

There are differing views on the use of AltNames.

>My preference would be to clearly indicate what attributes were validated
>by the CA
>and which were not, though the use of a Nonverified Subscriber Information
>flag,
>and as a vendor of a CA toolkit which can both create certificates itself
>and pass them
>on to external CAs to be signed, that is exactly what we are going to
>provide for
>certain attributes.  The major (and minor) CAs can then decide whether or
>not to
>accept and sign such attributes, and we will let the market decide what
>people want.

You've made this suggestion many time, and it has been been persusive.
Given the problems we already have with folks interpreting the "critical"
bit, adding another flag of this sort to a cert would only add further
confusion to processing.

>The only other distinction that I see between a DN and an alt name is the
>greatly
>increased complexity that ensues if it is allowable to retrieve and chain
>certificates
>based on either or both name forms.
>
>Steve works for a company that is a CA, but doesn't provide a directory
>(to my
>knowledge). Novell, on the other hand, has on the order of 80 million
>customer
>nodes (users), a vast percentage of whom make daily use of NDS, our X.500-like
>directory.  Granted that the top-down, monoply carrier imposed, everyone-is-
>connected-to-the-great-X.500-directory-in-the-sky model has never
>materialized and
>probably never will, it is still quite incorrect to assume that no one is
>using certificates
>in combination with directories, as he seems to imply.

Steve works for a company that offers directory services to millions of
individuals and businesses; they happen to be globally accessible phone
directories.  How many of your clients have their Novell directories are
connected together, Bob?  I hate to ask this, but I recall that Novell also
promulgated an addressing system (for IPX) that was notorious for not
scaling to accommodate the connection of all of the client "islands."

Steve

Date: Mon, 18 May 1998 11:00:25 -0400
To: "Bob Jueneman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

Bob,

>The only reason why I can think that you would want to break up
>a DNS name into it's constituent parts would be to try to apply name
>subordination techniques to it.  But name subordination is another
>hold-over from the PEM days, whose utility has yet to be proven.

There are several motivations for the decomposition cietd in 2247, most
obviously direct mapping to a hierarchic database structure.  As for name
subordination being an oudated notion, I suggest that the NameConstraints
extension is present precisely to support this notion in a more flexible
fashion that did RFC 1422.

>Given the lack of any obvious mapping of DNS names to an
>organization's legal name, together with the problem that complex
>organizations (like holding companies) are made up of independent
>subsidiary corporations that have no obvious name relationship
>(like EDS to GM), I believe that name subordination is nearly useless,
>both for "traditional" DNs and for DNS names as well. And completely
>useless for most e-mail names, given the tendency of people to acquire
>their e-mail addresses from an ISP that has no correspondence with their
>organization at all.

Whoever assigns an e-mail address is the owner of the part of the RFC822
name space from which it was assigned, and thus is appropriate and
authoritative.  An e-mail name, if it appears in a certificate, is what is
being vouched for, not some other form of identification of a person in a
broader context.

Steve

From: [email-masked]
To: Paul Koning <[email-masked]>
cc: [email-masked]
Date: Mon, 18 May 1998 11:06:01 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Paul Koning <[email-masked]> writes:

>John> 4 Allow any combination of DNs and altNames (although probably
>John> excluding the case of a null DN in combination with no
>John> altNames), and use them for chaining.
>
>John> Plus case 0: Require DNs and don't permit altNames for anything
>John> other than end-user subject names.
>
>Nice summary.
>
>My preference is 4.
>
>Reason: the only fundamental technical requirement I can see is that
>you have to be able to construct and verify a cert chain.  A cert
>chain is nothing more than a collection of certs Ci with issuer Ii and
>subject Si such that Ii == Si+1 (or Si-1 depending on which way you
>want to read).
>
>I see nothing in this that requires S or I to be a DN.  Nor does it
>require each cert to carry only one S and one I apiece.  To check a
>cert that carries a number of issuer (alt)names, I need another cert
>that contains at least one of those names among its subject names.
So you are picking a set of semantics that regards all altNames as
equivalent to one another, and equivalent to the DN (if present), in the
sense that any of them alone serves to name the entity, regardless of
whether the other names are asserted or verified.  So a cert with "n"
issuers and "m" subjects is merely an optimization of n.m individual 1->1
certificates that happen to contain the same key and which are signed with
the same key.

There has also been a suggestion that the sets of names have to match
exactly (rather than there just having to be an intersection).  Back in
min-April, Paul Hoffman posted a note describing a straw poll he took at
the LA IETF:

>And, let me bring up a topic again that no one responded to before:
>when validating chains on AltNames, is it the AND of all the items
>in the GeneralNames sequence, or is it the OR of them? If my
>IssuerAltName is a SEQUENCE of three rfc822Names, and you're
>comparing against a cert that has just one of those names, does
>the comparison pass or fail? In asking people in the hallways in
>LA, I got about a 50/50 split of what people thought it was.
>This alone should scare us away from using AltNames and expecting
>people writing validating code to get it right.
It's not at all clear either that none of the other obvious possibilities
(e.g. Subject(A) must be a subset of issuer(B) for A to chain to B) might
also be appropriate.

Can someone come up with an example of the sorts of uses to which a
certificate with multiple names might be put (other than an end-user cert
with multiple subject names)?  Are these examples consistent with the sorts
of things that we want to use end-user alternate subject names for?

Presumably under the intersection interpretation, the altNames would not
have to be marked critical (unless there is no DN), as a verifying party
that didn't understand how to compare altNames would "fail secure" if it
just ignored them.

Also, presumably the DN (if present) would be lumped together with any DNs
in the altName field prior to performing the intersection comparison, so
that a cert containing {subject=Fred, subjectAltName(DN)=jim} would chain
to a cert containing {issuer=Jim}.

What happens if some of the subject names fail a nameConstraints check?
For example, if a certificate has both a DN and a DNS name identifying its
subject, but the DNS name is outside the permittedSubtrees in the DNS space
(or there isn't an explicit permittedSubtree constraint for the DNS space,
but there is for the DN space, which (I think) implies a null
permittedSubtrees for all other namespaces).  Can the certificate be
verified?

Cert 0: Issuer {DN:"/C=US/O=Public CA Company (PCC)",
        Subject {DN:"/C=US/O=Iris/CN=CA"}
        permittedSubtrees {DN:"/C=US/O=Iris",
                           DNS:"Iris.com"}

Cert A: Issuer {DN:"/C=US/O=Iris/CN=CA",
                DNS:"ca.Iris.com"}
        Subject {DN:"/C=US/O=Iris/OU=Org1/CN=CA"}
        permittedSubtrees {DN:"/C=US/O=Iris/OU=Org1"}

Cert B: Issuer {DN:"/C=US/O=Iris/OU=Org1/CN=CA",
                DNS:"Org1-CA.Iris.com"}
        Subject {DN:"/C=US/O=Iris/OU=Org1/CN=Host1"}

Cert C: Issuer {DN:"/C=US/O=Iris/OU=Org1/CN=CA",
                DNS:"Org1-CA.Iris.com"}
        Subject {DNS:"host1.Org1.Iris.com"}

Cert D: Issuer {DN:"/C=US/O=Iris/OU=Org1/CN=CA",
                DNS:"Org1-CA.Iris.com"}
        Subject {DN:"/C=US/O=Iris/OU=Org1/CN=Host1",
                 DNS:"host1.Org1.Iris.com"}

Cert E: Issuer {DN:"/C=US/O=Iris/OU=Org1/CN=CA"}
        Subject {DN:"/C=US/O=Iris/OU=Org1/CN=John Wray",
                 RFC822: "[email-masked]",
                 RFC822: "[email-masked]}

Cert A is cut by the Iris CA, delegating responsibility for the OU=Org1
subtree to a secondary CA "/C=US/O=Iris/OU=Org1/CN=CA".  Cert B is
obviously verifiable by this cert.  Cert C isn't (since the subject name of
Cert C isn't compatible with Cert A's permittedSubtrees constraint).  How
about cert D, which is sort-of B and C combined into one certificate?  Is
the certificate as a whole verifiable, but the DNS subject name not?  Or is
the entire certificate thrown out?  If the former, the path processing
algorithm has now to calculate the set of "verified names" for each
certificate, rather than simply assuming that all subject names in a
verified certificate are equally valid.

Under either interpretation, it doesn't seem possible to use the
subjectAltName field to supply an RFC822 e-mail address for end-entities,
something that's often given as an example of something we'd like to be
able to do with certificates in the Internet world.  For an end-entity cert
to contain an e-mail address, RFC822 addresses would have to be explicitly
permitted in every certificate in the entire chain that contains any
nameConstraints.  So in the example above, either Cert E would fail to
verify entirely, or the RFC822 addresses in it wouldn't be included in the
"verified names" calculated for the certificate.

John

From: "Miklos, Sue A." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Role names in certificates
Date: Mon, 18 May 1998 09:05:17 -0400
Sender: [email-masked]

A few years back, we had tried to get concensus on role name
conventions, with no success.  We ended up creating (yet another)
subject directory attribute extension that contained approximately 18
"roles" and had a brief description of each role.  That way, each
organization could call their particular function anything they wanted
to, yet it mapped back to a bit set in this extension.  The empirical
evidence shows that most are mapping to about 2 or 3 of this bits,
leading me to believe we created too much granularity. However, if the
concept takes off, maybe the usage will, as well.

Sandi

>----------
>From: 	Blake Ramsdell[SMTP:[email-masked]]
>Sent: 	Friday, May 15, 1998 11:47 AM
>To: 	[email-masked]'
>Cc: 	[email-masked]'
>Subject: 	RE: Role names in certificates
>
>> -----Original Message-----
>> From: Denis Pinkas [mailto:[email-masked]]
>> Sent: Friday, May 15, 1998 5:18 PM
>> To: Blake Ramsdell
>> Cc: [email-masked]'
>> Subject: Re: Role names in certificates
>> 
>> Normally in a subjectAltName we should only describe the syntax of the
>> name, NOT the SEMANTIC of the name.
>
>This is part of what's being explored.  As you point out, attribute
>certificates may be The Right Way to express name semantics, so my
>proposal to associate semantics with subjectAltName may be a Bad Idea.
>That's part of what I'd like to figure out.  Do you have any suggestions
>as to how you might represent the semantics that I have proposed using
>an AC?  Is there a definitive source that says that altNames cannot
>express semantics?  I'm not trying to be a wise guy -- I don't have a
>good, definitive reference that shines the elusive light of X.509 truth
>on the answer.  Well, there's Peter's guide, and PKIX Part 1...
>
>In discussions on the S/MIME list, the consensus seemed to be that ACs
>had a bit of work that needed to be done before they were ready for
>prime time.  I am far from an expert on their popularity and use, so I'm
>not prepared to argue for or against them.  I just generally have a bad
>feeling about their use right now, that could very well be unfounded.
>
>> In addition, I took a look at the document again and I realized that I
>> was focussing on the word "role" too much.
>> 
>> "Role" has already some meaning for me (e.g. the case of the Sales
>> Director of the Delta Company). For the cases you consider, if this
>> document is going forward, I would rather prefer that we 
>> attempt to use
>> a different naming to avoid the confusion. Any other proposal 
>> (different
>> from simply "role") ?
>
>I agree -- there has been some confusion regarding the "sales director"
>role vs. the "domain signing authority" role.  Any suggestions welcome,
>and I will certainly scratch my head some more.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>

From: Nilsson Hans <[email-masked]>
To: [email-masked]
Subject: CRL vs OCSP
Date: Mon, 18 May 1998 13:09:39 +0100
Sender: [email-masked]

There has been some discussion recently here in Sweden regarding CRLs vs
OCSP for checking possibly revoked certificates. 

I have the impression that OCSP is most suitable for mail clients, who want
to verify a certificate, and who can not subscribe to all CRLs in the world,
whereas CRLs are more suitable for on-line servers, for example for an
"Internet Bank" or "IKEA Online", who already have decided only to trust
certain CAs, and then subscribe to their CRLs.

Is there any common view within PKIX on this? Are CRLs dead or not?

Hans Nilsson
AU-System Network
Stockholm SWEDEN

Date: Fri, 15 May 1998 14:57:54 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

If we are "voting"  Denis and Steve sound like they are on the right track, my vote is "yes"

>>> Denis Pinkas <[email-masked]> 05/15/98 04:51PM >>>
Steve,

Thank you for holding the position. :-)

I would like just to bring you my support and say that I endorse 
your arguments. Extracting some of your sentences, I fully support:

" I cannot endorse mandating DN use of issuers"

" The PKIX Part 1 spec was explicit about NOT requiring use of 
  issuer or subject DNs. I'd like to maintain that feature".

" .. for over a year, (..) DNs were optional for issuers and subjects,
     IF AltNames were used."

" I vote for i!"

Denis

> John,
> 
> >Nobody's suggesting that users should make up DNs.  The suggestion is that
> >they (or rather the CA they register with) should follow an IETF standards
> >track RFC (RFC 2247) that defines a simple syntactic mapping from DNS name
> >"a.b.c.d" to DN "/DC=d/DC=c/DC=b/DC=a" (or "DC=a,DC=b,DC=c,DC=d" to use the
> >LDAP printable syntax).  RFC 2247 defines the two name forms as equivalent
> >- different ways of representing the same underlying abstract name, just as
> >the two strings "a.b.c.d" and "A.B.C.D" are merely different ways or
> >representing the same underlying DNS name.
> 
> Fair enough, the mapping is simple. It's also redundant and inefficient
> relative to the AltName representation.  Maybe what we really need here is
> an articulation of a consistent set of reasons that motivate use of the
> DNS-as-DN representation.  I'm sure you have good motivations, but they are
> not being stated in a consolidated fashion.  Merely because we can
> represent these IDs that way does not mean that we should, and it certainly
> does not suggest that we ought to discriminate by requiring such
> representation in certs to the exlcusion of the AltName forms.
> 
> Steve

-- 
      Denis Pinkas     Bull S.A.          mailto:[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, 15 May 1998 15:02:18 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

> From: Stephen Kent <[email-masked]>
> 
> If you don't agree on the difference between object classes defined by
> X.500 in the context of their definition of DNs, and the ITEF generating a
> standard that also defines how to represent DNS names in DNs, I don't we
> can have a useful conversation in this regard.

Steve,

I believe that this thread began with a request that the PKIX Part 1
make an explicit statement regarding the use of RFC 2247 names.  Following
the request comes a debate; following the debate will come a decision.

If a consensus-based positive decision is made, I would hope that an
IETF PKIX standards-track document specifying how to represent DNS
names in a DN would hold approximately equal weight, at least within
the Internet community, as X.500 object classes.

Regards,
Dave Kemp

Date: Fri, 15 May 1998 14:01:38 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

>>>>> "John" == John Wray <[email-masked]> writes:

 John> It seems that some important formatting info got stripped off
 John> my previous message, namely the numbering of the various cases
 John> of altname inclusion.  Hopefully it was obvious, but here's how
 John> the list should have looked:

 John> 1 Require the presence of a DN in every certificate to be used
 John> for chain processing, but allow altName fields to be present
 John> for other (non-chaining) purposes (e.g. additional
 John> identification information, directory or other certificate
 John> location hints, etc).

 John> 2 Allow a single name, expressed as either a DN or an altName,
 John> in each certificate, and use it for chaining.

 John> 3 Allow either a DN or one or more altNames, but not both, in
 John> each certificate, and use them for chaining.

 John> 4 Allow any combination of DNs and altNames (although probably
 John> excluding the case of a null DN in combination with no
 John> altNames), and use them for chaining.

 John> Plus case 0: Require DNs and don't permit altNames for anything
 John> other than end-user subject names.

Nice summary.

My preference is 4.  

Reason: the only fundamental technical requirement I can see is that
you have to be able to construct and verify a cert chain.  A cert
chain is nothing more than a collection of certs Ci with issuer Ii and 
subject Si such that Ii == Si+1 (or Si-1 depending on which way you
want to read).  

I see nothing in this that requires S or I to be a DN.  Nor does it
require each cert to carry only one S and one I apiece.  To check a
cert that carries a number of issuer (alt)names, I need another cert
that contains at least one of those names among its subject names.

Did I miss anything here?

About the only drawback I can see in having this much flexibility is
that it requires set operations (intersect {Ii} with {Si+1} and look
for non-empty) rather than simple comparisons.  Doesn't sound like a
major hassle, but if that's considered too much trouble, the logical
conclusion is to adopt alternative 2 instead.

None of the above would block a particular CA from being more
restrictive in what certs they will issue, and such restrictions
wouldn't cause any trouble.

One reason (other than principle) why I want this flexibility is that
it simplifies life for certs managed within an organization.  It seems 
to me that a lot of discussion is driven by certs as cross-org tools
in electronic payment applications and stuff like that.  That's fine,
but there are also the sort of apps I mentioned earlier -- certs used
to authorize IPsec SAs, within a single organization.  By definition
that's an IP-oriented organization, for which DNS names and IP
addresses are obvious sorts of names to use.  Therefore I want to be
able to have them create and use certs in the form most natural to
them, which as far as I can tell are altnames.  Bottom line: altnames
should be allowed in chain construction, hence alternatives 0 and 1
are not sufficient.

	paul

Date: Fri, 15 May 1998 08:52:48 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Role names in certificates
Sender: [email-masked]

At 05:18 PM 5/15/98 -0700, Denis Pinkas wrote:
>I wonder why should we attach such an attribute in this way. I
>believe/believed that AC (Attribute Certificates) should be used for
>that. 

AC's could be used for this, but I think it would be good to have the
option for clients and servers that do not understand ACs to understand
semantics in these names.

>Normally in a subjectAltName we should only describe the syntax of the
>name, NOT the SEMANTIC of the name.

That's why this is a separate draft and not part of Part 1. Someone can
implement Part 1 and not the role draft still be able to handle all
addresses that come from an agent that is following the role draft. It is
an extension that does not affect the semantics of Part 1.

>"Role" has already some meaning for me (e.g. the case of the Sales
>Director of the Delta Company). For the cases you consider, if this
>document is going forward, I would rather prefer that we attempt to use
>a different naming to avoid the confusion. Any other proposal (different
>from simply "role") ?

I would want to see what other word you suggested before commenting on
this. I think "role" works just fine for what the draft is describing. The
programs that sign and/or encrypt are taking the role of "this group's
signer and/or encrypter". It is like a secretary or assistant function, and
those are roles in my mind. We should stay away from terms that have too
many meanings, like "agent".

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: Role names in certificates
Date: Fri, 15 May 1998 08:47:14 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Friday, May 15, 1998 5:18 PM
> To: Blake Ramsdell
> Cc: [email-masked]'
> Subject: Re: Role names in certificates
> 
> Normally in a subjectAltName we should only describe the syntax of the
> name, NOT the SEMANTIC of the name.

This is part of what's being explored.  As you point out, attribute
certificates may be The Right Way to express name semantics, so my
proposal to associate semantics with subjectAltName may be a Bad Idea.
That's part of what I'd like to figure out.  Do you have any suggestions
as to how you might represent the semantics that I have proposed using
an AC?  Is there a definitive source that says that altNames cannot
express semantics?  I'm not trying to be a wise guy -- I don't have a
good, definitive reference that shines the elusive light of X.509 truth
on the answer.  Well, there's Peter's guide, and PKIX Part 1...

In discussions on the S/MIME list, the consensus seemed to be that ACs
had a bit of work that needed to be done before they were ready for
prime time.  I am far from an expert on their popularity and use, so I'm
not prepared to argue for or against them.  I just generally have a bad
feeling about their use right now, that could very well be unfounded.

> In addition, I took a look at the document again and I realized that I
> was focussing on the word "role" too much.
> 
> "Role" has already some meaning for me (e.g. the case of the Sales
> Director of the Delta Company). For the cases you consider, if this
> document is going forward, I would rather prefer that we 
> attempt to use
> a different naming to avoid the confusion. Any other proposal 
> (different
> from simply "role") ?

I agree -- there has been some confusion regarding the "sales director"
role vs. the "domain signing authority" role.  Any suggestions welcome,
and I will certainly scratch my head some more.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Fri, 15 May 1998 17:18:19 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Blake Ramsdell <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Role names in certificates
Sender: [email-masked]

Blake,

I took me some time to replay to this message.  :-)

I wonder why should we attach such an attribute in this way. I
believe/believed that AC (Attribute Certificates) should be used for
that. 

Normally in a subjectAltName we should only describe the syntax of the
name, NOT the SEMANTIC of the name.

In addition, I took a look at the document again and I realized that I
was focussing on the word "role" too much.

"Role" has already some meaning for me (e.g. the case of the Sales
Director of the Delta Company). For the cases you consider, if this
document is going forward, I would rather prefer that we attempt to use
a different naming to avoid the confusion. Any other proposal (different
from simply "role") ?

Denis

> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Tuesday, May 05, 1998 2:50 PM
> > To: Blake Ramsdell
> > Cc: [email-masked]'
> > Subject: Re: Role names in certificates
> >
> >
> > > I have written a draft that I have submitted as an
> > individual (not under
> > > IETF-PKIX).  It describes a concept of using "role" names in
> > > certificates for several purposes that are not covered with
> > conventional
> > > PKIX certificates.
> >
> > I am not sure that this thread is relevant to the PKIX WG. It might be
> > more relevant to the S/MIME WG.
> 
> It may end up this way -- the original intent was to profile roles for
> other name types besides rfc822Name (specifically, dNSName).  If we end
> up just doing rfc822Name, it might end up in S/MIME, but roles in
> rfc822Name may be applicable to other profiles that use email addresses
> for end-entities.  We'll see how it hammers out, and where we end up.
> 
> > A requirement would be the need to sign a message as the
> > Sales Director
> > of the Delta Company, who may happen to be John Walker. However John
> > Walker may not have a private key of its own.
> 
> I think that this may be another use of role that has different
> semantics -- in my case the role was "This certificate belongs to an
> entity that is signing messages on behalf of individuals at this
> organization", vs. your valid example of "This certificate belongs to
> the Sales Director of the Delta Company".  This may be an additional
> role that we can consider.
> 
> > For the other following cases related to encryption, I wonder
> > why a role
> > is needed.
> 
> They may not be.  In the event that the sending agent is an MTA and it
> wants to encrypt messages to another particular MTA, I didn't know if a
> special semantic should be communicated so that there was no confusion
> during configuration that the certificate was suitable for MTA-to-MTA
> encryption.  It may not be.
> 
> The plaintext recovery role seems useful so that the sending agent can
> provide user feedback to the effect of "You are encrypting for a
> certificate that is being used for message recovery.  Is that cool?"
> 
> > 1) a signature server (from a company) is able to sign documents on
> > behalf of an employee with its own key and indicate the appropriate
> role
> > used by the employee. The employee may authenticate to that signature
> > server by whatever means. In that case the signer is the company which
> > indicates the role of the employee.
> 
> I think that the server vouching for the role of the employee is a
> separate problem.  The first point that I was hoping to get to was an
> automated agent signing all messages leaving the organization, and then
> associating semantics with that.
> 
> As a separate problem, the company gateway placing a signature on the
> message based on his assessment that this individual is indeed the
> "CFO", "CEO", or whatever, may be interesting.
> 
> > 2) a temporary certificate issued by a server of a company includes a
> > role and a temporary public key. The employee is given back the
> > temporary private key so that it can sign documens directly using that
> > private key.
> 
> In the particular usage that I have in mind (signing at the MTA), this
> would be self-defeating -- you still have to distribute keys, educate
> users, and enforce policy at the individual level.
> 
> Thanks for the comments...
> 
> Blake

-- 
      Denis Pinkas     Bull S.A.          mailto:[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, 15 May 1998 10:24:37 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[email-masked]>
Reply-To: Anne Anderson - Sun Microsystems <[email-masked]>
Subject: Re: Alternate name semantics and usage
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

>>Maybe what we really need here is an articulation of a
>>consistent set of reasons that motivate use of the
>>DNS-as-DN representation.

IF
   PKIX continues to allow blank "subject" and "issuer"
   where "subjectAltName" and "issuerAltName" are
   present
AND IF
   PKIX continues to allow certificate chaining
   through "issuerAltName" and "subjectAltName"
THEN
   There is probably no need for RFC2247 format
   DNs in "subject" and "issuer", except that it
   may be a useful "common syntax" for verifiers
   that do not understand an alternate name syntax.
END

IF
   PKIX changes PKIX 1 to require "subject" and "issuer"
AND IF
   All certificate chaining is done through "subject"
   and "issuer"
THEN
   PKIX 1 must explicitly support RFC2247 as a "common
   syntax" for conversion of names from namespaces other
   than X.500, such as DNS names.
END

Anne Anderson                 Email: [email-masked]
Sun Microsystems Laboratories   Tel: (978) 442-0928
2 Elizabeth Drive, UCHL03-205   Fax: (978) 250-5067
Chelmsford, MA 01824 USA

From: [email-masked]
To: [email-masked]
Date: Fri, 15 May 1998 10:18:07 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

It seems that some important formatting info got stripped off my previous
message, namely the numbering of the various cases of altname inclusion.
Hopefully it was obvious, but here's how the list should have looked:

1  Require the presence of a DN in every certificate to be used for chain
   processing, but allow altName fields to be present for other
   (non-chaining) purposes (e.g. additional identification information,
   directory or other certificate location hints, etc).

2  Allow a single name, expressed as either a DN or an altName, in each
   certificate, and use it for chaining.

3  Allow either a DN or one or more altNames, but not both, in each
   certificate, and use them for chaining.

4  Allow any combination of DNs and altNames (although probably excluding
   the case of a null DN in combination with no altNames), and use them for
   chaining.

Plus case 0: Require DNs and don't permit altNames for anything other than
end-user subject names.

John

From: [email-masked]
To: Stephen Kent <[email-masked]>
cc: [email-masked]
Date: Fri, 15 May 1998 09:55:45 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>>Nobody's suggesting that users should make up DNs.  The suggestion is
that
>>they (or rather the CA they register with) should follow an IETF
standards
>>track RFC (RFC 2247) that defines a simple syntactic mapping from DNS
name
>>"a.b.c.d" to DN "/DC=d/DC=c/DC=b/DC=a" (or "DC=a,DC=b,DC=c,DC=d" to use
the
>>LDAP printable syntax).  RFC 2247 defines the two name forms as
equivalent
>>- different ways of representing the same underlying abstract name, just
as
>>the two strings "a.b.c.d" and "A.B.C.D" are merely different ways or
>>representing the same underlying DNS name.
>
>Fair enough, the mapping is simple. It's also redundant and inefficient
>relative to the AltName representation.  Maybe what we really need here is
>an articulation of a consistent set of reasons that motivate use of the
>DNS-as-DN representation.  I'm sure you have good motivations, but they
are
>not being stated in a consolidated fashion.  Merely because we can
>represent these IDs that way does not mean that we should, and it
certainly
>does not suggest that we ought to discriminate by requiring such
>representation in certs to the exlcusion of the AltName forms.

RFC 2247 names aren't something I'm particularly tied to.  I'm simply
arguing that dismissing them out of hand as a hack, or as inferior in some
way to other DNs is just wrong, and shouldn't be used to bolster an
argument that DNs are inadequate.

Names in certificates are used in PKIX for two main purposes:

   To name end entities
   To link certificates together in a trust-chain

They are also used to locate certificates, but I'm not going to address
that here.

Usage 1 is accompanied by a fairly fuzzy set of requirements, in that
end-entities will probably want some say in how they name themselves, and
what identifying information they consider to be their name, or want to
accompany their name.

Usage 2 is critical to the interoperation of PKIX-compliant systems.  Given
two certificates A and B, a PKIX system has to be able to determine whether
A can be used to verify B, which among other things, requires it to
determine:

   Does subject(A) match issuer(B)?
   Do the name-constraints in effect for issuer(A) allow it to certify
   subject(A)
   Do the name-constraints in effect for issuer(A), augmented by those
   applied by certificate A, allow issuer(B) to certify subject(B)

Algorithms for answering these three questions are well-specified for the
case when A contains only DNs, and no altName fields, and where B contains
only a DN for its issuerName.  No ambiguity is introduced into chain
processing by allowing end-entity certs to use altNames in any form they
desire.

If we want to add altName fields (other than for subject(B)), there are
several degrees to which we can do this:

   Require the presence of a DN in every certificate to be used for chain
   processing, but allow altName fields to be present for other
   (non-chaining) purposes (e.g. additional identification information,
   directory or other certificate location hints, etc).
   Allow a single name, expressed as either a DN or an altName, in each
   certificate, and use it for chaining.
   Allow either a DN or one or more altNames, but not both, in each
   certificate, and use them for chaining.
   Allow any combination of DNs and altNames (although probably excluding
   the case of a null DN in combination with no altNames), and use them for
   chaining.

I'll refer to to the situation where altNames may appear only in the
subjectAltName field of end-entity certs as case 0.  I believe PKIX-1 is
currently adequate for this case only.

Algorithms for case (1) are straightforward (they're the same a case 0, and
PKIX-1 can be read to cover this case when the altName critical flag isn't
set, although I feel this is a misuse of the critical flag).

We might be able to reach agreement on algorithms to answer the three
questions above for case (2), for some subset of the defined altName types;
we don't have that agreement today (or at least, if we do, it's not written
down in PKIX-1, or in any of the proposed additions to PKIX-1 that I've
seen floated on the list).  In particular, what happens when trust chains
cross between namespaces?  What does a "*" match in a Name Constraint for a
dNSName (can it include periods, or can it only match characters within a
domain component)?  rfc822 name constraints are documented as applying both
to names represented as rfc822Name altNames, and to names represented using
PKCS#9 e-mail attributes as a DN - a natural extension of this would be to
apply dNSName constraints to RFC 2247 names, and to apply DN name
constraints that affect the /DC=* subtree to dNSName altNames, although
that's not stated.

Given the degree of disagreement on what a CA's signature means wrt
multiple altNames, and whether each individual name is an alternative, or
whether the entity is named by the the entire set, I don't believe we can
reach rapid closure on cases 3 or 4.

So we need to decide a strategy for PKIX-1: either live with DNs alone or
choose case 1, fix the ambiguities for case 2 above and only support that
case, or try to address the problems in cases 3 and 4.  I don't believe we
will get a quick resolution on cases 3 and 4.  As we need to get the PKIX
specs (PKIX-1 in particular) out ASAP, I am strongly in favor of postponing
cases 3 and 4 for a future revision of the document, and picking either DNs
alone (case 0) or case 1 or 2.

If we start off with DNs alone, that can be generalised to either case 1 or
case 2.  On the face of it, cases 1 and 2 would appear to be mutually
incompatible, so picking either would restrict our future opportunities at
generalisation.  We could try to support a combination of 1 and 2 (i.e. if
a certificate has a DN, then that is used for chaining and the cert can
have multiple altNames which are ignored, but if there's no DN, then the
cert must have a single altName which is used for chaining), but that's an
incredible kludge, and has all sorts of problems generalizing in the
future.  We could also attempt to use the critical flag to indicate whether
an altName contains a "distinguished" altName, or simply additional
identifying information, but that's misusing the definition of the critical
flag, by requiring implementations that understand the extension to apply
different semantics depending on the state of the flag.  Its interesting
that this is what the current draft of PKIX-1 apparently indicates
(although it doesn't restrict certs to using a single altName in the case
where there's no DN, nor does it restrict the use of the critical flag in
the case where there is a DN).

So, do we need to support altNames anywhere other than as subjects of
end-entity certificates?  If so, then we need to pick between cases 1 and
2, and there are strong voices arguing for each viewpoint.  Unless we can
resolve these differences quickly, we should go with the position given at
the IETF, which was that PKIX certs shall use DNs in all cases other than
in the subject field of end-entity certs (and in addition we'd need to
restrict certs from providing critical altNames along with those DNs),
which implies that chain processing is performed using DNs exclusively.

The whole discussion over RFC 2247 names was to emphasize that a
requirement to issue certificates to CAs named with DNS names isn't a
requirement to use the altName fields.

John

Date: Fri, 15 May 1998 15:51:23 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Stephen Kent <[email-masked]>
CC: [email-masked], Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Steve,

Thank you for holding the position. :-)

I would like just to bring you my support and say that I endorse 
your arguments. Extracting some of your sentences, I fully support:

" I cannot endorse mandating DN use of issuers"

" The PKIX Part 1 spec was explicit about NOT requiring use of 
  issuer or subject DNs. I'd like to maintain that feature".

" .. for over a year, (..) DNs were optional for issuers and subjects,
     IF AltNames were used."

" I vote for i!"

Denis

> John,
> 
> >Nobody's suggesting that users should make up DNs.  The suggestion is that
> >they (or rather the CA they register with) should follow an IETF standards
> >track RFC (RFC 2247) that defines a simple syntactic mapping from DNS name
> >"a.b.c.d" to DN "/DC=d/DC=c/DC=b/DC=a" (or "DC=a,DC=b,DC=c,DC=d" to use the
> >LDAP printable syntax).  RFC 2247 defines the two name forms as equivalent
> >- different ways of representing the same underlying abstract name, just as
> >the two strings "a.b.c.d" and "A.B.C.D" are merely different ways or
> >representing the same underlying DNS name.
> 
> Fair enough, the mapping is simple. It's also redundant and inefficient
> relative to the AltName representation.  Maybe what we really need here is
> an articulation of a consistent set of reasons that motivate use of the
> DNS-as-DN representation.  I'm sure you have good motivations, but they are
> not being stated in a consolidated fashion.  Merely because we can
> represent these IDs that way does not mean that we should, and it certainly
> does not suggest that we ought to discriminate by requiring such
> representation in certs to the exlcusion of the AltName forms.
> 
> Steve

-- 
      Denis Pinkas     Bull S.A.          mailto:[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

From: Sharon Boeyen <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: RE: Alternate name semantics and usage
Date: Fri, 15 May 1998 09:20:25 -0400
Sender: [email-masked]

Wow, this list has sure been busy!! Too many issues to comment on all of
them, but:

Earlier someone said they've never seen a certificate with rfc822 address in
subject alt name extension. When appropriate, we do put these in subject alt
name, but we also include a DN in the certificate. 

I don't like the idea of dumping everything into the DN, the subject alt
name field was designed for this purpose specifically and dumping
application specific names into a DN defeats the purpose of them. Despite
the bad rap DNs seem to be getting in this thread, they are actually being
used quite successfully in many places and with many different styles. 

The IETF PKIX WG should NOT try to mandate any particular naming structure
for DNs, that is up to entities being named and flexibility is needed in
order to meet the business needs of various organizations. For example, some
CAs issue certificates which contain DNs that are ONLY meaningful within
their own particular business environment. These DNs are perfectly valid and
can be resolved in the traditional way by directory systems, but to a
certificate using system which is not part of their particular business
application, these names would be totally useless and the certificates are
virtually anonymous. Business requirements will and should dictate the form
and content of DNs, not the PKIX WG.

On the issue of DNS /DN mapping, I don't consider the RFC that maps DNS
names into DNs the same as the discussion of throwing alt names into DNs
though. In the former case, a clear mapping of element by element into RDN
by RDN is provided. The DN structure is maintained and name resolution can
proceed. Matching rules are defined for the attributes just as for the X.500
ones. I think this is a perfectly valid model and some organizations may
choose to use this while others may choose the more "DN traditional"
approach and still others will use the anonymous style. As long as the
structure is the same and knowledge references maintained, this would be
seamless from a directory processing standpoint and from a certificate
processing standpoint.  In the X.500 group, we did define a set of generally
useful attributes but these were never intended to be the only ones and the
same applies to the naming and DIT structure parts of X.500. However, for
environments where you want to have directory interoperability it is
necessary that the attributes used for naming be supported and understood by
the systems processing them, so it is recommended to use well known
attributes only for naming. I do think it is especially problematic, from a
directory standpoint, to include application-specific naming information
(e.g. rfc822 addresses) in DNs. This results in unnecessary bounds on the
DIT structure an organization can set up and becomes very complicated when
more than one application is involved.

As for use of alt names in path validation, my personal preference would be
to keep things simple and rely on DNs. If that isn't possible, then we need
to be cautious about ensuring that we have properly dealt with all the
issues such as: paths which have certificates with different name forms;
priority of name form where the extension contains more than one; problems
where the certificate processing system supports one of the multiple name
forms present in the certificate, but it isn't the one of interest for the
particular validation activity;  how to specify which value is important to
path validation etc. If more specification is needed here, I'd like to see
it coordinated with the X.509 group and ensure that the PKIX work and base
509 continue to be aligned. In X.509, our current work items do allow for
enhancements in the extensions area if required.  

Sharon

Date: Thu, 14 May 1998 19:31:48 -0400
To: [email-masked], Stephen Kent <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

John,

>Nobody's suggesting that users should make up DNs.  The suggestion is that
>they (or rather the CA they register with) should follow an IETF standards
>track RFC (RFC 2247) that defines a simple syntactic mapping from DNS name
>"a.b.c.d" to DN "/DC=d/DC=c/DC=b/DC=a" (or "DC=a,DC=b,DC=c,DC=d" to use the
>LDAP printable syntax).  RFC 2247 defines the two name forms as equivalent
>- different ways of representing the same underlying abstract name, just as
>the two strings "a.b.c.d" and "A.B.C.D" are merely different ways or
>representing the same underlying DNS name.

Fair enough, the mapping is simple. It's also redundant and inefficient
relative to the AltName representation.  Maybe what we really need here is
an articulation of a consistent set of reasons that motivate use of the
DNS-as-DN representation.  I'm sure you have good motivations, but they are
not being stated in a consolidated fashion.  Merely because we can
represent these IDs that way does not mean that we should, and it certainly
does not suggest that we ought to discriminate by requiring such
representation in certs to the exlcusion of the AltName forms.

Steve

Date: Thu, 14 May 1998 19:06:44 -0400
To: Bob Jueneman <[email-masked]>, [email-masked], [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

Bob,

>John, I really don't care much, but I personally believe that the
>RFC 2247 style mapping is egregious -- more unwieldy than the
>X.400 naming. IETF "standard" or not, it's ugly, and dumb, IMHO.
>
>What is wrong with simply defining a DNS attribute that can contain the
>entire DNS name string, regardless of how many components it
>may contain?

I assume that the desire for use of the 2247-style naming is to enable use
of existing X.500 facilities to structure the name space and distribute it
in a fashion parallel to the DNS.  If one puts the whole name in as a
single attribute then one looses the tree structuring that is essential to
distributing the database (if one makes use of the existing X.500
facilities)

>Of course a decent GUI could easily transform the LDAP
>printable syntax into back into a reasonable presentation format,
>e.g., a.b.c.d. That's why I'm not particularly concerned.

Yes, for user presentation one can do that, but that doesn't take advantage
of the backend database structure mechanisms.

>The only reason why I can think that you would want to break up
>a DNS name into it's constituent parts would be to try to apply name
>subordination techniques to it.  But name subordination is another
>hold-over from the PEM days, whose utility has yet to be proven.

The NameConstraints extension is designed to allow a CA to impose name
subordination to make cross-certification safe.  It is an improvement over
the PEM model because it is selectively applicable.  However, contrary to
your assertion, most folks I know appreciate the need for this sort of
constraint whenever two organizations cross-certify.  Perhaps the basis for
disagreement is that your model for CA operations focuses on public CAs,
who can certify anything for a fee, whereas mine focuses on organizations
acting as CAs when they actually are authoritative for the name spaces
being certified.  This latter model parallels most existing infrastructures
for issuance of credentials  of various forms.  The former model seems
designed to generate revenue for third parties who, by the way, mostly
disclaim liability for their certification activities :-).

>Given the lack of any obvious mapping of DNS names to an
>organization's legal name, together with the problem that complex
>organizations (like holding companies) are made up of independent
>subsidiary corporations that have no obvious name relationship
>(like EDS to GM), I believe that name subordination is nearly useless,
>both for "traditional" DNs and for DNS names as well. And completely
>useless for most e-mail names, given the tendency of people to acquire
>their e-mail addresses from an ISP that has no correspondence with their
>organization at all.

It is much easier to argue that DNs are "nearly useless" for common
Internet applications, since there is no authority for their assignment.
We already have a handful of federal court cases dealing with resolution of
DNS name "ownership" when dispuites have arisen. DNs, today, don't get you
anywhere on the Internet, don't  really identify web servers, and don't
reliably identify users for e-mail.  DNS names, RFC 822 names, and IP
addresses do fulfill these critical requiremenmts and we know how to
administer the spaces, so let's make use of them.  You sound like you still
believe in the one, universal ID and certificate that will authenticate a
user to everyone.  That's not reality.  Reality is that we all have many
forms of ID, issued by a wide range of organizations, for use in different
roles.  There is no reason we cannot translate these ID forms into
certificates.  I have no objection to using arbitrary DNs to identify folks
in closed PKIs, e.g., as client certificate subject names.  But these don't
have to be stored in a directory, nor do they pretend to represent an
identity in any butna purely local, arbitrary sense.

Steve

Date: Thu, 14 May 1998 16:54:02 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

>>>>>> "Bob" =3D=3D Bob Jueneman <[email-masked]> writes:
>
> Bob> I agree with your scenario, and with Steve's formulation of IP
> Bob> addresses (if static), DNS names, or RFC822 names as the useful
> Bob> cert IDs.
>
> Bob> What I still cannot fathom is why he insists that those name
> Bob> forms, although perfectly valid altnames, are somehow verbotten
> Bob> for use as a legitimate RDN or DN.
>
>There's an interesting puzzle here.
>
>If IP addresses, DNS names, etc., are perfectly legitimate RDNs or
>DNs, it sounds like there is no need to have the concept of an
>AltName.   But AltName does exist; presumably it's there for a reason?
>
>Also, if RDNs let you encode the same sort of things (like DNS names)
>that you can put in AltNames, except that the syntax used is rather
>bizarre, this suggests that there is no reason for the two to have
>different semantics.  Yet people are saying that it somehow doesn't
>make sense to chain up certs via AltNames.  (Why not?  If I have an
>altname issuer in one cert, can't I have another cert that certifies
>the binding of that altname to a key?)
>
>	paul

paul,

Steve (and perhaps others) might well disagree, but I believe that=20
there are two fundamental reasons.

The first is both historic and emotional, and reflects an enormous =
cultural
gap between the highly institutionalized ISO/ITU processes and the=20
free-wheeling, lets get it done and see if it works philosophy of the =
IETF.
(Note however, that the IETF is increasingly becoming involved in=20
design-by-committee, and is becoming indistinguishable, in effect, from
the "official" standards organizations they/we often protest against.)

DNs have a lot of baggage, primarily because of the X.400 association
and a rather cumbersome printed name form (business-card representaiton)
that lots of people objected to. And unfortunately, by steadfastly =
refusing to
address the interoperability issues caused by not standardizing the schema
for DNs within a certificate, the old baggage is left undisturbed, and =
hence=20
is still disliked.  But the problem is not with the DNs, but the lack of =
an
acceptable schema. No one likes X.520/X.521, but no one since the NADF
has tried to fix the problem.

The other issue, which also arose back in the PEM days, is the=20
distinction between what might be reasonably considered=20
necessary, and/or "official" (two different concepts to be sure), vs.=20
what might be merely useful or convenient.

One point of view, which Steve apparently reflects, is that a CA should =
be=20
absolutely responsible/liable for every single element contained in the
certificate. In that case, of course, a CA would be compelled to do its=20
due diligence to verify the contents, and would strongly resist =
including=20
anything it couldn't reasonably verify, for fear of unwanted and=20
unwarranted liability.

Another point of view, which I know that VeriSign supports, and=20
in particular Michael Baum, their VP for Practices and also the=20
chairman of the ABA group that wrote the Digital Signature Guidelines,
is that the definition of what is verified and what is not verified in a =
certificate
can and should be defined in the CA's Certification Practice Statement.
And certainly VeriSign's current practices allow the user to add informatio=
n=20
(such as SSN, DOB, etc.) that may be of questionable utility, but =
cannot=20
reasonably be verified by the CA.

My own point of view is in the middle.  If I feel the need to include my =
height,=20
weight, hair color, skin color, JPEG photo, fingerprint classification, =
etc., because=20
I believe that will be beneficial to me in my own use of my certificate, =
that=20
should be my business, at least within reason.

>From a legal standpoint, I am making a representation to the CA, and hence =
to
relying parties, in the expectation that someone may rely on the informatio=
n. And
therefore, if I misrepresent that information I might be liable for any =
damages
encurred by someone who relied on it. So I, the subscriber/subject of =
the=20
certificate, am on the hook.

On the other hand, the CA shouldn't have to choose between honoring their
customer's wishes (generally a poor business practice!) and becoming=20
unnecessarily liable in their own right for apparently endorsing some=20
"fact" which the subscriber represented to them if it turns out not to be =
true.

At least part of the motivation for alternate subject names, therefore, =
was the=20
recognition of the utility of "informational" names and/or other attributes=
, which
the CA might or might not choose to independently validate.

In retrospect, the semantics of these name forms was not thought through =
carefully
enough, and now we have this argument.

My preference would be to clearly indicate what attributes were validated =
by the CA
and which were not, though the use of a Nonverified Subscriber Information =
flag,
and as a vendor of a CA toolkit which can both create certificates itself =
and pass them=20
on to external CAs to be signed, that is exactly what we are going to =
provide for
certain attributes.  The major (and minor) CAs can then decide whether or =
not to=20
accept and sign such attributes, and we will let the market decide what =
people want.

The only other distinction that I see between a DN and an alt name is the =
greatly=20
increased complexity that ensues if it is allowable to retrieve and chain =
certificates=20
based on either or both name forms. =20

Steve works for a company that is a CA, but doesn't provide a directory =
(to my=20
knowledge). Novell, on the other hand, has on the order of 80 million =
customer=20
nodes (users), a vast percentage of whom make daily use of NDS, our =
X.500-like
directory.  Granted that the top-down, monoply carrier imposed, everyone-is=
-=20
connected-to-the-great-X.500-directory-in-the-sky model has never =
materialized and=20
probably never will, it is still quite incorrect to assume that no one is =
using certificates=20
in combination with directories, as he seems to imply.

Hope this helps.

Bob

Date: Thu, 14 May 1998 18:09:44 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

>>>>> "Bob" == Bob Jueneman <[email-masked]> writes:

 Bob> I agree with your scenario, and with Steve's formulation of IP
 Bob> addresses (if static), DNS names, or RFC822 names as the useful
 Bob> cert IDs.

 Bob> What I still cannot fathom is why he insists that those name
 Bob> forms, although perfectly valid altnames, are somehow verbotten
 Bob> for use as a legitimate RDN or DN.

There's an interesting puzzle here.

If IP addresses, DNS names, etc., are perfectly legitimate RDNs or
DNs, it sounds like there is no need to have the concept of an
AltName.   But AltName does exist; presumably it's there for a reason?

Also, if RDNs let you encode the same sort of things (like DNS names)
that you can put in AltNames, except that the syntax used is rather
bizarre, this suggests that there is no reason for the two to have
different semantics.  Yet people are saying that it somehow doesn't
make sense to chain up certs via AltNames.  (Why not?  If I have an
altname issuer in one cert, can't I have another cert that certifies
the binding of that altname to a key?)

	paul

Date: Thu, 14 May 1998 16:02:37 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

I agree with your scenario, and with Steve's formulation of=20
IP addresses (if static), DNS names, or RFC822 names as
the useful cert IDs.

What I still cannot fathom is why he insists that those name
forms, although perfectly valid altnames, are somehow verbotten
for use as a legitimate RDN or DN.

Bob

>>> Paul Koning <[email-masked]> 05/14 1:02 PM >>>
Thanks!

>>>>> "Stephen" =3D=3D Stephen Kent <[email-masked]> writes:

 Stephen> Paul,
 >> Scenario: I build a box that implements IPsec, with IKE, with
 >> certificate based authentication.  Let's assume these are PKIX
 >> certificates as opposed to some other kind.
 >>=20
 >> The box is an IP box, so the customer (i.e., the network support
 >> personnel there) understand very well how DNS names, IP addresses,
 >> and such things are administered.
 >> ...
 >> Now here's the issue: the customer has to set up access
 >> authorization to this box (i.e., the right to establish IPsec
 >> SAs).  This means creating certs for each of the end users that
 >> will be speaking IPsec to this box.  What do we tell them?  What
 >> sort of names should be used?  Who administers them?  What tools
 >> are used to do so?  What are the directories that are used (not
 >> just conceptually -- what products)?

 Stephen> The most likely choices for user certs IDs are IP addresses
 Stephen> (if they are statically assigned), DNS names (if there is a
 Stephen> one-to-one user-to-host mapping and it's static), or rfc822
 Stephen> names (for pure user identification).  All of these are ID
 Stephen> forms you administrators are familiar with, as you specified
 Stephen> the scenario, so issuance of certs based on any of these
 Stephen> name forms should be "natural."  Each of these name forms
 Stephen> can be represented in certs as AltNames, or using standard
 Stephen> or ad hoc DN-embedding conventions.  For IPsec, we are
 Stephen> defining the preferred represnetations for these Internet
 Stephen> name forms, and the current draft on this topic calls for
 Stephen> use of the AltName formats, not DNs.

I thought that AltNames made sense here, which is why I'm
puzzled/disturbed at apparent efforts to restrict the use of
AltNames.  If they are inappropriate for certain uses (which may be
the case, though that isn't yet clear to me) then the obvious answer
is to document those cases and recommend in the spec (or, maybe,
require) to avoid AltNames for those specific situations.

 Stephen> Also, for IPsec, t is not clear that one needs to go to a
 Stephen> directory to fetch certs for users or firewalls.  One can
 Stephen> exchange the certs as part of the IKE negotiation, in real
 Stephen> time.  Since you note that the users have to be autorized
 Stephen> for access, not just random public users, then the
 Stephen> distribution of certs (including CA certs) can be managed as
 Stephen> part of the enrollment process, which would also involve
 Stephen> creating ACL entries (SPD entries, to use IPsec
 Stephen> terminology).

Yes, IKE has that mechanism, but by analogy with things like RADIUS it=20
may also be attractive to put the applicable certs in a central place
where the IPsec box can find them.

	paul

Date: Thu, 14 May 1998 15:55:49 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Despite my comments on RFC 2247 in particular, I do agree with you
on this issue.

bob

>>> <[email-masked]> 05/14 11:00 AM >>>
>>I agree, and in particular it's wrong to claim that an RFC 2247 name is
>>somehow less "real" or more of a hack than an X.521 OrganizationalPerson
>>name.
>
>Well, OrganizationalPerson is defined as a class in X.500, and DNs are
>defined in X.500, but RFC 2247 is not X.500 and so I do think it has a
>lesser standing, if only on that basis.

OrganizationalPerson is defined within the X.500 series in a document
titled "Selected Object Classes", not "The Most Important Object Classes",
or "The Only Object Classes That May be Used".  The introduction to this
document say that it contains definitions that may be useful across a =
range
of applications of the directory.  The sorts of applications the writers =
of
the document had in mind related to retrieving information (such a
telephone numbers) primarily about people, not to retrieving X.509
certificates for Internet hosts.  It shouldn't be any suprise that things
deemed to be "useful" in the first context aren't particularly helpful in
the second, nor should it be any suprise that names that do turn out to be
useful in the second context weren't specified in a document addressed to
the first.  That X.521 didn't define an object class for "InternetDNSname"
doesn't give RFC 2247 names any lesser standing than the name forms that
_are_ defined there.

John

Date: Thu, 14 May 1998 15:54:29 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

John, I really don't care much, but I personally believe that the
RFC 2247 style mapping is egregious -- more unwieldy than the=20
X.400 naming. IETF "standard" or not, it's ugly, and dumb, IMHO.

What is wrong with simply defining a DNS attribute that can contain the
entire DNS name string, regardless of how many components it=20
may contain?

Of course a decent GUI could easily transform the LDAP=20
printable syntax into back into a reasonable presentation format,
e.g., a.b.c.d. That's why I'm not particularly concerned.

The only reason why I can think that you would want to break up
a DNS name into it's constituent parts would be to try to apply name
subordination techniques to it.  But name subordination is another=20
hold-over from the PEM days, whose utility has yet to be proven.

Given the lack of any obvious mapping of DNS names to an=20
organization's legal name, together with the problem that complex
organizations (like holding companies) are made up of independent=20
subsidiary corporations that have no obvious name relationship=20
(like EDS to GM), I believe that name subordination is nearly useless,
both for "traditional" DNs and for DNS names as well. And completely
useless for most e-mail names, given the tendency of people to acquire
their e-mail addresses from an ISP that has no correspondence with their
organization at all.

bob

>>> <[email-masked]> 05/14 10:40 AM >>>
Stephen Kent <[email-masked]>, in reply to Bob Jueneman writes:

>>In answer to John's last point, I agree that it would be possible
>>and under some circumstances desirable, to provide those alternative,
>>not rigidly bound names or other attributes by means of a directory.
>>But although I very much WANT to be able to look up certificates, CRLs,
>>etc. in a directory, I don't think that users should be COMPELLED
>>to.
>
>And I believe that users ought not be compelled to "make up" DNs when =
they
>have perfectly good DNS names!

Nobody's suggesting that users should make up DNs.  The suggestion is that
they (or rather the CA they register with) should follow an IETF standards
track RFC (RFC 2247) that defines a simple syntactic mapping from DNS name
"a.b.c.d" to DN "/DC=3Dd/DC=3Dc/DC=3Db/DC=3Da" (or "DC=3Da,DC=3Db,DC=3Dc,DC=
=3Dd" to use the
LDAP printable syntax).  RFC 2247 defines the two name forms as equivalent
- different ways of representing the same underlying abstract name, just =
as
the two strings "a.b.c.d" and "A.B.C.D" are merely different ways or
representing the same underlying DNS name.

John

Date: Thu, 14 May 1998 15:42:27 -0400
To: Paul Koning <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

Paul,

> Stephen> The most likely choices for user certs IDs are IP addresses
> Stephen> (if they are statically assigned), DNS names (if there is a
> Stephen> one-to-one user-to-host mapping and it's static), or rfc822
> Stephen> names (for pure user identification).  All of these are ID
> Stephen> forms you administrators are familiar with, as you specified
> Stephen> the scenario, so issuance of certs based on any of these
> Stephen> name forms should be "natural."  Each of these name forms
> Stephen> can be represented in certs as AltNames, or using standard
> Stephen> or ad hoc DN-embedding conventions.  For IPsec, we are
> Stephen> defining the preferred represnetations for these Internet
> Stephen> name forms, and the current draft on this topic calls for
> Stephen> use of the AltName formats, not DNs.
>
>I thought that AltNames made sense here, which is why I'm
>puzzled/disturbed at apparent efforts to restrict the use of
>AltNames.  If they are inappropriate for certain uses (which may be
>the case, though that isn't yet clear to me) then the obvious answer
>is to document those cases and recommend in the spec (or, maybe,
>require) to avoid AltNames for those specific situations.

We agree, but others on this list insist on the primacy of DNs in all
instances.

> Stephen> Also, for IPsec, t is not clear that one needs to go to a
> Stephen> directory to fetch certs for users or firewalls.  One can
> Stephen> exchange the certs as part of the IKE negotiation, in real
> Stephen> time.  Since you note that the users have to be autorized
> Stephen> for access, not just random public users, then the
> Stephen> distribution of certs (including CA certs) can be managed as
> Stephen> part of the enrollment process, which would also involve
> Stephen> creating ACL entries (SPD entries, to use IPsec
> Stephen> terminology).
>
>Yes, IKE has that mechanism, but by analogy with things like RADIUS it
>may also be attractive to put the applicable certs in a central place
>where the IPsec box can find them.

Yes, but be aware that such retrieval (absent caching) adds further to the
SA establishment time and creates another attack point for denial of
service.

Steve

From: =?iso-8859-1?Q?H=E4ger=F6=2C_Per?= <[email-masked]>
To: "'Robert Klerer'" <[email-masked]>, [email-masked]
Subject: SV: Searching a directory for certs
Date: Thu, 14 May 1998 21:13:38 +0200
Sender: [email-masked]

Hi !

You could set up the Access Control to not returning the e-mail =
addresses
(and other info) for an entry if that the search is issued by an =
anonymous
user. Or restrict the search to only return one match since the search =
your
doing on e-mail address should only return one match (that is if the =
user
doesn=B4t have more than one entry).

-------------------------------------------
Med V=E4nlig H=E4lsning / Best Regards
Per H=E4ger=F6
Senior Consultant & Product Manager
WM-data
Tel +46 8 7758204 | Fax +46 8 7758322=20
E-post: [email-masked]
------------------------------------------------------------------------=
----
---

> -----Ursprungligt meddelande-----
> Fr=E5n:	Robert Klerer [SMTP:[email-masked]]
> Skickat:	 den 14 maj 1998 18:34
> Till:	[email-masked]
> =C4mne:	Searching a directory for certs
>=20
> I=A0 looked through the archive and I did not find this issue, let me
> apologize if I am re-visiting a prior discussion.
>=20
> I am setting up a directory for a network provider, one of whose =
purposes
> is to be a certificate repository for several different =
organizations.=A0
> One of our requirements is to minimize the information disclosure for
> anonymous access.=A0
>=20
> For some of my services I know the DN of the other party, so a "read" =
of
> the directory (section 6 of draft-ietf-pkix-ipki2opp-07) can retrieve =
the
> certificate.=A0 But for email, I usually know the email address and =
perform
> a search (section 7 of draft-ietf-pkix-ipki2opp-07) returning the
> certificate and DN.=20
>=20
> What is stopping someone from searching for all of the email address =
in a
> organization to populate a commercial mailing list.=A0 My directory =
tool
> does not allow me to distinguish search type (exact match vs =
substring) by
> strength of bind.
>=20
> As we have the "read" by DN, do we need a "read" by email address - =
exact
> match, single returned entry?=A0=20
>=20
> =A0
>=20
> BTW:=A0 The change comments to the draft still points to tandem.com
>=20

Date: Thu, 14 May 1998 15:02:53 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Thanks!

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

 Stephen> Paul,
 >> Scenario: I build a box that implements IPsec, with IKE, with
 >> certificate based authentication.  Let's assume these are PKIX
 >> certificates as opposed to some other kind.
 >> 
 >> The box is an IP box, so the customer (i.e., the network support
 >> personnel there) understand very well how DNS names, IP addresses,
 >> and such things are administered.
 >> ...
 >> Now here's the issue: the customer has to set up access
 >> authorization to this box (i.e., the right to establish IPsec
 >> SAs).  This means creating certs for each of the end users that
 >> will be speaking IPsec to this box.  What do we tell them?  What
 >> sort of names should be used?  Who administers them?  What tools
 >> are used to do so?  What are the directories that are used (not
 >> just conceptually -- what products)?

 Stephen> The most likely choices for user certs IDs are IP addresses
 Stephen> (if they are statically assigned), DNS names (if there is a
 Stephen> one-to-one user-to-host mapping and it's static), or rfc822
 Stephen> names (for pure user identification).  All of these are ID
 Stephen> forms you administrators are familiar with, as you specified
 Stephen> the scenario, so issuance of certs based on any of these
 Stephen> name forms should be "natural."  Each of these name forms
 Stephen> can be represented in certs as AltNames, or using standard
 Stephen> or ad hoc DN-embedding conventions.  For IPsec, we are
 Stephen> defining the preferred represnetations for these Internet
 Stephen> name forms, and the current draft on this topic calls for
 Stephen> use of the AltName formats, not DNs.

I thought that AltNames made sense here, which is why I'm
puzzled/disturbed at apparent efforts to restrict the use of
AltNames.  If they are inappropriate for certain uses (which may be
the case, though that isn't yet clear to me) then the obvious answer
is to document those cases and recommend in the spec (or, maybe,
require) to avoid AltNames for those specific situations.

 Stephen> Also, for IPsec, t is not clear that one needs to go to a
 Stephen> directory to fetch certs for users or firewalls.  One can
 Stephen> exchange the certs as part of the IKE negotiation, in real
 Stephen> time.  Since you note that the users have to be autorized
 Stephen> for access, not just random public users, then the
 Stephen> distribution of certs (including CA certs) can be managed as
 Stephen> part of the enrollment process, which would also involve
 Stephen> creating ACL entries (SPD entries, to use IPsec
 Stephen> terminology).

Yes, IKE has that mechanism, but by analogy with things like RADIUS it 
may also be attractive to put the applicable certs in a central place
where the IPsec box can find them.

	paul

Date: Thu, 14 May 1998 14:29:11 -0400
To: Paul Koning <[email-masked]>, [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

Paul,

>Scenario: I build a box that implements IPsec, with IKE, with
>certificate based authentication.  Let's assume these are PKIX
>certificates as opposed to some other kind.
>
>The box is an IP box, so the customer (i.e., the network support
>personnel there) understand very well how DNS names, IP addresses, and
>such things are administered.
>
>Presumably we could (as, say, Netscape did) supply a handful of top
>level certificates along with the product to help bootstrap the cert
>hierarchy.  That might include an additional level: a top level cert
>for the customer (if he doesn't have one yet).

If the users are going to form closed communities, then I would not suggest
embeding CA certs by default, the way browsers do.  They are addressing a
different sort of user environment.

>Now here's the issue: the customer has to set up access authorization
>to this box (i.e., the right to establish IPsec SAs).  This means
>creating certs for each of the end users that will be speaking IPsec
>to this box.  What do we tell them?  What sort of names should be
>used?  Who administers them?  What tools are used to do so?  What are
>the directories that are used (not just conceptually -- what
>products)?

The most likely choices for user certs IDs are IP addresses (if they are
statically assigned), DNS names (if there is a one-to-one user-to-host
mapping and it's static), or rfc822 names (for pure user identification).
All of these are ID forms you administrators are familiar with, as you
specified the scenario, so issuance of certs based on any of these name
forms should be "natural."  Each of these name forms can be represented in
certs as AltNames, or  using standard or ad hoc DN-embedding conventions.
For IPsec, we are defining the preferred represnetations for these Internet
name forms, and the current draft on this topic calls for use of the
AltName formats, not DNs.

Also, for IPsec, t is not clear that one needs to go to a directory to
fetch certs for users or firewalls.  One can exchange the certs as part of
the IKE negotiation, in real time.  Since you note that the users have to
be autorized for access, not just random public users, then the
distribution of certs (including CA certs) can be managed as part of the
enrollment process, which would also involve creating ACL entries (SPD
entries, to use IPsec terminology).

You asked who administers the certs.  This depends on the environment, but
it often will be the same IT folks who manage the IPsec technology,
probably the firewall folks.  They can make use of IPsec as an alternative
user authentication technology, just as they maintain accounts in Radius
servers, etc.  I'd rather not comment on specific products available today,
but most IPsec firewall vendors I have seen have some form of cert issuing
capability available with their products.

Steve

From: [email-masked]
To: Stephen Kent <[email-masked]>
Date: Thu, 14 May 1998 14:17:39 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>If you don't agree on the difference between object classes defined by
>X.500 in the context of their definition of DNs, and the ITEF generating a
>standard that also defines how to represent DNS names in DNs, I don't we
>can have a useful conversation in this regard.

Maybe you could explain further the distinction you are trying to draw.
The X.500 series goes to great lengths to separate the abstract definition
of the directory (which is where DNs are defined) from the details of
particular attribute types and name-forms of the DNs that populate it.
X.501 says that the directory schema (which includes specification of the
DIT structure) is itself distributed, and that each administrative
authority establishes the part of the schema that applies to those portions
of the DIB it is responsible for.  The introduction to the X.521 spec
(which contains selected object classes and suggested name-forms) says that
"any Administrative Authority may define its own object classes or
subclasses for any purpose", although it does have a note that says that
"It is recommended that an object class defined by this document, or a
subclass derived from one, be used in preference to the generation of a new
one, whenever the semantics is approriate for the application".  Annex B of
X.521 (which contains "suggested name-forms", and is where the object
classes are arranged into name-forms and DIT structures, and where the
"/C=/O=/OU=/CN=" Organizational Person name form is defined) is marked as
being not an integral part of the standard.

RFC 2247 provides a good reason to define its own classes and name-forms -
the fact that none of the X.521 definitions are appropriate for DNS names -
and, in acordance with X.521, defines its own object classes to represent
objects named this way.  This name-form appears to be defined in full
accordance with the standard, so I really don't understand the grounds for
treating it as any less "real" than one of the X.521 "suggested
name-forms".

John

Date: Thu, 14 May 1998 13:47:00 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Having supplied some of the fuel for this discussion, I think I should 
supply a bit more to help explain just why this issue is bothering me
so much.

(Part of it comes from having sat through endless discussions in the
ATM Forum which basically amounted to "what do I tell the customers
that buy my boxes about how to get an ATM address".  The same sort of
issue comes up here.)

Scenario: I build a box that implements IPsec, with IKE, with
certificate based authentication.  Let's assume these are PKIX
certificates as opposed to some other kind.

The box is an IP box, so the customer (i.e., the network support
personnel there) understand very well how DNS names, IP addresses, and 
such things are administered.  

Presumably we could (as, say, Netscape did) supply a handful of top
level certificates along with the product to help bootstrap the cert
hierarchy.  That might include an additional level: a top level cert
for the customer (if he doesn't have one yet).

Now here's the issue: the customer has to set up access authorization
to this box (i.e., the right to establish IPsec SAs).  This means
creating certs for each of the end users that will be speaking IPsec
to this box.  What do we tell them?  What sort of names should be
used?  Who administers them?  What tools are used to do so?  What are
the directories that are used (not just conceptually -- what
products)?

	paul

Date: Thu, 14 May 1998 13:20:58 -0400
To: [email-masked], Stephen Kent <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

John,

>>>I agree, and in particular it's wrong to claim that an RFC 2247 name is
>>>somehow less "real" or more of a hack than an X.521 OrganizationalPerson
>>>name.
>>
>>Well, OrganizationalPerson is defined as a class in X.500, and DNs are
>>defined in X.500, but RFC 2247 is not X.500 and so I do think it has a
>>lesser standing, if only on that basis.
>
>OrganizationalPerson is defined within the X.500 series in a document
>titled "Selected Object Classes", not "The Most Important Object Classes",
>or "The Only Object Classes That May be Used".  The introduction to this
>document say that it contains definitions that may be useful across a range
>of applications of the directory.  The sorts of applications the writers of
>the document had in mind related to retrieving information (such a
>telephone numbers) primarily about people, not to retrieving X.509
>certificates for Internet hosts.  It shouldn't be any suprise that things
>deemed to be "useful" in the first context aren't particularly helpful in
>the second, nor should it be any suprise that names that do turn out to be
>useful in the second context weren't specified in a document addressed to
>the first.  That X.521 didn't define an object class for "InternetDNSname"
>doesn't give RFC 2247 names any lesser standing than the name forms that
>_are_ defined there.

If you don't agree on the difference between object classes defined by
X.500 in the context of their definition of DNs, and the ITEF generating a
standard that also defines how to represent DNS names in DNs, I don't we
can have a useful conversation in this regard.

Steve

From: [email-masked]
To: Stephen Kent <[email-masked]>
cc: [email-masked]
Date: Thu, 14 May 1998 13:00:37 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

>>I agree, and in particular it's wrong to claim that an RFC 2247 name is
>>somehow less "real" or more of a hack than an X.521 OrganizationalPerson
>>name.
>
>Well, OrganizationalPerson is defined as a class in X.500, and DNs are
>defined in X.500, but RFC 2247 is not X.500 and so I do think it has a
>lesser standing, if only on that basis.

OrganizationalPerson is defined within the X.500 series in a document
titled "Selected Object Classes", not "The Most Important Object Classes",
or "The Only Object Classes That May be Used".  The introduction to this
document say that it contains definitions that may be useful across a range
of applications of the directory.  The sorts of applications the writers of
the document had in mind related to retrieving information (such a
telephone numbers) primarily about people, not to retrieving X.509
certificates for Internet hosts.  It shouldn't be any suprise that things
deemed to be "useful" in the first context aren't particularly helpful in
the second, nor should it be any suprise that names that do turn out to be
useful in the second context weren't specified in a document addressed to
the first.  That X.521 didn't define an object class for "InternetDNSname"
doesn't give RFC 2247 names any lesser standing than the name forms that
_are_ defined there.

John

From: [email-masked]
To: Stephen Kent <[email-masked]>
cc: [email-masked]
Date: Thu, 14 May 1998 12:40:27 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Stephen Kent <[email-masked]>, in reply to Bob Jueneman writes:

>>In answer to John's last point, I agree that it would be possible
>>and under some circumstances desirable, to provide those alternative,
>>not rigidly bound names or other attributes by means of a directory.
>>But although I very much WANT to be able to look up certificates, CRLs,
>>etc. in a directory, I don't think that users should be COMPELLED
>>to.
>
>And I believe that users ought not be compelled to "make up" DNs when they
>have perfectly good DNS names!

Nobody's suggesting that users should make up DNs.  The suggestion is that
they (or rather the CA they register with) should follow an IETF standards
track RFC (RFC 2247) that defines a simple syntactic mapping from DNS name
"a.b.c.d" to DN "/DC=d/DC=c/DC=b/DC=a" (or "DC=a,DC=b,DC=c,DC=d" to use the
LDAP printable syntax).  RFC 2247 defines the two name forms as equivalent
- different ways of representing the same underlying abstract name, just as
the two strings "a.b.c.d" and "A.B.C.D" are merely different ways or
representing the same underlying DNS name.

John

From: "Robert Klerer" <[email-masked]>
To: <[email-masked]>
Subject: Searching a directory for certs
Date: Thu, 14 May 1998 12:34:12 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01BD7F34.994F9B40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I  looked through the archive and I did not find this issue, let me =
apologize if I am re-visiting a prior discussion.

I am setting up a directory for a network provider, one of whose =
purposes is to be a certificate repository for several different =
organizations.  One of our requirements is to minimize the information =
disclosure for anonymous access.=20

For some of my services I know the DN of the other party, so a "read" of =
the directory (section 6 of draft-ietf-pkix-ipki2opp-07) can retrieve =
the certificate.  But for email, I usually know the email address and =
perform a search (section 7 of draft-ietf-pkix-ipki2opp-07) returning =
the certificate and DN.=20

What is stopping someone from searching for all of the email address in =
a organization to populate a commercial mailing list.  My directory tool =
does not allow me to distinguish search type (exact match vs substring) =
by strength of bind.

As we have the "read" by DN, do we need a "read" by email address =96 =
exact match, single returned entry? =20

BTW:  The change comments to the draft still points to tandem.com

------=_NextPart_000_0010_01BD7F34.994F9B40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.2016.0"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>
<P><FONT size=3D3>I&nbsp; looked through the archive and I did not find =
this=20
issue, let me apologize if I am re-visiting a prior =
discussion.</FONT></P>
<P><FONT color=3D#000000><FONT size=3D3>I am setting up a directory for =
a network=20
provider, one of whose purposes is to be a certificate repository for =
several=20
different organizations.&nbsp; One of our requirements is to minimize =
the=20
information disclosure for anonymous access.</FONT></FONT><FONT=20
size=3D3></FONT>&nbsp;</P>
<P><FONT size=3D3>For some of my services I know the DN of the other =
party, so a=20
&quot;read&quot; of the directory (section 6 of =
draft-ietf-pkix-ipki2opp-07) can=20
retrieve the certificate.&nbsp; But for email, I usually know the email =
address=20
and perform a search (section 7 of draft-ietf-pkix-ipki2opp-07) =
returning the=20
certificate and DN. </FONT></P>
<P><FONT size=3D3>What is stopping someone from searching for all of the =
email=20
address in a organization to populate a commercial mailing list.&nbsp; =
My=20
directory tool does not allow me to distinguish search type (exact match =
vs=20
substring) by strength of bind.</FONT></P>
<P><FONT size=3D3>As we have the &quot;read&quot; by DN, do we need a=20
&quot;read&quot; by email address &ndash; exact match, single returned=20
entry?&nbsp; </FONT></P>
<P><FONT color=3D#000000 face=3D"" size=3D3></FONT>&nbsp;</P>
<P><FONT color=3D#000000 face=3D"" size=3D3>BTW:&nbsp; The change =
comments to the=20
draft still points to tandem.com</FONT></P></DIV></DIV></BODY></HTML>

------=_NextPart_000_0010_01BD7F34.994F9B40--

Date: Thu, 14 May 1998 10:02:20 -0400
To: Olivier Onimus <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage (again!)
Cc: [email-masked]
Sender: [email-masked]

Oliver,

>I may have missed something basic in the (very long) discussion
>you are follwing since several days, but IMO, the "semantics" of
>Alternate name in comparison with "Name" (e.g. for subject)
>is already (well) defined in X.509:
>
>"subject" and "Issuer" in Certificat are of type "Name". Name is defined in
>X.501 as =84SEQUENCE OF RelativeDistinguishedName".  This means that only R=
DNs
>(of a real or a virtual existing DIT) should be present at this level.
>
>In X.509, Chapter. 12.3.1 about the Extensions, it is said:
>
>
>    The following requirements relate to certificate subject and
>    certificate issuer attributes:
>	a) Certificates need to be usable by applications
>           that employ a variety of name forms, including
>           Internet electronic mail names, Internet domain names,
>           X.400 originator/recipient addresses, and EDI party names.
>           It is therefore necessary to be able to securely associate
>           multiple names of a variety of name forms with a certificate
>           subject or a certificate or CRL issuer.
>	b) A certificate user may need to securely know certain
>           identifying information about a subject in order to have
>           confidence that the subject is indeed the person or thing
>           intended. For example, information such as postal address,
>           position in a corporation, or a picture image may be required.
>           Such information may be conveniently represented as directory
>attributes,
>           but these attributes are not necessarily part of the
>distinguished name.
>           A certificate field is therefore needed for conveying additional
>           directory attributes beyond those in the distinguished name.
>
>
>
>What I do understand is, that the attributes of the =84Issuer" or =84Subjec=
t",
>which can not be coded in the fields =84issuer" or =84subject", because=
 they are
>not part of a RDN, can be coded as certificate-extension. That's all.

You may be missing the historical context in which this WG asserted, for
over a year, that DNs were optional for issuers and subjects, IF AltNames
were used.

>With the informations contained in "Issuer", I can identify (as software) a
>tree (DIT)
>in which I can identify in a UNIQUE way (as software) an entry using the
>information contained in "Subject". The extra information contained in the
>extension "AltName" may
>be used for me (as user) to identify the subject or the issuer of the
>certificate in another way. The informations are (as David P. Kemp said)
>"only extra identification information".

This is not the interpretation we have historically applied in this WG.

>Another remark before I finish: I don't want to defend here the x.509-world=
=2E
>I know, PKIX will profile the X.509 world in such a way the whole stuff wor=
ks
>and the designers and the implementors can easily understand what is meant.=
 I
>just thought that this discussion about "Alternate name semantics and usage=
"
>could take something from what is specified in X.509.....

We are aware of the original text, and we had chosen to adopt a different
approach. This was based on the fact that the text assumes an X.500
environment, which is NOT representative of the Internet

Date: Thu, 14 May 1998 10:02:20 -0400
To: Olivier Onimus <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage (again!)
Cc: [email-masked]
Sender: [email-masked]

Oliver,

>I may have missed something basic in the (very long) discussion
>you are follwing since several days, but IMO, the "semantics" of
>Alternate name in comparison with "Name" (e.g. for subject)
>is already (well) defined in X.509:
>
>"subject" and "Issuer" in Certificat are of type "Name". Name is defined in
>X.501 as =84SEQUENCE OF RelativeDistinguishedName".  This means that only R=
DNs
>(of a real or a virtual existing DIT) should be present at this level.
>
>In X.509, Chapter. 12.3.1 about the Extensions, it is said:
>
>
>    The following requirements relate to certificate subject and
>    certificate issuer attributes:
>	a) Certificates need to be usable by applications
>           that employ a variety of name forms, including
>           Internet electronic mail names, Internet domain names,
>           X.400 originator/recipient addresses, and EDI party names.
>           It is therefore necessary to be able to securely associate
>           multiple names of a variety of name forms with a certificate
>           subject or a certificate or CRL issuer.
>	b) A certificate user may need to securely know certain
>           identifying information about a subject in order to have
>           confidence that the subject is indeed the person or thing
>           intended. For example, information such as postal address,
>           position in a corporation, or a picture image may be required.
>           Such information may be conveniently represented as directory
>attributes,
>           but these attributes are not necessarily part of the
>distinguished name.
>           A certificate field is therefore needed for conveying additional
>           directory attributes beyond those in the distinguished name.
>
>
>
>What I do understand is, that the attributes of the =84Issuer" or =84Subjec=
t",
>which can not be coded in the fields =84issuer" or =84subject", because=
 they are
>not part of a RDN, can be coded as certificate-extension. That's all.

You may be missing the historical context in which this WG asserted, for
over a year, that DNs were optional for issuers and subjects, IF AltNames
were used.

>With the informations contained in "Issuer", I can identify (as software) a
>tree (DIT)
>in which I can identify in a UNIQUE way (as software) an entry using the
>information contained in "Subject". The extra information contained in the
>extension "AltName" may
>be used for me (as user) to identify the subject or the issuer of the
>certificate in another way. The informations are (as David P. Kemp said)
>"only extra identification information".

This is not the interpretation we have historically applied in this WG.

>Another remark before I finish: I don't want to defend here the x.509-world=
=2E
>I know, PKIX will profile the X.509 world in such a way the whole stuff wor=
ks
>and the designers and the implementors can easily understand what is meant.=
 I
>just thought that this discussion about "Alternate name semantics and usage=
"
>could take something from what is specified in X.509.....

We are aware of the original text, and we had chosen to adopt a different
approach. This was based on the fact that the text assumes an X.500
environment, which is NOT representative of the Internet, it's use of other
names forms and it's deployment of the DNS anw web servers as alternative
repositories for certs, CRLs, etc.

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: Bob Jueneman <[email-masked]>, [email-masked]
Sender: [email-masked]

John,

>>Peter said that one of the primary uses of alternate names
>>was to accommodate those name forms that can't be a DN,
>>e.g., almost everything useful.  I have to strongly disagree with
>>that notion, which I thought we had overthrown back in the
>>PEM days.
>>
>>To the best of my knowledge, the ITU does not act as any kind of
>>a schema registration "authority" for X.500 or anything else.
>>Nor, even less, do they act as a name registration authority for
>>names that are defined within any particular schema.
>>
>>So although it might be too strong to say that such a view
>>is ludicrous, I firmly believe that it would be wrong.
>>
>>I may be somewhat notorious for my "MPEG of my cat" view
>>of what a DN can contain, but to the best of my knowledge,
>>anyone who wanted to create an OID and a syntax description
>>for such an attribute would be PURRFECTLY within their rights
>>to include it within their certificate DN. So there is absolutely
>>no reason at all why an RFC822 name, DNS name, or anything else
>>that is at all reasonable could not be contained in a DN.  In
>>particular, neither PKIX, nor X.500, in fact, has to be constrained
>>by the oxymoronic "useful attributes" defined in X.520.
>
>I agree, and in particular it's wrong to claim that an RFC 2247 name is
>somehow less "real" or more of a hack than an X.521 OrganizationalPerson
>name.

Well, OrganizationalPerson is defined as a class in X.500, and DNs are
defined in X.500, but RFC 2247 is not X.500 and so I do think it has a
lesser standing, if only on that basis.

>>And to respond to John's comment, PKIX could in fact totally
>>ignore issues of what kinds of attributes are allowed for a DN
>>in a certificate, and PKIX would still work. Chains could be searched,
>>name constraints applied (assuming the basic comparison syntax is
>>supplied), etc.
>>
>>The only thing that won't work is _interoperability_, especially with
>>various kinds of directories.  Directories, especially most X.500
>>directories, are NOT general purpose relational search engines.
>
>My position is that a relying party shouldn't itself impose schema
>constraints on the names that it is willing to accept.  If it is using a
>directory to retrieve certificates, then that directory may well impose
>restrictions of its own, and that is a good reason for CAs to be careful
>about the sorts of names they issue certificates for, but, assuming that an
>end-system can obtain a certificate, it shouldn't refuse to use that
>certificate in a chain simply because the name contains an attribute that
>the end-system doesn't recognize.

A relying party has to understand the names it accepts, so it is not
unreasonable for it to impose syntactic constraints on such names as a side
effect of facilitating manageable implementations.  For the various
Internet anme forms, we understand the syntax and softwarecan easily
accommodate it. For arbitrary DNs, with unusual "(what the heck, I got an
OID for it") attributes, this is an unreasonable assumtion.

>>Most X.500 and similar directories I know of can find almost
>>anything very quickly, but ONLY if the search arguments have
>>been predefined as some kind of a filter. So given a name, you
>>can look up anything that is filed under that name, including say
>>street address, telephone number, e-mail address, certificates, and
>>the obligatory cat picture.
>>
>>Likewise, if you PREDEFINE the appropriate filters, you can look up
>>what is effectively an alias that doesn't have to be created specifically,
>of
>>say my telephone number, and get back a pointer to my name and all
>>the rest.
>>
>>But unless you have predefined it, you cannot enter a picture of my cat,
>>or even my e-mail address, and find anything else, unless you are
>>prepared to search the ENTIRE database for a match.
>>
>>Therefore, the CAs and the director service providers are going to
>>HAVE to play a strong role in defining what kind of names (schemas)
>>are acceptable if we want directories to work at all. Since PKIX is active
>>in this field, I would hope they would take the initiative, otherwise, I
>would
>>expect that the CAs would get together and decide for themselves --
>>after all, they have to sign the certificate containing the DN, and
>>presumably they take some degree of responsibility for the contents.
>
>I think this is an important thing to do, however, I don't think we need to
>hold up PKIX-1 for it.  PKIX-1 should explicitly allow names constructed
>using arbitrary attribute types.

We agree here.  Such schema definition is outside the scope of PKIX.

>>So my view is that the DN should contain names that are agreed within
>>the community to fall within an acceptable schema, AND ARE
>>SEARCHABLE WITHIN  A DIRECTORY. Otherwise, I would argue,
>>there is no reason to have a DN at all.
>
>Not all certificates necessarily need to be obtained from a directory,
>though.  An application protocol is entitled to provide some portion of the
>certificate chain needed to establish trust in the final key, so if a
>certificate is always used in the context of such a protocol, the fact that
>it might contain names using unusual schema ought not to matter, provided
>that the relying party can correctly verify that the subject of one cert
>"matches" the issuer of the next. Of course, with an unknown attribute,
>matching is a little tricky, but there is text pending for inclusion in
>PKIX-1 that specifies binary matching for all string syntaxes other than
>printableString, and while I'm not sure of the wisdom of doing this when an
>end-system knows how to apply X.520 matching rules, I think it's a
>perfectly acceptable fallback position for a relying party to take for
>attributes it doesn't recognise.

Precisely because not all certs need to be retrieved from an LDAP or X.500
directory, it is inappropriate to mandate DNs for all issuers of PKIX
compliant certs.

[remainde of message deleted because it just rehashes previous material
which I never liked in the first case ... :-)]

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: "David P. Kemp" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

David,

>> Apologies if I'm asking something that should be obvious from reading
>> the specs, but this long discussion makes me wonder.
>>
>> In much of the world we live in, it's well understood how to get
>> (a) an IP address, (b) a DNS name.
>>
>> On the other hand, X.500 style names (i.e., strings of the form "C=US,
>> ORG=bar, FOO=xxx...") are, most of the time, going to be received with
>> "what the heck is *that*?".  That's not a problem if we can simply
>> write some documentation to make it clear.
>
>Is it clear that an X.500 style name of the form "E=[email-masked]"
>means what one would expect it to mean?  The emailAddress DN attribute
>(1.2.840.113549.1.9.1, commonly abbreviated as "E") is already used
>in many certs.  Unfortunately, many CAs generally include it in
>a meaningless mishmash of a DN
>("C=US, ORG=Bar, CN=Fred Jones, E=[email-masked]") in which the fourth RDN
>has no subordinate relationship to the third; this misuse is what
>prompted the ITU to define GeneralName in the first place.
>But IMHO the proper response to DN abuse is not to create a whole new
>syntax, but to define a schema which would demonstrate the proper use
>of the existing DN syntax.

Yes, that's a very reaonsonable interpretation of such a DN.  But what
purpose is served by such a construct?  Most of the folks who are pushing
for DNs want to use them for LDAP or X.500 lookups.  This DN would be much
easier to lookup in the DNS than in any X.500 directory I know.

>
>> Does it amount to re-encoding the DNS name into a different syntax?
>
>Yes.
>
>> That works (except for the pain of explaining why a different syntax
>> that doesn' have any different semantics is useful).
>
>If one is prepared to require that all certs with DNS subjects are
>End Entity certs, then there is no difference in semantics and no reason
>to have a multi-RDN syntax for DNS names.

I am arguing for DNS names in issuer certs, not just end entities.

>However, DNS doesn't work that way.  It's a heirarchy, with registration
>delegated to administrators at lower levels.  If you want the CA topology
>to mirror the DNS administrative topology, then you want the CA for
>"DC=net, DC=vaultline" to be able to issue a CA cert for
>"DC=net, DC=vaultline, DC=santaclara" and have the normal name
>constraint process work as expected.  The ITU has not defined any
>processing rules to go along with GeneralName, so the semantics of the
>multi-RDN form *is* different than the undefined semantics of a single
>subjectAltName string of "dNSName=santaclara.vaultline.net".
>

We agree on this point.

>> Or does it
>> requiring going to a different authority and getting an additional
>> name in a different naming hierarchy?
>
>No!

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: Bob Jueneman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Bob,

>No apologies are necessary.  The questions you are asking are in fact
>recorded very precisely in the original X.DOT specifications. Unfortunately
>the specs are copyrighted and can only be referenced by visting the archives
>on the planet Vogon in person, after payment of 1000 International Standard
>Units of platinum, ISO 4217 alpha currency code XPT, numeric
>funds code 962. Unfortunately ISO 4217 does not specify what the
>standard units ARE, but only their names, so it might be grams, troy
>ounces, or mean solar mass equivalent.  Probably it is the latter,
>so bring your American Express card.
>>
>>In much of the world we live in, it's well understood how to get
>>(a) an IP address, (b) a DNS name.
>
>Actually, in MOST of the world we live in, it is far from obvious how one
>goes about getting an IP address, or even an DNS name.  Take a poll
>of 1000 AOL newbies, and ask them whether they fully understand the
>intricacies of DHCP, for example. I certainly don't pretend to.  Likewise
>a DNS name, if I'm behind a firewall on a corporate network.

The question is not whether folks who are unaware of Internet name spaces
know how to get such names.  You're needlessly confusing the issue.

>>On the other hand, X.500 style names (i.e., strings of the form "C=US,
>>ORG=bar, FOO=xxx...") are, most of the time, going to be received with
>>"what the heck is *that*?".  That's not a problem if we can simply
>>write some documentation to make it clear.

Clear, yes. Authoritative, unambiguous, and unique, no.

>On the other hand, I would suggest that most people _would_ understand
>a question such as "what country do you live in, i.e., what is your primary
>residence?" (We won't get into residence vs. domiciles).
>
>And most people would be able to answer the question, "What is the
>name of the organization you work for or are associated with?"
>
>Depending on the frequency of organization updates, answering a question
>about organizational units might be a bit more difficult, I suppose.
>
>Now the trickiest of all might be "What is your name?"  But that is
>because standards organizations, unfortunately including PKIX , worry
>excessively about the obscure minutia, and never get around to specifying
>whether the form is last name first, first name last, or what a surname is.
>I suppose it is due to early toilet training, or something -- anal retentive,
>I think it's called.

Bob, how can you, of all people, say this.  You have been the primary
progenitor of minutae in these discussions for almost a decade!

>Hopefully, the public CAs will enforce some discipline on this process,
>and if they don't, some very small number of dominant vendors will
>do so (unless the Justice Department gets into the act). At least I hope so.
>
>Notice that nowhere in this process did I ever use such X.400 business
>card jargon as c=US,O=foo, cn=Bar.  And anyone's GUI that does
>use such junk ought to be banned, at least if it is intended for the
>casual user.
>
>(If, however, it is the network administrator, or the directory administrator,
>or other reasonably skilled person who is filling out these screens, then
>a certain latitude can perhaps be tolerated.  Just like doctors and lawyers,
>system administrators have to use a specialized language to communicate
>with their brethren, or anybody might be able to do this stuff! :-)
>>
>>However, what *is* critical is that there has to be a well defined,
>>easily executed, and effective way for people to obtain the names they
>>need.  It isn't clear to me yet from the discussion whether this is
>>the case, or if so, what the process is.
>
>People don't OBTAIN names, they HAVE names, or they are given them,
>typically by their parents. People who work for organizations and choose
>(or are told) to use that organizational person class (excuse the jargon)
>inherit those names. People who chose to be identified by their residential
>addresses look on their mailbox. People who only want to be identified by
>obscure 8 character e-mail names have to ask their system administrator
>what they should use, to make sure it doesn't give away corporate secrets.

The names people HAVE and not DNs!  They are DNS names, RFC822 names, IP
addresses, URLs, account numbers with varioiusorganizations, etc.  None of
these is a natural DN.  Also, we all have lots of names and no single DN
will suffice to meaningfully identify us in all the contexts in which we
communicate.

[rest of text snipped because I can't stand it anymore ...]

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: Bob Jueneman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Bob,

>This has been a very illuminating discussion.
>
>First off, I suppose I should apologize for using the term "ludicrous."
>I did not mean to deprecate anyone's opinion that differed from
>mine. But there are apparently some rather divergent views.
>
>Peter said that one of the primary uses of alternate names
>was to accommodate those name forms that can't be a DN,
>e.g., almost everything useful.  I have to strongly disagree with
>that notion, which I thought we had overthrown back in the
>PEM days.

As the PEM WG chair, that's not my recollection of the outcome ofn our
discussions 'way back then.

>To the best of my knowledge, the ITU does not act as any kind of
>a schema registration "authority" for X.500 or anything else.
>Nor, even less, do they act as a name registration authority for
>names that are defined within any particular schema.
>
>So although it might be too strong to say that such a view
>is ludicrous, I firmly believe that it would be wrong.

That's not my point Bob, as I mentioned in a previous message.

>I may be somewhat notorious for my "MPEG of my cat" view
>of what a DN can contain, but to the best of my knowledge,
>anyone who wanted to create an OID and a syntax description
>for such an attribute would be PURRFECTLY within their rights
>to include it within their certificate DN. So there is absolutely
>no reason at all why an RFC822 name, DNS name, or anything else
>that is at all reasonable could not be contained in a DN.  In
>particular, neither PKIX, nor X.500, in fact, has to be constrained
>by the oxymoronic "useful attributes" defined in X.520.

You could do it, and it would be as inappropriate as a DN now as it was
when you first suggested it.

>And to respond to John's comment, PKIX could in fact totally
>ignore issues of what kinds of attributes are allowed for a DN
>in a certificate, and PKIX would still work. Chains could be searched,
>name constraints applied (assuming the basic comparison syntax is
>supplied), etc.
>
>The only thing that won't work is _interoperability_, especially with
>various kinds of directories.  Directories, especially most X.500
>directories, are NOT general purpose relational search engines.

No, they are not, and they also are not the only game in town.

>Most X.500 and similar directories I know of can find almost
>anything very quickly, but ONLY if the search arguments have
>been predefined as some kind of a filter. So given a name, you
>can look up anything that is filed under that name, including say
>street address, telephone number, e-mail address, certificates, and
>the obligatory cat picture.
>
>Likewise, if you PREDEFINE the appropriate filters, you can look up
>what is effectively an alias that doesn't have to be created specifically, of
>say my telephone number, and get back a pointer to my name and all
>the rest.
>
>But unless you have predefined it, you cannot enter a picture of my cat,
>or even my e-mail address, and find anything else, unless you are
>prepared to search the ENTIRE database for a match.
>
>Therefore, the CAs and the director service providers are going to
>HAVE to play a strong role in defining what kind of names (schemas)
>are acceptable if we want directories to work at all. Since PKIX is active
>in this field, I would hope they would take the initiative, otherwise, I
>would
>expect that the CAs would get together and decide for themselves --
>after all, they have to sign the certificate containing the DN, and
>presumably they take some degree of responsibility for the contents.
>
>So my view is that the DN should contain names that are agreed within
>the community to fall within an acceptable schema, AND ARE
>SEARCHABLE WITHIN  A DIRECTORY. Otherwise, I would argue,
>there is no reason to have a DN at all.

I, for one, am not willing to defer to the whims of directiry service
providers.  This model strikes me as outdated, especially given the lack of
substantive directory services being offered in the X.500 domain.

>At the admitted risk of overloading the semantic content of the
>DN, I would also propose that the DN comport more or less well with
>the more or less "official" name of the subject, i.e., the name that is
>legally
>recognized as being associated with that entity.  That doesn't necessarily
>rule out the use of an e-mail address in the appropriate contexts, but it
>probably does rule out my cat.  (We sometimes have a disagreement on
>this issue, but I claim that I own the cat, not vice versa. Not to get into
>SPKI semantics, but my name is a legitimate qualifier for the cat, not
>the other way around, at least until he can open his own cans of cat food.)

This is where value judgements become critical, since there is no arbiter
for DNs, and CAs ought not have to make such judgements.  It only provides
business for lawyers!

>So what purpose is or should be served by alternate names?
>
>Well, in my view, at least, they are representations made by the subscriber
>to the CA, and hence to relying parties, and as such may have certain legal
>consequences. So even if the CA does not have the resources to do a full
>due diligence investigation of their veracity, that doesn't mean that a
>subscriber is entitled to make any representations he wishes in this regard.

On this later point we agree, but I think of AltNames as primary,
verifiable IDs in the cases in question, not ancilliary IDs.

>Ideally, anything contained in an alternate name should carry an explicit
>Nonverified Subscriber Information flag, in order to make this much clearer.
>But failing that, the CA at least ought to spell out in their CPS whether or
>not they independently verify the subscriber's right-to-use and perhaps global
>unambiguity of those attributes.

Bob, we don't have such a flag, despite your urging for several years.
Perhaps the reason is because it's just a bad idea to put such info into a
cert!

[snip material having to do with foreign names and characters sets]

>In answer to John's last point, I agree that it would be possible
>and under some circumstances desirable, to provide those alternative,
>not rigidly bound names or other attributes by means of a directory.
>But although I very much WANT to be able to look up certificates, CRLs,
>etc. in a directory, I don't think that users should be COMPELLED
>to.

And I believe that users ought not be compelled to "make up" DNs when they
have perfectly good DNS names!

>If this gets to be too much of an impasse, we could always define the
>syntax for an alternate subject (or issuer) name to be a compound attribute,
>and define on a per attribute or even per name basis a Nonverified
>Subscriber Information bit.

Nice try Bob, but we're still not buying into NVI!

>So I would modify David's taxonomy to include a fourth option, which
>would be my preference:
>
>" iv) They are alternative names which are a representation
>made by the subscriber to the CA and/or any relying party
>which may have legal consequences, but which may or
>may not have been independently verified by the CA. They
>may be used by end-systems for display to the user in
>security-related contexts, and may also be used for such
>secondary purposes as automatic e-mail or http address
>confirmation. They are not used in chain-building, certificate
>retrieval, certificate verification, or constraint processing."
>

I vote a strong "NO" for this one.

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: "David P. Kemp" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

David,

>> Alternative Names
>>
>> The subject and issuer alternative names are used to specify all the things
>> which can't be given in a DN, which for most purposes means practically
>> everything of any use on the Internet.
>
>Can't is such a strong word.  "Sometimes aren't given in a DN" is more
>accurate, since rfc822 names are often (incorrectly) included in
>mixed-namespace DNs.  In your experience, what percentage of the certs
>which contain rfc822 names encode them in an AltName extension?

I'll answer for Peter, and say 0%.  But that's understandable since people
were issuing version 1 certs and didn't have a good place to put the rfc822
names.  But, now that we have an AltName syntax for 822 names, we should
use it.

>> This would require an amendment to X.509v3 though, I'm not sure how likely
>> that is to happen.  As it currently stands, the altName semantics are too
>> ambiguous to make it possible to rely on altNames for much.

[snip]

>
>A different solution which does not require an amendment to X.509:
>
> * AltName extensions are never used in path development, only the
>   subject and issuer fields are used.  The AltName extensions are
>   used only for extra identification information, verified or not
>   as described in the CA's CPS.
>
> * subjects which have one true, certified name would have that name
>   encoded as a DN.  RDN attributes already exist for emailAddress and
>   DNS name component.  Additional attributes could be defined to hold
>   the string form of a full DNS name, URI, EDIPartyName, etc.
>   (An alternative, which I don't like but which should be mentioned
>   anyway for completeness, is to define a single attribute with syntax
>   GeneralName which could hold any nameform.)
>
> * subjects which have more than one certified subject name should have
>   more than one certificate.  (I'd argue that those certs should have
>   different public keys, but that's a different thread :-).

Yes, one could do this, but it would be wrong :-)!  This proposal is
essentially a throwback to v1 cert names, plus the notion of non-verified
info (AltNames) in certs, which is a abbrogation of CA responsibility.

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: Bob Jueneman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

Bob,

>My point was that in my view, at least, the primary purpose for alternate
>subject anmes (and even alternate issuer names) was to convey additional
>optional information to the relying party.

Yes, that's an appropriate X.500-centric view, but this is the Internet.
We don't need no stinkin' DNs :-).

>If we start using them to convey all sorts of mandatory contraints, impose
>a requirement to be able to search for them in a directory, etc.,  then I
>think we have started down a different kind of semantics entirely.

We have a global repository in which they fit quite nicely, i.e., the DNS.

>I mentioned something along these lines to Hoyt Kesterson a while ago, and
>I believe he told me that X.500 '97 provides the ability have multiple
>DNs, presumably for the same object.  I clearly don't undertand what the
>difference is between a DN and an alias to a ND in a directory, but having
>multiple DNs is a certificate, quite independent of the altSubjectName
>_semantics_ would be worth exploring, I think.

Good question for someone else.

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: "David P. Kemp" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

David,

>> From: [email-masked]
>>
>> I agree that things are very much simpler if we can
>> prescribe the use of DNs in all certificates, and I'd
>> be quite happy with that restriction.  However, I don't
>> see why PKIX needs to say anything about schema.  PKIX
>> systems ought to be able to handle any X.500 name,
>> regardless of whether that name follows an X.520/X.521
>> schema, or whether it uses some private schema.
>
>John,
>  I agree almost completely.  The exception: PKIX should say something
>about schema: it may reasonably define mandatory and optional schema to
>promote interoperablity.  But PKIX and X.509 should not prohibit the
>use of other (private or agreed-to-elsewhere) schema.
>
>Bob says:
>
>>    The question of who "owns" or registers name in the DN space is not
>>    only ludicrous, but moot.  CAs are going to define them, and
>>    directory service providers are going to decide whether or not that
>>    schema is acceptable for their directory, and everything else will
>>    spill on the floor.
>
>The question isn't ludicrous, but "own" may have been a poor choice
>of words.  Is there any question that Naming Authorities (such as
>the IETF) exist, and that rfc822 names and DNS names are assigned
>in accordance with a reasonably well defined registration procedure?

We agree. See also my comments to Bob.

>The question of ownership only came up as a result of the assertion
>that the ITU owns the DN structure and that names registered by
>non-ITU NAs such as the IETF could/should not appear in a DN.  I
>wouldn't call this assertion "ludicrous", but I do disagree with it.

I don't think I have said this.  What I meant was that the ITU or its
designates would be the nominal arbiters of DNs, and that we have no such
arbiters.  That is a problem, irrespective of use of the term "owns."

>Schemas will be defined by PKIX and privately, and as you say, CAs,
>application developers, and directory providers will decide which schemas
>to support.  Schemas for representing rfc822 and DNS names as RDN
>attributes should live or die based on their utility, not be automatically
>rejected because "the ITU owns the DN space" and defines an AltName
>extension to hold those other names.
>
Schema definition is a directory issue, not a PKIX issue, though I admit
the common interest.  We defined an LDAP schema for management objects only
when requested by the IESG, as we were developing new objects.  For DNs,
this is not the case and I believe it is outside of our charter.
>
>
>> So, we have at least three different possible sets of
>> semantics for the AltName fields:
>>
>> i)  They are "official" names, and should be used to
>> link certificates together in chain-building (perhaps
>> only if there aren't DNs in ther certificates).  The
>> current PKIX-1 draft is consistent with this
>> interpretation, but doesn't define how the linkage is
>> to be performed.
>>
>> ii) They are nicknames, chosen by the end-system and
>> unverified by the CA.  They are therefore not to be
>> believed by end systems, and should not be displayed
>> to the user in any security-related context.  They are
>> not used in chain-building.
>>
>> iii) They are approved alternative names, verified by
>> the CA, and may be used by end-systems for display to
>> the user in security-related contexts.  They are not
>> used in chain-building.
>>
>> We need to decide what these names mean, and what an
>> end-system is required/permitted to do with them
>> before we can include them in the PKIX profile.
>
>
>My vote is for ii) or iii): AltName extensions are prohibited in chain
>building.  Verifying (and the strength of verification) is a matter to
>be described in the CPS.  Displaying is a UI issue - don't go there.

I vote for i!

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

John,

>
>So, we have at least three different possible sets of
>semantics for the AltName fields:
>
>i)  They are "official" names, and should be used to
>link certificates together in chain-building (perhaps
>only if there aren't DNs in ther certificates).  The
>current PKIX-1 draft is consistent with this
>interpretation, but doesn't define how the linkage is
>to be performed.

This is my position and I agree that Part 1 needs to do a better job to
address the processing of AltName-only certs.

>ii) They are nicknames, chosen by the end-system and
>unverified by the CA.  They are therefore not to be
>believed by end systems, and should not be displayed
>to the user in any security-related context.  They are
>not used in chain-building.

And if one does this, I question the appropriateness of putting them in a
cert, just as you do.

>iii) They are approved alternative names, verified by
>the CA, and may be used by end-systems for display to
>the user in security-related contexts.  They are not
>used in chain-building.

One might do this, but for the Internet context I believe this is an
inppropriate interpretation for DNS names, RFC822 Names, IP addresses and
URLs.

>We need to decide what these names mean, and what an
>end-system is required/permitted to do with them
>before we can include them in the PKIX profile.

Agreed.

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: Bob Jueneman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

Bob,

>My very strong preference is to mandate the use of DNs in certificates,
>both for end-entities and especially for CAs.  And the schema for these
>DNs ought to be drawn from a rather limited set of the allegedly "useful
>attributes" defined in X.520, unless or until PKIX gets around (after five
>years and counting) to defining an acceptable schema.

You and John Wray both advocate DNs for issuers, but your motivations and
his don't  match.  I'm very much opposed to imposing constraints on DNs for
PKIX compliance, because I see too many opportunities to create useful,
closed PKIs where the form of the Dn should be dictated solely by the CA.
In open PKIs, DNs conforming to a well-defined schema would be good, if
only we had X.500 (instead of LDAP) to work with, and if someone were
authoritative for the DNs.  Absent these facilities, I cannot endorse
mandating DN use of issuers, especially in cases where the names are really
drawn from other spaces where we have well-defined AltName extensions.

>Given such a restriction, I can at least be guaranteed a way of finding
>and/or revoking a certificate, although adding the hash of the public key
>would be better yet.

No you can't, given the state of directories.

>I really can't take seriously any proposal to apply name subordination
>constraints, etc., on subjectAltNames when the intent was to be rather
>loose about what those names were intended to contain.

We disagree.  The IETF is the cognizant body for deciding how to employ
DNS, RFC822, and IP address AltNames.  Until very recently, the PKIX Part 1
spec was explicit about NOT requiring use of issuer or subject DNs.  I'd
like to maintain that feature.

>The question of who "owns" or registers name in the DN space is not only
>ludicrous, but moot.  CAs are going to define them, and directory service
>providers are going to decide whether or not that schema is acceptable for
>their directory, and everything else will spill on the floor.

Again we disagree, and I'm a CA.  (Well, I'm the CTO for a major CA; close
enough!)  This approach has gotten us terrible bastardizations of DNs in
many certs now, but we have an opportunity to avoid that in the future.

>The thread that John was discussing may or may not have been the one on
>cert-talk where I was discussing what to do about multilingual countries,
>but there is clearly a need to define at least "roughly equivalent" names
>that are either official or unofficial translations or transliterations of
>the presumably "official" primary DN.

Nope, wrong thread.  Following text related to it deleted ...

>It has even been suggested that we should take advantage of the "other
>name" form, and allow a JPEG logo to be included in subjectAltName, and
>presumably issuerAltName as well. I think that is a very reasonable
>suggestion, as the logo is more likely to be recognized internationally
>than the name, whether translated or not. but obviously I don't expect to
>do a name search against a logo, much less a name subordination constraint.

I too am in favor of including a JPEG logo for registered trademarks, for a
similar reason.  The goal of a cert is to identify the holder of the
corresponding private key, in a fashion meaningful to relying parties.  The
problem we face with DNs is a lack of authoritative sources, which forces a
CA to make a value judgement about whether the assertede DN is appropriate,
given some set of supporting documentation.  In contrast, we have the
requisite, authoritative sources for DNS names, etc. and we ought to make
use of them.  However, since a user may guess a DNS name for a well-known
organization and find that the target is not the one he/she expected, I'm
in favor of including a logo as a means of minimizing confusion.  it would
be nice, though, of we could keep the size down.

>Although it is (normally) perfectly feasible for a directory provider to
>map the alternate names to directory aliases, this isn't a universal
>requirement. the relying party can either do it or not, as he sees fit.

I don't care.  I'm more interested in the innate accuracy of the AltName
construct than it's use as an alias.= in and X.500 directory.

>So my bottom line is that the alternate names should be primarily intended
>for use as a human-readable confirmation of the subscriber's identity, but
>not necessarily for use as a means of searching for that name.

And I say that AltNames should be the primary ID form when the identity is
drawn from a space for which we have an AltName extension and for which
there is an authoritative arbiter of the name space.

>If someone requires that an RFC822 name or a DNS name be included, I would
>think that in most cases it would suffice to include it in the alternate
>name form, and comparisons at the application level can be done against
>that name. If it is absolutely essential to include such a construct in
>the DN, we ought to define an attribute and assign it a suitable OID.  I
>would hate to see the semantics of commonName being debased more and more,
>just because implementors (or standards groups) are too lazy to define
>something more precisely.

This comment suppirts neither my position nor John's, so I'll pass on it.

Steve

Date: Tue, 12 May 1998 18:31:30 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

>>" iv) They are alternative names which are a representation
>>made by the subscriber to the CA and/or any relying party
>>which may have legal consequences, but which may or
>>may not have been independently verified by the CA. They
>>may be used by end-systems for display to the user in
>>security-related contexts, and may also be used for such
>>secondary purposes as automatic e-mail or http address
>>confirmation. They are not used in chain-building, certificate
>>retrieval, certificate verification, or constraint processing."
>
>I'm perfectly happy with that interpretation, although I'd prefer to =
extend
>"They may be used by end-systems for display to the user in
>security-related contexts" to something like "They may be used by
>end-systems for display to the user in security-related contexts, but =
that
>such display should be accompanied by a disclaimer that the authenticity =
of
>such names may not have been verified by the CA, and that the CA's CPS
>should be consulted before placing the same level of trust in an altName =
as
>in a DN".  This interpretation would be a change from the behavior
>specified in the current draft of PKIX-1, which uses altName fields for
>chain-building.
>
>John
>
I'd be comfortable with that interpretation, although I would prefer to
see a Nonverified Subscriber Information flag be made explicit. Having to
read a very lengthy CPS is bad enough, but having to read various
amendments and keep up with them because the CA says that they
are binding is much, much worse.

Bob

Date: Tue, 12 May 1998 11:29:08 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: [email-masked]
CC: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Hi Denis,
    I thought the KeyIdentifier WAS the hash of the public key. On
re-reading Part 1, I see that it is the hash of the public key if
one is not present in the issuer's certificate. If it is present,
it could be the integer 1 for all anyone knows.

So you are right - this spec needs to spell out exactly what is in
that field:

The hash shall be calculated over the value (excluding tag and length)
of the BIT STRING subjectPublicKey in the issuer's certificate.

Would that work?

Regards,
Ambarish

Denis Pinkas wrote:
> 
> Ambarish,
> 
> I see two problems with your proposal.
> 
> > Hi All,
> >     Given the amount of debate on this topic, I am proposing the
> > following structure to identify a certificate in OCSP:
> >
> > CertID ::= SEQUENCE {
> >    issuerNameAndKey     IssuerNameAndKey,
> >    serialNumber         CertificateSerialNumber }
> >
> > IssuerNameAndKey ::= SEQUENCE {
> >    issuer                       Name,
> >    issuerAltName        [0]     EXPLICIT IssuerAltName OPTIONAL,
> >    keyIdentifier                KeyIdentifier }
> 
> This is a structure that is different from the "option 3". Why ?
> 
> The proposed structure would be roughly equivalent if the KeyIdentifier
> were a hash of the public key of the CA. Since a keyIdentifier is only a
> bit string, it will NOT prevent collisions.
> 
> Why don't you take the "option 3 " ?
> 
> Denis
> 
> > Will this address everyone's concerns?
> > If you want to just use the Issuer's key as the method of figuring
> > out the issuer, you can do that. If you want to use the Name and/or
> > the AltName, that will also work.
> >
> > Comments?
> >
> > Ambarish
> >
> > --
> > 
-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Tue, 12 May 1998 18:53:36 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Ambarish Malpani <[email-masked]>
CC: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Ambarish,

I see two problems with your proposal.

> Hi All,
>     Given the amount of debate on this topic, I am proposing the
> following structure to identify a certificate in OCSP:
> 
> CertID ::= SEQUENCE {
>    issuerNameAndKey     IssuerNameAndKey,
>    serialNumber         CertificateSerialNumber }
> 
> IssuerNameAndKey ::= SEQUENCE {
>    issuer                       Name,
>    issuerAltName        [0]     EXPLICIT IssuerAltName OPTIONAL,
>    keyIdentifier                KeyIdentifier }

This is a structure that is different from the "option 3". Why ?

The proposed structure would be roughly equivalent if the KeyIdentifier
were a hash of the public key of the CA. Since a keyIdentifier is only a
bit string, it will NOT prevent collisions.

Why don't you take the "option 3 " ?

Denis

> Will this address everyone's concerns?
> If you want to just use the Issuer's key as the method of figuring
> out the issuer, you can do that. If you want to use the Name and/or
> the AltName, that will also work.
> 
> Comments?
> 
> Ambarish
> 
> --
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                              (650) 849-9880
> ValiCert, Inc.                                  [email-masked]
> 3160 W. Bayshore Road                         http://www.valicert.com
> Palo Alto, CA 94303

-- 
      Denis Pinkas     Bull S.A.          mailto:[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

From: [email-masked]
To: "Bob Jueneman" <[email-masked]>
cc: [email-masked]
Date: Tue, 12 May 1998 12:01:27 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Bob Jueneman <[email-masked]> writes:

>Peter said that one of the primary uses of alternate names
>was to accommodate those name forms that can't be a DN,
>e.g., almost everything useful.  I have to strongly disagree with
>that notion, which I thought we had overthrown back in the
>PEM days.
>
>To the best of my knowledge, the ITU does not act as any kind of
>a schema registration "authority" for X.500 or anything else.
>Nor, even less, do they act as a name registration authority for
>names that are defined within any particular schema.
>
>So although it might be too strong to say that such a view
>is ludicrous, I firmly believe that it would be wrong.
>
>I may be somewhat notorious for my "MPEG of my cat" view
>of what a DN can contain, but to the best of my knowledge,
>anyone who wanted to create an OID and a syntax description
>for such an attribute would be PURRFECTLY within their rights
>to include it within their certificate DN. So there is absolutely
>no reason at all why an RFC822 name, DNS name, or anything else
>that is at all reasonable could not be contained in a DN.  In
>particular, neither PKIX, nor X.500, in fact, has to be constrained
>by the oxymoronic "useful attributes" defined in X.520.

I agree, and in particular it's wrong to claim that an RFC 2247 name is
somehow less "real" or more of a hack than an X.521 OrganizationalPerson
name.

>And to respond to John's comment, PKIX could in fact totally
>ignore issues of what kinds of attributes are allowed for a DN
>in a certificate, and PKIX would still work. Chains could be searched,
>name constraints applied (assuming the basic comparison syntax is
>supplied), etc.
>
>The only thing that won't work is _interoperability_, especially with
>various kinds of directories.  Directories, especially most X.500
>directories, are NOT general purpose relational search engines.

My position is that a relying party shouldn't itself impose schema
constraints on the names that it is willing to accept.  If it is using a
directory to retrieve certificates, then that directory may well impose
restrictions of its own, and that is a good reason for CAs to be careful
about the sorts of names they issue certificates for, but, assuming that an
end-system can obtain a certificate, it shouldn't refuse to use that
certificate in a chain simply because the name contains an attribute that
the end-system doesn't recognize.

>Most X.500 and similar directories I know of can find almost
>anything very quickly, but ONLY if the search arguments have
>been predefined as some kind of a filter. So given a name, you
>can look up anything that is filed under that name, including say
>street address, telephone number, e-mail address, certificates, and
>the obligatory cat picture.
>
>Likewise, if you PREDEFINE the appropriate filters, you can look up
>what is effectively an alias that doesn't have to be created specifically,
of
>say my telephone number, and get back a pointer to my name and all
>the rest.
>
>But unless you have predefined it, you cannot enter a picture of my cat,
>or even my e-mail address, and find anything else, unless you are
>prepared to search the ENTIRE database for a match.
>
>Therefore, the CAs and the director service providers are going to
>HAVE to play a strong role in defining what kind of names (schemas)
>are acceptable if we want directories to work at all. Since PKIX is active
>in this field, I would hope they would take the initiative, otherwise, I
would
>expect that the CAs would get together and decide for themselves --
>after all, they have to sign the certificate containing the DN, and
>presumably they take some degree of responsibility for the contents.

I think this is an important thing to do, however, I don't think we need to
hold up PKIX-1 for it.  PKIX-1 should explicitly allow names constructed
using arbitrary attribute types.

>So my view is that the DN should contain names that are agreed within
>the community to fall within an acceptable schema, AND ARE
>SEARCHABLE WITHIN  A DIRECTORY. Otherwise, I would argue,
>there is no reason to have a DN at all.

Not all certificates necessarily need to be obtained from a directory,
though.  An application protocol is entitled to provide some portion of the
certificate chain needed to establish trust in the final key, so if a
certificate is always used in the context of such a protocol, the fact that
it might contain names using unusual schema ought not to matter, provided
that the relying party can correctly verify that the subject of one cert
"matches" the issuer of the next. Of course, with an unknown attribute,
matching is a little tricky, but there is text pending for inclusion in
PKIX-1 that specifies binary matching for all string syntaxes other than
printableString, and while I'm not sure of the wisdom of doing this when an
end-system knows how to apply X.520 matching rules, I think it's a
perfectly acceptable fallback position for a relying party to take for
attributes it doesn't recognise.

>So what purpose is or should be served by alternate names?
>
>Well, in my view, at least, they are representations made by the
subscriber
>to the CA, and hence to relying parties, and as such may have certain
legal
>consequences. So even if the CA does not have the resources to do a full
>due diligence investigation of their veracity, that doesn't mean that a
>subscriber is entitled to make any representations he wishes in this
regard.
>
>Ideally, anything contained in an alternate name should carry an explicit
>Nonverified Subscriber Information flag, in order to make this much
clearer.
>But failing that, the CA at least ought to spell out in their CPS whether
or
>not they independently verify the subscriber's right-to-use and perhaps
global
>unambiguity of those attributes.
>
>In answer to John's last point, I agree that it would be possible
>and under some circumstances desirable, to provide those alternative,
>not rigidly bound names or other attributes by means of a directory.
>But although I very much WANT to be able to look up certificates, CRLs,
>etc. in a directory, I don't think that users should be COMPELLED
>to.
>
>If this gets to be too much of an impasse, we could always define the
>syntax for an alternate subject (or issuer) name to be a compound
attribute,
>and define on a per attribute or even per name basis a Nonverified
>Subscriber Information bit.
>
>So I would modify David's taxonomy to include a fourth option, which
>would be my preference:
>
>" iv) They are alternative names which are a representation
>made by the subscriber to the CA and/or any relying party
>which may have legal consequences, but which may or
>may not have been independently verified by the CA. They
>may be used by end-systems for display to the user in
>security-related contexts, and may also be used for such
>secondary purposes as automatic e-mail or http address
>confirmation. They are not used in chain-building, certificate
>retrieval, certificate verification, or constraint processing."

I'm perfectly happy with that interpretation, although I'd prefer to extend
"They may be used by end-systems for display to the user in
security-related contexts" to something like "They may be used by
end-systems for display to the user in security-related contexts, but that
such display should be accompanied by a disclaimer that the authenticity of
such names may not have been verified by the CA, and that the CA's CPS
should be consulted before placing the same level of trust in an altName as
in a DN".  This interpretation would be a change from the behavior
specified in the current draft of PKIX-1, which uses altName fields for
chain-building.

John

Date: Tue, 12 May 1998 09:45:05 +0200
To: [email-masked]
From: [email-masked] (Olivier Onimus)
Subject: Re: Alternate name semantics and usage (again!)
Sender: [email-masked]

Hi,

I may have missed something basic in the (very long) discussion
you are follwing since several days, but IMO, the "semantics" of
Alternate name in comparison with "Name" (e.g. for subject)=20
is already (well) defined in X.509:

"subject" and "Issuer" in Certificat are of type "Name". Name is defined in
X.501 as =84SEQUENCE OF RelativeDistinguishedName".  This means that only=
 RDNs
(of a real or a virtual existing DIT) should be present at this level.

In X.509, Chapter. 12.3.1 about the Extensions, it is said:

    The following requirements relate to certificate subject and=20
    certificate issuer attributes:
	a) Certificates need to be usable by applications=20
           that employ a variety of name forms, including=20
           Internet electronic mail names, Internet domain names,=20
           X.400 originator/recipient addresses, and EDI party names.
           It is therefore necessary to be able to securely associate
           multiple names of a variety of name forms with a certificate
           subject or a certificate or CRL issuer.
	b) A certificate user may need to securely know certain
           identifying information about a subject in order to have
           confidence that the subject is indeed the person or thing
           intended. For example, information such as postal address,
           position in a corporation, or a picture image may be required.
           Such information may be conveniently represented as directory
attributes,
           but these attributes are not necessarily part of the
distinguished name.
           A certificate field is therefore needed for conveying additional
           directory attributes beyond those in the distinguished name.

What I do understand is, that the attributes of the =84Issuer" or =84Subject=
",
which can not be coded in the fields =84issuer" or =84subject", because they=
 are
not part of a RDN, can be coded as certificate-extension. That's all.

With the informations contained in "Issuer", I can identify (as software) a
tree (DIT)
in which I can identify in a UNIQUE way (as software) an entry using the
information contained in "Subject". The extra information contained in the
extension "AltName" may=20
be used for me (as user) to identify the subject or the issuer of the
certificate in another way. The informations are (as David P. Kemp said)
"only extra identification information".

Another remark before I finish: I don't want to defend here the x.509-world.=
=20
I know, PKIX will profile the X.509 world in such a way the whole stuff=
 works
and the designers and the implementors can easily understand what is meant.=
 I
just thought that this discussion about "Alternate name semantics and usage"
could take something from what is specified in X.509.....

Olivier

Date: Mon, 11 May 1998 16:58:20 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Hi All,
    Given the amount of debate on this topic, I am proposing the
following structure to identify a certificate in OCSP:

CertID ::= SEQUENCE {
   issuerNameAndKey     IssuerNameAndKey,
   serialNumber         CertificateSerialNumber }

IssuerNameAndKey ::= SEQUENCE {
   issuer			Name,
   issuerAltName	[0]	EXPLICIT IssuerAltName OPTIONAL,
   keyIdentifier		KeyIdentifier }

Will this address everyone's concerns?
If you want to just use the Issuer's key as the method of figuring
out the issuer, you can do that. If you want to use the Name and/or
the AltName, that will also work.

Comments?

Ambarish

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Mon, 11 May 1998 16:15:00 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

>Apologies if I'm asking something that should be obvious from reading
>the specs, but this long discussion makes me wonder.

No apologies are necessary.  The questions you are asking are in fact
recorded very precisely in the original X.DOT specifications. Unfortunately=
=20
the specs are copyrighted and can only be referenced by visting the =
archives=20
on the planet Vogon in person, after payment of 1000 International =
Standard=20
Units of platinum, ISO 4217 alpha currency code XPT, numeric=20
funds code 962. Unfortunately ISO 4217 does not specify what the=20
standard units ARE, but only their names, so it might be grams, troy=20
ounces, or mean solar mass equivalent.  Probably it is the latter,=20
so bring your American Express card.
>
>In much of the world we live in, it's well understood how to get
>(a) an IP address, (b) a DNS name.

Actually, in MOST of the world we live in, it is far from obvious how one
goes about getting an IP address, or even an DNS name.  Take a poll
of 1000 AOL newbies, and ask them whether they fully understand the=20
intricacies of DHCP, for example. I certainly don't pretend to.  =
Likewise=20
a DNS name, if I'm behind a firewall on a corporate network.
>
>On the other hand, X.500 style names (i.e., strings of the form =
"C=3DUS,=20
>ORG=3Dbar, FOO=3Dxxx...") are, most of the time, going to be received =
with=20
>"what the heck is *that*?".  That's not a problem if we can simply
>write some documentation to make it clear.

On the other hand, I would suggest that most people _would_ understand=20
a question such as "what country do you live in, i.e., what is your =
primary=20
residence?" (We won't get into residence vs. domiciles).

And most people would be able to answer the question, "What is the=20
name of the organization you work for or are associated with?"

Depending on the frequency of organization updates, answering a question
about organizational units might be a bit more difficult, I suppose.

Now the trickiest of all might be "What is your name?"  But that is
because standards organizations, unfortunately including PKIX , worry=20
excessively about the obscure minutia, and never get around to specifying
whether the form is last name first, first name last, or what a surname =
is.
I suppose it is due to early toilet training, or something -- anal =
retentive,
I think it's called.

Hopefully, the public CAs will enforce some discipline on this process,=20
and if they don't, some very small number of dominant vendors will=20
do so (unless the Justice Department gets into the act). At least I hope =
so.

Notice that nowhere in this process did I ever use such X.400 business=20
card jargon as c=3DUS,O=3Dfoo, cn=3DBar.  And anyone's GUI that does=20
use such junk ought to be banned, at least if it is intended for the =
casual user.

(If, however, it is the network administrator, or the directory administrat=
or,
or other reasonably skilled person who is filling out these screens, then
a certain latitude can perhaps be tolerated.  Just like doctors and =
lawyers,
system administrators have to use a specialized language to communicate
with their brethren, or anybody might be able to do this stuff! :-)
>
>However, what *is* critical is that there has to be a well defined,
>easily executed, and effective way for people to obtain the names they=20
>need.  It isn't clear to me yet from the discussion whether this is
>the case, or if so, what the process is.

People don't OBTAIN names, they HAVE names, or they are given them,
typically by their parents. People who work for organizations and =
choose=20
(or are told) to use that organizational person class (excuse the =
jargon)=20
inherit those names. People who chose to be identified by their residential=
=20
addresses look on their mailbox. People who only want to be identified by
obscure 8 character e-mail names have to ask their system administrator=20
what they should use, to make sure it doesn't give away corporate secrets.
>
>Does it amount to re-encoding the DNS name into a different syntax?
>That works (except for the pain of explaining why a different syntax
>that doesn' have any different semantics is useful).  Or does it
>requiring going to a different authority and getting an additional
>name in a different naming hierarchy?  If so, which authority?

Note that the ordinary DNS name hardly has any syntax specified=20
at all, except that the various names are separated by periods.

Syntactically, com.novell.www would be a perfectly legitimate=20
DNS name.  It isn't a legal name SEMANTICALLY, because the DNS
name registration folks won't honor www as a suffix.  Aside from that=20
point, almost anything goes -- .foo.bar.www.novell.com would be fine.

So if you wanted to code up such a name in X.500 style, what you
SHOULD do is create an attribute, say

dnsName ::=3D DnsName IDENTIFIED BY (<attribute OID>)
DnsName ::=3D DIRECTORY STRING

If you were so inclined, you might say something about the included=20
periods, say in the comments field, but you don't really have to.=20
And you certainly don't have to break up the name
into various arbitrary labeled components -- syntactic chaff.

Unfortunately, people were either too ignorant, too lazy, in a big =
hurry,=20
or thought that God and/or the ITU had already invented all of=20
legal X.500 names, and so they perverted the already obscure=20
semantic definition of commonName by using it for DNS names,
RFC822 names, yada, yada, yada. And all of the lessons people
learned about the virtues of strong typing in Computer Science 101
went right out the window.

Naughty, naughty, naughty!

Bob

Date: Mon, 11 May 1998 16:49:56 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

> From: Paul Koning <[email-masked]>
> 
> Apologies if I'm asking something that should be obvious from reading
> the specs, but this long discussion makes me wonder.
> 
> In much of the world we live in, it's well understood how to get
> (a) an IP address, (b) a DNS name.
> 
> On the other hand, X.500 style names (i.e., strings of the form "C=US, 
> ORG=bar, FOO=xxx...") are, most of the time, going to be received with 
> "what the heck is *that*?".  That's not a problem if we can simply
> write some documentation to make it clear.

Is it clear that an X.500 style name of the form "E=[email-masked]"
means what one would expect it to mean?  The emailAddress DN attribute
(1.2.840.113549.1.9.1, commonly abbreviated as "E") is already used
in many certs.  Unfortunately, many CAs generally include it in
a meaningless mishmash of a DN
("C=US, ORG=Bar, CN=Fred Jones, E=[email-masked]") in which the fourth RDN
has no subordinate relationship to the third; this misuse is what
prompted the ITU to define GeneralName in the first place.
But IMHO the proper response to DN abuse is not to create a whole new
syntax, but to define a schema which would demonstrate the proper use
of the existing DN syntax.

> Does it amount to re-encoding the DNS name into a different syntax?

Yes.

> That works (except for the pain of explaining why a different syntax
> that doesn' have any different semantics is useful).

If one is prepared to require that all certs with DNS subjects are
End Entity certs, then there is no difference in semantics and no reason
to have a multi-RDN syntax for DNS names.

However, DNS doesn't work that way.  It's a heirarchy, with registration
delegated to administrators at lower levels.  If you want the CA topology
to mirror the DNS administrative topology, then you want the CA for
"DC=net, DC=vaultline" to be able to issue a CA cert for
"DC=net, DC=vaultline, DC=santaclara" and have the normal name
constraint process work as expected.  The ITU has not defined any
processing rules to go along with GeneralName, so the semantics of the
multi-RDN form *is* different than the undefined semantics of a single
subjectAltName string of "dNSName=santaclara.vaultline.net".

> Or does it
> requiring going to a different authority and getting an additional
> name in a different naming hierarchy?

No!

Date: Mon, 11 May 1998 14:53:43 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Apologies if I'm asking something that should be obvious from reading
the specs, but this long discussion makes me wonder.

In much of the world we live in, it's well understood how to get
(a) an IP address, (b) a DNS name.

On the other hand, X.500 style names (i.e., strings of the form "C=US, 
ORG=bar, FOO=xxx...") are, most of the time, going to be received with 
"what the heck is *that*?".  That's not a problem if we can simply
write some documentation to make it clear.

However, what *is* critical is that there has to be a well defined,
easily executed, and effective way for people to obtain the names they 
need.  It isn't clear to me yet from the discussion whether this is
the case, or if so, what the process is.

Does it amount to re-encoding the DNS name into a different syntax?
That works (except for the pain of explaining why a different syntax
that doesn' have any different semantics is useful).  Or does it
requiring going to a different authority and getting an additional
name in a different naming hierarchy?  If so, which authority?

	paul

Date: Mon, 11 May 1998 12:57:32 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

John, Peter, and David,

This has been a very illuminating discussion.

First off, I suppose I should apologize for using the term "ludicrous."
I did not mean to deprecate anyone's opinion that differed from=20
mine. But there are apparently some rather divergent views.

Peter said that one of the primary uses of alternate names
was to accommodate those name forms that can't be a DN,
e.g., almost everything useful.  I have to strongly disagree with
that notion, which I thought we had overthrown back in the=20
PEM days.

To the best of my knowledge, the ITU does not act as any kind of=20
a schema registration "authority" for X.500 or anything else.=20
Nor, even less, do they act as a name registration authority for
names that are defined within any particular schema.

So although it might be too strong to say that such a view=20
is ludicrous, I firmly believe that it would be wrong.

I may be somewhat notorious for my "MPEG of my cat" view
of what a DN can contain, but to the best of my knowledge,
anyone who wanted to create an OID and a syntax description
for such an attribute would be PURRFECTLY within their rights
to include it within their certificate DN. So there is absolutely=20
no reason at all why an RFC822 name, DNS name, or anything else
that is at all reasonable could not be contained in a DN.  In=20
particular, neither PKIX, nor X.500, in fact, has to be constrained
by the oxymoronic "useful attributes" defined in X.520.

And to respond to John's comment, PKIX could in fact totally=20
ignore issues of what kinds of attributes are allowed for a DN
in a certificate, and PKIX would still work. Chains could be searched,
name constraints applied (assuming the basic comparison syntax is
supplied), etc.

The only thing that won't work is _interoperability_, especially with
various kinds of directories.  Directories, especially most X.500
directories, are NOT general purpose relational search engines.

Most X.500 and similar directories I know of can find almost=20
anything very quickly, but ONLY if the search arguments have=20
been predefined as some kind of a filter. So given a name, you=20
can look up anything that is filed under that name, including say=20
street address, telephone number, e-mail address, certificates, and=20
the obligatory cat picture.

Likewise, if you PREDEFINE the appropriate filters, you can look up
what is effectively an alias that doesn't have to be created specifically, =
of
say my telephone number, and get back a pointer to my name and all=20
the rest.

But unless you have predefined it, you cannot enter a picture of my cat,
or even my e-mail address, and find anything else, unless you are=20
prepared to search the ENTIRE database for a match.=20

Therefore, the CAs and the director service providers are going to=20
HAVE to play a strong role in defining what kind of names (schemas)
are acceptable if we want directories to work at all. Since PKIX is active
in this field, I would hope they would take the initiative, otherwise, I =
would=20
expect that the CAs would get together and decide for themselves --=20
after all, they have to sign the certificate containing the DN, and=20
presumably they take some degree of responsibility for the contents.

So my view is that the DN should contain names that are agreed within=20
the community to fall within an acceptable schema, AND ARE=20
SEARCHABLE WITHIN  A DIRECTORY. Otherwise, I would argue,=20
there is no reason to have a DN at all.

At the admitted risk of overloading the semantic content of the=20
DN, I would also propose that the DN comport more or less well with
the more or less "official" name of the subject, i.e., the name that is =
legally=20
recognized as being associated with that entity.  That doesn't necessarily
rule out the use of an e-mail address in the appropriate contexts, but it
probably does rule out my cat.  (We sometimes have a disagreement on
this issue, but I claim that I own the cat, not vice versa. Not to get =
into
SPKI semantics, but my name is a legitimate qualifier for the cat, not=20
the other way around, at least until he can open his own cans of cat =
food.)

So what purpose is or should be served by alternate names?

Well, in my view, at least, they are representations made by the subscriber=
=20
to the CA, and hence to relying parties, and as such may have certain =
legal
consequences. So even if the CA does not have the resources to do a =
full=20
due diligence investigation of their veracity, that doesn't mean that a=20
subscriber is entitled to make any representations he wishes in this =
regard.

Ideally, anything contained in an alternate name should carry an explicit
Nonverified Subscriber Information flag, in order to make this much =
clearer.
But failing that, the CA at least ought to spell out in their CPS whether =
or=20
not they independently verify the subscriber's right-to-use and perhaps =
global
unambiguity of those attributes. =20

As I said in response to a private question regarding alternate language
names:

My position would be that even if an attribute were flagged with a=20
Nonverified Subscriber Information flag, it is still a representation=20
that is made by the CA, and hence to relying parties. The only
issue is whether the CA is capable of performing some additional=20
due diligence investigation at the time of issuance.

I don't want to necessarily force the CA to become a linguistics
expert in every possible language I might like to include in my
certificate, in order to have it be readable by my customers or=20
relying parties.

However, I do believe that if someone notices that the DN says
"Itty Bitty Movers" and the translation into Aramaic, Urdu, etc., says
International Business Machines Corp., SOMEBODY will be competent
in both languages, and will blow the whistle. Then either the CA will
revoke the certificate, or people will stop relying on that CA.

Reputation capital punishment in either case.

In answer to John's last point, I agree that it would be possible
and under some circumstances desirable, to provide those alternative,
not rigidly bound names or other attributes by means of a directory.
But although I very much WANT to be able to look up certificates, CRLs,
etc. in a directory, I don't think that users should be COMPELLED
to. =20

If this gets to be too much of an impasse, we could always define the=20
syntax for an alternate subject (or issuer) name to be a compound =
attribute,
and define on a per attribute or even per name basis a Nonverified
Subscriber Information bit.

So I would modify David's taxonomy to include a fourth option, which
would be my preference:

" iv) They are alternative names which are a representation
made by the subscriber to the CA and/or any relying party
which may have legal consequences, but which may or=20
may not have been independently verified by the CA. They=20
may be used by end-systems for display to the user in=20
security-related contexts, and may also be used for such=20
secondary purposes as automatic e-mail or http address=20
confirmation. They are not used in chain-building, certificate=20
retrieval, certificate verification, or constraint processing."

Bob

From: Ellen_McDermott/CAM/[email-masked]
To: [email-masked]
cc: Ellen_McDermott/CAM/[email-masked]
Date: Mon, 11 May 1998 13:55:32 -0400
Subject: -request to subscribe
Sender: [email-masked]

Date: Mon, 11 May 1998 12:28:02 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

> From: [email-masked] (Peter Gutmann)
>  
> Alternative Names
>  
> The subject and issuer alternative names are used to specify all the things
> which can't be given in a DN, which for most purposes means practically
> everything of any use on the Internet.

Can't is such a strong word.  "Sometimes aren't given in a DN" is more
accurate, since rfc822 names are often (incorrectly) included in
mixed-namespace DNs.  In your experience, what percentage of the certs
which contain rfc822 names encode them in an AltName extension?

  [snip - excellent discussion of the ambiguities created by
          the AltName extension]

> The solution to this problem would be to split the altName into two new 
> extensions, a true _alt__Name_ which provides a single _alternative_ to the 
> subject_Name_ (for example a single dNSName or rfc822Name) and which is used 
> only when the subject DN is empty, and a collection of other information 
> about the subject which follows the current altName syntax but which is used 
> strictly for informational purposes.  The true altName provides a single 
> alternative for the subjectName, and the informational altName provides any 
> extra identification information which the subject may want to include with 
> their certificate.
>  
> -- Snip --
>  
> This would require an amendment to X.509v3 though, I'm not sure how likely 
> that is to happen.  As it currently stands, the altName semantics are too 
> ambiguous to make it possible to rely on altNames for much.

A different solution which does not require an amendment to X.509:

 * AltName extensions are never used in path development, only the
   subject and issuer fields are used.  The AltName extensions are
   used only for extra identification information, verified or not
   as described in the CA's CPS.

 * subjects which have one true, certified name would have that name
   encoded as a DN.  RDN attributes already exist for emailAddress and
   DNS name component.  Additional attributes could be defined to hold
   the string form of a full DNS name, URI, EDIPartyName, etc.
   (An alternative, which I don't like but which should be mentioned
   anyway for completeness, is to define a single attribute with syntax
   GeneralName which could hold any nameform.)

 * subjects which have more than one certified subject name should have
   more than one certificate.  (I'd argue that those certs should have
   different public keys, but that's a different thread :-).

Date: Mon, 11 May 1998 18:21:26 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: [email-masked]
CC: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

John Wray wrote:

(text deleted)

> >                                  If we can solve the case of name
> >constraints with DNs, I see no reason why we could not solve it for
> >rfc822 and dNSName. This would at least allow an issuer name to be
> >either a DN or an rfc822 or a dNSName.
> 
> "Either" is the key qualifier.  Today, the PKIX-1 spec allows a certificate
> to carry an Issuer name and a number of IssuerAltNames, and this is the
> source of many of the problems I referred to in my earlier post.  If we
> were to constrain PKIX CAs to identify themselves in certificates using
> only a single name (i.e. either a DN which would go in the issuer field of
> certificates they cut, or a single rfc822 or dNSName which would be placed
> in the IssuerAltName extension of their certificates), that would go a long
> way towards simplifying the problem. 

This is exactly the case I would like to be supported.

>  Subtree constraints are already
> defined for both of these AltName types.

Would you point out to the text you refer ?
 
> The issue still remains of what do constraints mean in a certificate chain
> that crosses over between name-spaces. 

This is much more complex and I wonder if we can find an easy solution
for this. I would be satisfied if we could, at this time, address only
the case with a uniform naming.

> Suppose I have a certificate chain
> that starts in the DN namespace, and in which subtree constraints are
> applied by some early certificate.  Can a later CA-certificate (with an
> issuer DN permitted by the subtree constraints) contain a subject field
> expressed using the dNSName syntax?  How about if the DN-namespace
> constraints permit the use of names below the /DC=xxx root that matches the
> first domain component in the dNSName of the certificate in question?  This
> problem is one argument for preferring the use of RFC2247-format DNs names
> over dNSNames when trying to put a DNS name into a certificate.

I wonder if this is so easy since in one case you have a sequence of
"DC" versus a structure that contains no "DC=" at all. :-)

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[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: Mon, 11 May 1998 11:36:54 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

> From: [email-masked]
> 
> I agree that things are very much simpler if we can
> prescribe the use of DNs in all certificates, and I'd
> be quite happy with that restriction.  However, I don't
> see why PKIX needs to say anything about schema.  PKIX
> systems ought to be able to handle any X.500 name,
> regardless of whether that name follows an X.520/X.521
> schema, or whether it uses some private schema.

John,
  I agree almost completely.  The exception: PKIX should say something
about schema: it may reasonably define mandatory and optional schema to
promote interoperablity.  But PKIX and X.509 should not prohibit the
use of other (private or agreed-to-elsewhere) schema.

Bob says:

>    The question of who "owns" or registers name in the DN space is not
>    only ludicrous, but moot.  CAs are going to define them, and
>    directory service providers are going to decide whether or not that
>    schema is acceptable for their directory, and everything else will
>    spill on the floor.

The question isn't ludicrous, but "own" may have been a poor choice
of words.  Is there any question that Naming Authorities (such as
the IETF) exist, and that rfc822 names and DNS names are assigned
in accordance with a reasonably well defined registration procedure?

The question of ownership only came up as a result of the assertion
that the ITU owns the DN structure and that names registered by
non-ITU NAs such as the IETF could/should not appear in a DN.  I
wouldn't call this assertion "ludicrous", but I do disagree with it.

Schemas will be defined by PKIX and privately, and as you say, CAs,
application developers, and directory providers will decide which schemas
to support.  Schemas for representing rfc822 and DNS names as RDN
attributes should live or die based on their utility, not be automatically
rejected because "the ITU owns the DN space" and defines an AltName
extension to hold those other names.

> So, we have at least three different possible sets of
> semantics for the AltName fields:
> 
> i)  They are "official" names, and should be used to
> link certificates together in chain-building (perhaps
> only if there aren't DNs in ther certificates).  The
> current PKIX-1 draft is consistent with this
> interpretation, but doesn't define how the linkage is
> to be performed.
> 
> ii) They are nicknames, chosen by the end-system and
> unverified by the CA.  They are therefore not to be
> believed by end systems, and should not be displayed
> to the user in any security-related context.  They are
> not used in chain-building.
> 
> iii) They are approved alternative names, verified by
> the CA, and may be used by end-systems for display to
> the user in security-related contexts.  They are not
> used in chain-building.
> 
> We need to decide what these names mean, and what an
> end-system is required/permitted to do with them
> before we can include them in the PKIX profile.

My vote is for ii) or iii): AltName extensions are prohibited in chain
building.  Verifying (and the strength of verification) is a matter to
be described in the CPS.  Displaying is a UI issue - don't go there.

From: Sharon Boeyen <[email-masked]>
To: [email-masked], "'Scott, Greg'" <[email-masked]>
Subject: RE: Question re ipki2opp-07
Date: Mon, 11 May 1998 09:11:03 -0400
Sender: [email-masked]

Scott, I don't recall seeing a reply to this, but I've been away and am a
bit behind with email, so in case no one has responded yet:

The difference between the filtering ability in the two sections is that in
6.2.1 filtering is only permitted on the objectClass attribute and only the
"presence" test is supported. In 7.2.1 the enhanced filtering functionality
is that filtering can be done on any attribute and all LDAPv2 match types
can be tested, not just the presence test. Hope this helps.

Sharon

> ----------
> From: 	Scott, Greg[SMTP:[email-masked]]
> Sent: 	May 5, 1998 9:53 AM
> To: 	[email-masked]
> Subject: 	Question re ipki2opp-07
> 
>    This is probably painfully obvious to most, but I'm just asking to be 
>    sure.
>    
>    In section 6.2.1 the filter is defined as:
>    
>            Filter ::=
>              CHOICE {
>                      present       [7] AttributeType, -- "objectclass"
> only
>                     }
>    
>    In 7.2.1 the text states that an element added to this service is:
>    
>      "- Enhanced filter capability"
>    
>    but there is no ASN.1 code redefining Filter.  
>    
>    Does this mean that the full range of filter conditions defined in RFC 
>    1777 section 4.3 is now available?
>    
>    Thanks,
>    
>    Greg
>    
>    PS. Spelling and grammar nits:
>       
>        Section 6.2.2, I believe that "The application/relying party may 
>        ..." should read "The application/replying party may ..."
>        
>        Section 7, "To search ,using ..." should read "To search, using
> ..."
> 

From: [email-masked]
To: "Bob Jueneman" <[email-masked]>
cc: [email-masked]
Date: Mon, 11 May 1998 08:37:46 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Bob Jueneman <[email-masked]> writes:

>My very strong preference is to mandate the use of
>DNs in certificates, both for end-entities and especially
>for CAs.  And the schema for these DNs ought to be drawn
>from a rather limited set of the allegedly "useful
>attributes" defined in X.520, unless or until PKIX
>gets around (after five years and counting) to
>defining an acceptable schema.

I agree that things are very much simpler if we can
prescribe the use of DNs in all certificates, and I'd
be quite happy with that restriction.  However, I don't
see why PKIX needs to say anything about schema.  PKIX
systems ought to be able to handle any X.500 name,
regardless of whether that name follows an X.520/X.521
schema, or whether it uses some private schema.  While
individual CAs might well impose schema constraints
on the names they will issue certificates for, we
shouldn't build such restrictions into the PKIX specs,
as our ideas of what are appropriate constraints are
likely to change over time.  End systems in particular
ought to be able to do chain verification on certificates
regardless of the schema followed by the DNs in those
certificates.

>I believe that it is reasonable to require the CA do
>perform its due diligence on the DN, maybe even vouching
>for the organization's right to use.  However, I very
>much doubt that most CAs would step up to a due
>diligence verification of  all of the possible
>alternative spellings and translations. Nor should
>they have to, especially if such constructs are
>presented as alternate names.

If the CA hasn't verified a name, and isn't asserting
anything about its validity, what business does it
have signing it?  If an end-system has a need for
alternative "nicknames", then it should use a
directory service to publish those names, not try
to piggy-back them on the certificate infrastructure.

>So my bottom line is that the alternate names should
>be primarily intended for use as a human-readable
>confirmation of the subscriber's identity, but not
>necessarily for use as a means of searching for that name.

That's a very diffeent use from what the previous para
described.  This sounds like the CA's signature acts as
a stamp of approval on the AltNames - the CA asserts
that they are valid aliases for the subject DN, and as a
result of this CA approval, an end-system would feel
justified in using one of these AltNames in user display,
for example.

So, we have at least three different possible sets of
semantics for the AltName fields:

i)  They are "official" names, and should be used to
link certificates together in chain-building (perhaps
only if there aren't DNs in ther certificates).  The
current PKIX-1 draft is consistent with this
interpretation, but doesn't define how the linkage is
to be performed.

ii) They are nicknames, chosen by the end-system and
unverified by the CA.  They are therefore not to be
believed by end systems, and should not be displayed
to the user in any security-related context.  They are
not used in chain-building.

iii) They are approved alternative names, verified by
the CA, and may be used by end-systems for display to
the user in security-related contexts.  They are not
used in chain-building.

We need to decide what these names mean, and what an
end-system is required/permitted to do with them
before we can include them in the PKIX profile.

John

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Reply-To: [email-masked]
Date: Sat, 9 May 1998 09:11:51 (NZST)
Sender: [email-masked]

>My point was that in my view, at least, the primary purpose for alternate
>subject anmes (and even alternate issuer names) was to convey additional
>optional information to the relying party.
>
>If we start using them to convey all sorts of mandatory contraints, impose a
>requirement to be able to search for them in a directory, etc.,  then I think
>we have started down a different kind of semantics entirely.
 
I cover this problem in a not-yet-released version of the X.509 style guide, 
here's the section on altNames:
 
-- Snip --
 
Alternative Names
 
The subject and issuer alternative names are used to specify all the things
which can't be given in a DN, which for most purposes means practically
everything of any use on the Internet.  This includes email addresses, URL's
for web pages, server addresses, and other odds and ends like X.400 and EDI
addresses.  There's also a facility to include your postal address, physical
address, phone, fax and pager numbers, and of course the essential MPEG of your
cat.  
 
The alternative names can be used for certificate identification in place of
the DN's, however the exact usage is somewhat unclear.  In particular if an
altName is used for certificate chaining purposes, there's a roughly 50/50
split of opinion as to whether all the items in the altName must match or any
one of the items must match.  For example if an altName contains three URL's in
the issuer and one in the client (which matches one of the issuer URL's), noone
really knows whether this counts as a valid altName match or not.  Eventually
someone will make a decision one way or the other, probably the S/MIME
standards group who are rather reliant on altNames for some things.  Until this
is sorted out, it's not a good idea to rely on altNames for chaining.
 
This confusion is caused by the fact that an altName is serving two 
conflicting purposes.  The first of these is to provide extra information on 
the certificate owner which can't be specified in the DN, including things 
like their phone number, email address, and physical address.  The second is 
to provide an alternative to the ITU-managed (or, strictly speaking, 
non-managed) DN space.  For example a DNS name or IP address, which falls 
outside the range of ITU (non-)management, is controlled by the IETF, which 
has jurisdiction over the name space of the Internet-related altName 
components.  However since an altName can only specify a collection of names 
with a single critical attribute to cover all of them, there's no way to 
differentiate between something which really is critical (for example an 
rfc822Name being used in place of DN) and something which is merely present to 
provide extra details on the certificate owner (an rfc822Name being provided 
as a contact address).  One IETF draft overloaded this even further by forcing 
authorityInfoAccess semantics onto some of the altName components.
 
This ambiguity is complicated by the presence of other attributes like path 
processing constraints.  For example does an included or excluded subtree 
constraint containing a DN cover the subjectName DN, the altName 
directoryName, or both?.  More seriously, since a subjectName and altName 
directoryName have the same form, it's possible to specify an identical DN in 
two different ways across an issuer and subject cert, leading to the same 
problem described below in the name constraints section in which it's possible 
to evade constraint checks by using alternative encodings for the same item.
 
The solution to this problem would be to split the altName into two new 
extensions, a true _alt__Name_ which provides a single _alternative_ to the 
subject_Name_ (for example a single dNSName or rfc822Name) and which is used 
only when the subject DN is empty, and a collection of other information about 
the subject which follows the current altName syntax but which is used 
strictly for informational purposes.  The true altName provides a single 
alternative for the subjectName, and the informational altName provides any 
extra identification information which the subject may want to include with 
their certificate.
 
-- Snip --
 
This would require an amendment to X.509v3 though, I'm not sure how likely 
that is to happen.  As it currently stands, the altName semantics are too 
ambiguous to make it possible to rely on altNames for much.
 
Peter.

Date: Fri, 08 May 1998 11:55:25 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

My point was that in my view, at least, the primary purpose for alternate =
subject anmes (and even alternate issuer names) was to convey additional =
optional information to the relying party.

If we start using them to convey all sorts of mandatory contraints, impose =
a requirement to be able to search for them in a directory, etc.,  then I =
think we have started down a different kind of semantics entirely.

I mentioned something along these lines to Hoyt Kesterson a while ago, and =
I believe he told me that X.500 '97 provides the ability have multiple =
DNs, presumably for the same object.  I clearly don't undertand what the =
difference is between a DN and an alias to a ND in a directory, but having =
multiple DNs is a certificate, quite independent of the altSubjectName =
_semantics_ would be worth exploring, I think.

Can someone address this issue, like Sharon or Hoyt?

Bob>
>
>>>> Tony Bartoletti <[email-masked]> 05/08 11:38 AM >>>
>At 12:13 PM 5/7/98 -0600, Bob Jueneman wrote:
>>More seriously, though, where would the user get the logo in the first
>>place, from which to derive the hash in order to begin the search?
>>
>>Or were you only addressing the question of how to file a certificate=20
>>you already had in hand?
>>
>>bob
>
>Actually, I assumed that the "transaction-initiating party" (owner of
>the logo, in this case) would need to convey its location as part of
>the transaction.  But this is not helpful when the RP needs to collect
>yet-other-certs up a chain (cert-pull)...
>
>There would need to be a logo-link (uri) in each cert, akin to the way a
>CA may point to their CPS, for instance.  I am not really up to speed
>on the syntax/handling of subjectAltName.  If it could be an "object"
>then "hashLogo+uri" would be informational of itself, and provide a
>secure foundation for displaying a faithful "picture" for ID purposes.
>
>(I hadn't tried to work it out;)
>
>I suppose I just take it on faith that "a name is a bit-string" and how
>the bits are interpreted is a different matter.  But its not an independen=
t
>matter.  The method of interpretation must be joined with the bit-string
>in order to allow it to convey given meaning.
>
>I like the idea of a jpeg image/logo as a "name". (make it so;)

Date: Fri, 08 May 1998 10:38:30 -0700
To: "Bob Jueneman" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

At 12:13 PM 5/7/98 -0600, Bob Jueneman wrote:
>More seriously, though, where would the user get the logo in the first
>place, from which to derive the hash in order to begin the search?
>
>Or were you only addressing the question of how to file a certificate 
>you already had in hand?
>
>bob

Actually, I assumed that the "transaction-initiating party" (owner of
the logo, in this case) would need to convey its location as part of
the transaction.  But this is not helpful when the RP needs to collect
yet-other-certs up a chain (cert-pull)...

There would need to be a logo-link (uri) in each cert, akin to the way a
CA may point to their CPS, for instance.  I am not really up to speed
on the syntax/handling of subjectAltName.  If it could be an "object"
then "hashLogo+uri" would be informational of itself, and provide a
secure foundation for displaying a faithful "picture" for ID purposes.

(I hadn't tried to work it out;)

I suppose I just take it on faith that "a name is a bit-string" and how
the bits are interpreted is a different matter.  But its not an independent
matter.  The method of interpretation must be joined with the bit-string
in order to allow it to convey given meaning.

I like the idea of a jpeg image/logo as a "name". (make it so;)

___tony___

>>>> Tony Bartoletti <[email-masked]> 05/07 11:43 AM >>>
>At 09:19 AM 5/7/98 -0600, you wrote, in part:
>
>>It has even been suggested that we should take advantage of the "other
>name" form, and allow a JPEG logo to be included in subjectAltName, and
>presumably issuerAltName as well. I think that is a very reasonable
>suggestion, as the logo is more likely to be recognized internationally
>than the name, whether translated or not. but obviously I don't expect to
>do a name search against a logo, much less a name subordination constraint.
>
>Once bandwidth grows to allow JPEG images for _displayable_ names, it may
>make sense to provide a means to convey "HashOfJPEGID" in some field that
>one _could_ search on.
>
>I believe bandwidth WILL become so available, so one should plan for what
>it will allow.
>
>my two cents.
>
>___tony___
>
>
>Tony Bartoletti                                             LL
>SPI-NET GURU                                             LL LL
>Computer Security Technology Center                   LL LL LL
>Lawrence Livermore National Lab                       LL LL LL
>PO Box 808, L - 303                                   LL LL LLLLLLLL
>Livermore, CA 94551-9900                              LL LLLLLLLL
>email: [email-masked]   phone: 510-422-3881             LLLLLLLL
>
>
>

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Fri, 08 May 1998 14:55:33 +0100
From: "Stephen P. Wilson" <[email-masked]>
Organization: Defence Evaluation & Research Agency.
To: Bob Jueneman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Bob Jueneman wrote:
> 
> More seriously, though, where would the user get the logo in the first
> place, from which to derive the hash in order to begin the search?

I suppose if there was a web page for whoever it was you were trying to
obtain the logo of - you could get it from there.

I think there is a much more fundamental problem than that though -
finding things by a simple text name is fairly simple - I don't think
anyone would have a problem spotting a the difference between "Stephen"
and Stephqn" - but, if you have a few hundred bytes of binary data,
that's kind of different - try taking a jpeg, and changing one pixel
from say RGB 0,0,0 (black) to RGB 0,0,1 (nearly black) - how many people
could actually tell the difference? - and, I'm sure they would generate
completely different hash values (especially as they are a compressed
file format - so I don't think it would even be just a single byte that
would change). the same thing goes for resizing the image (slightly more
obvious), changing the colour depth, and a whole host of things you can
do to graphic images which change them so subtly that it might not be
noticable.

Of course, that's not even considering the problems when companies start
redesigning their logos...

Stephen.

-- 
Stephen Wilson. BSc (hons), AMIEE.          [email-masked] 
The views and statements contained in this message are entirely those 
of the author and should not be considered as the opinion or policy 
of any other person or organisation.

From: "Miklos, Sue A." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: SHA-1 and RSA for signing certificates
Date: Fri, 8 May 1998 08:26:50 -0400
Sender: [email-masked]

Based on the Specification FIPS PUB 186, Digital Signature Standard,
dated  19 May 1994 (from NIST) the OID - iso(1) member-body(2) us(840)
x9-57(10040) x9algorithm(4) id-dsa-with-sha1(3) 1.2.840.10040.4.3  

and, I believe the American National Standard X9.57-199x Public Key
Cryptography for the Financial Services Industry: Certificate Management
21 June 1996  also references this oid.  The question for the X9 folks
is whether this oid will be preserved in an international registry.

Sandi

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Thursday, May 07, 1998 11:35 PM
>To: 	[email-masked]
>Cc: 	[email-masked]
>Subject: 	Re: SHA-1 and RSA for signing certificates
>
>>Section 7.2 of PKIX part 1 documents that the object identifier that shall
>>be
>>used to identify certificates signed using SHA-1 with the RSA algorithm will
>>be:
>>
>>        sha1WithRSASignature OBJECT IDENTIFIER  ::=  {
>>            iso(1) identified-organization(3) oiw(14)
>>            secsig(3) algorithm(2) 29  }
>>
>>In the S/MIME -msg draft, section A.4:
>>
>>sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
>>   {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}
>>
>>Who's gonna fix their stuff?
>>
>>I believe that the interpretation of the value represented by both of these
>>OIDs is exactly the same, only there are two different OIDs (only two?!?).
> 
>There are more than a dozen OID's covering SHA and DSA, but only two that I
>know of for SHA and RSA.  The correct ones (well, the OIDs du jour anyway)
>are:
> 
>  SHA-1: sha1 (1 3 14 3 2 26)
>  DSA: dsa (1 2 840 10040 4 1)
>  SHA-1 and DSA: dsaWithSha1 (1 2 840 10040 4 3)
>  SHA-1 and RSA: sha-1WithRSAEncryption (1 2 840 113549 1 1 5)
> 
>The SHA-1 OID is from the mostly-deprecated OIW arc, FIPS 180 never defined
>an
>OID for it but presumably once SHA-1 appears in other standards (eg ISO
>10118-3) it'll get a different OID.
> 
>Peter.
> 
>
>

From: Graham Bland <[email-masked]>
Date: Fri, 8 May 1998 8:42:20 +0000
To: [email-masked]
Subject: RE: Standards for Digitally Signed Docum
Sender: [email-masked]

IDUP-GSS is an API being developed by the cat-ietf group for handling=20
protection and authentication of independant data units
 Extract from abstract of draft-ietf-cat-idup-gss-11=2Etxt follows

   The IDUP-GSS-API extends the GSS-API [RFC-2078] for applications
   requiring protection of a generic data unit (such as a file or
   message) in a way which is independent of the protection of any other
   data unit and independent of any concurrent contact with designated
   ''receivers'' of the data unit=2E  Thus, it is suitable for applications
   such as secure electronic mail where data needs to be protected
   without any on-line connection with the intended recipient(s) of that
   data=2E  The protection offered by IDUP includes services such as data
   origin authentication with data integrity, data confidentiality with
   data integrity, and support for non-repudiation services=2E  Subsequent
   to being protected, the data unit can be transferred to the
   recipient(s) - or to an archive - perhaps to be processed
   (''unprotected'') only days or years later=2E

   Throughout the remainder of this document, the ''unit'' of data
   described in the above paragraph will be referred to as an IDU
   (Independent Data Unit)=2E  The IDU can be of any size (the application
   may, if it wishes, split the IDU into pieces and have the protection
   computed a piece at a time, but the resulting protection token
   applies to the entire IDU)=2E  However, the primary characteristic of
   an IDU is that it represents a stand-alone unit of data whose
   protection is entirely independent of any other unit of data=2E  If an
   application protects several IDUs and sends them all to a single
   receiver, the IDUs may be unprotected by that receiver in any order
   over any time span; no logical connection of any kind is implied by
   the protection process itself=2E

Graham
 ----------
From: WHenry@pec=2Ecom
To: Graham Bland
Subject: RE: Standards for Digitally Signed Docum
Date: Wednesday, 06 May, 1998 6:09PM

 Graham,

 What's an IDUP-GSS mechanism??

> -----Original Message-----
> From:   Graham Bland [SMTP:gbland@zergo=2Ecom]
> Sent:   Wednesday, May 06, 1998 11:38 AM
> To:     ietf-pkix@imc=2Eorg
> Subject:     RE: Standards for Digitally Signed Docum
>
> This could be considered within the context of an IDUP-GSS mechanism
>
> Graham
>  ----------
> From: samiklo@missi=2Encsc=2Emil
> To: ietf-pkix@imc=2Eorg; WHenry@pec=2Ecom
> Subject: RE: Standards for Digitally Signed Docum
> Date: Wednesday, 06 May, 1998 3:28PM
>
> May I suggest that those interested put together the appropriate request
> for a BOF at the Chicago IETF?
>
> Sandi
>
> >----------
> >From:    WHenry[SMTP:WHenry@pec=2Ecom]
> >Sent:    Tuesday, May 05, 1998 1:43 PM
> >To:      'ietf-pkix@imc=2Eorg'
> >Subject:      Standards for Digitally Signed Documents
> >
> > I hope this isn't out of the context of PKIX, but I'll ask anyway=2E Is
> there
> >an IETF WG or other that is handling standards for digitally signed
> >documents?
> >
> > There is an email/message transfer (i=2Ee=2E S/MIME) standard, but ther=
e
> don't
> >appear to be any similar standards for storage of digitally signed
> >documents=2E
> >
> > I see three options:
> > 1) use a proprietary format (e=2Eg=2E Entrust or Verisign) for storing
> >documents; in which case all who need access to the documents require th=
e
> >same public key infrastructure=2E
> > 2) actually store a signed document in S/MIME format=2E
> > 3) create middleware/proprietary option(s) for appending digital
> signatures
> >to the likes of =2Edoc or =2Eppt documents=2E
> >
> > I'd greatly appreciate any comments or thoughts on the above=2E
> >
> > Bill Henry
> > Performance Engineering Corporation
> > 3949 Pender Drive
> > Farifax, VA  22030
> > whenry@pec=2Ecom
> >
> >
> >
> >> -----Original Message-----
> >> From:  Miklos, Sue A=2E [SMTP:samiklo@missi=2Encsc=2Emil]
> >> Sent:  Tuesday, May 05, 1998 9:30 AM
> >> To:    'Blake Ramsdell'; 'Denis=2EPinkas@bull=2Enet'
> >> Cc:    'ietf-pkix@imc=2Eorg'
> >> Subject:    RE: Role names in certificates
> >>
> >> I'm somewhat confused=2E  I had thought that certificates and roles co=
uld
> >> be used in a variety of contexts (applications) for, among other
> things,
> >> access control=2E  Therefore this would appear to extend beyond just t=
he
> >> S/MIME messaging context=2E  Is this of interest to the LDAP access
> >> controls?  Is this useful for the web-based document retrieval
> >> environments?
> >>
> >> Sandi Miklos
> >>
> >>
> >> >----------
> >> >From:      Denis Pinkas[SMTP:Denis=2EPinkas@bull=2Enet]
> >> >Sent:      Tuesday, May 05, 1998 5:49 PM
> >> >To:   Blake Ramsdell
> >> >Cc:   'ietf-pkix@imc=2Eorg'
> >> >Subject:   Re: Role names in certificates
> >> >
> >> >> I have written a draft that I have submitted as an individual (not
> >> under
> >> >> IETF-PKIX)=2E  It describes a concept of using "role" names in
> >> >> certificates for several purposes that are not covered with
> >> conventional
> >> >> PKIX certificates=2E
> >> >
> >> >I am not sure that this thread is relevant to the PKIX WG=2E It might=
 be
> >> >more relevant to the S/MIME WG=2E
> >> >
> >> >> I have currently profiled the rfc822Name choice, but
> >> >> I have heard that there is interesting in profiling the dNSName
> choice
> >> >> also=2E  Cutting and pasting a little bit from the document, roles=20=
are
> >> >> defined for:
> >> >>
> >> >> * The need to sign messages on behalf of people at a domain that ma=
y
>
> or
> >> >> may not have signature services available at the desktop=2E An
> outbound
> >> >> message from a domain may be sent that is signed at the domain mail
> >> >> server=2E
> >> >
> >> >A requirement would be the need to sign a message as the Sales
> Director
> >> >of the Delta Company, who may happen to be John Walker=2E However Joh=
n
> >> >Walker may not have a private key of its own=2E
> >> >
> >> >> * The need to encrypt messages for people at a domain that may not
> have
> >> >> encryption services available at the desktop=2E A message may be
> >> encrypted
> >> >> for the domain mail server using a domain encrypting certificate,
> and
> >> >> that message will be decrypted before local delivery=2E
> >> >
> >> >For the other following cases related to encryption, I wonder why a
> role
> >> >is needed=2E
> >> >
> >> >> * The need to encrypt messages between two mail transfer agents
> (MTAs)=2E
> >> >> This is different than a domain encrypting certificate, in that the
> >> >> message is never encrypted or decrypted at the mail user agent (MUA=
)
> >> >> level=2E
> >> >>
> >> >> * The need to encrypt messages for a keypair that is controlled by
> the
> >> >> domain administrator for the purposes of plaintext access=2E A mess=
age
> >> may
> >> >> be encrypted for the domain mail server using a domain message
> recovery
> >> >> encryption certificate for the purpose of selective plaintext
> recovery
> >> >> by the domain administrator=2E This differs from a domain encryptin=
g
> >> >> certificate in that the message is not necessarily decrypted before
> >> >> local delivery=2E
> >> >>
> >> >> I know that the last one is going to be controversial, and this is
> not
> >> >> an all-or-nothing proposal (you can simply not implement it)=2E
> Please
> >> >> don't flame me for daring to speak its evil name, but keep an open
> mind
> >> >> for the other uses I have listed=2E
> >> >
> >> >> This is meant to get the ball rolling in a direction where we think
> >> >> about PKIX representing entities that are not necessarily a specifi=
c
> >> >> end-entity, but an end-entity with a particular role or
> responsibility=2E
> >> >
> >> >This is the point=2E
> >> >
> >> >> Any insight welcome as to how to address these issues in an
> alternative
> >> >> way=2E
> >> >
> >> >> http://www=2Edeming=2Ecom/users/blaker/draft-ramsdell-role-names is
> always
> >> >> the latest version
> >> >> http://www=2Eietf=2Eorg/internet-drafts/draft-ramsdell-role-names-0=
0=2Etxt
>
> is
> >> >> the current draft at the IETF=2E
> >> >>
> >> >> Now where's my suit=2E=2E=2E
> >> >
> >> >There are several ways to address this issue=2E Among them:
> >> >
> >> >1) a signature server (from a company) is able to sign documents on
> >> >behalf of an employee with its own key and indicate the appropriate
> role
> >> >used by the employee=2E The employee may authenticate to that signatu=
re
> >> >server by whatever means=2E In that case the signer is the company wh=
ich
> >> >indicates the role of the employee=2E
> >> >
> >> >2) a temporary certificate issued by a server of a company includes a
> >> >role and a temporary public key=2E The employee is given back the
> >> >temporary private key so that it can sign documens directly using tha=
t
> >> >private key=2E
> >> >
> >> >If we would like to support such scheme(s), some arrangements would
> need
> >> >to be done to the S/MIME specifications, so I would propose to shift
> >> >this thread to the S/MIME WG=2E
> >> >
> >> >Denis
> >> >
> >> >> Blake
> >> >> --
> >> >> Blake C=2E Ramsdell
> >> >> Worldtalk Corporation
> >> >> For current info, check http://www=2Edeming=2Ecom/users/blaker
> >> >> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
> >> >
> >> >--
> >> >      Denis Pinkas     Bull S=2EA=2E          mailto:Denis=2EPinkas@b=
ull=2Enet
> >> >      Rue Jean Jaures  B=2EP=2E 68            Phone : 33 - 1 30 80 34=
 87
> >> >      78340 Les Clayes sous Bois=2E FRANCE   Fax  : 33 - 1 30 80 33 2=
1
> >> >
> >
>
> --
> Zergo Limited, The Square, Basing View, Basingstoke, Hants=2E RG21 4EG, U=
K
> Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
> Website:  http://www=2Ezergo=2Ecom

--
Zergo Limited, The Square, Basing View, Basingstoke, Hants=2E RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www=2Ezergo=2Ecom

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: SHA-1 and RSA for signing certificates
Date: Thu, 7 May 1998 14:09:03 -0700
Sender: [email-masked]

> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, May 07, 1998 9:26 AM
> To: Blake Ramsdell
> Cc: [email-masked]'
> Subject: Re: SHA-1 and RSA for signing certificates
> 
> 
> Blake:
> 
> This is fixed in a draft that will be posted this week.

Thanks to everyone who pointed out that I was a moron and missed the
conversation from last month regarding this (under the subject
"[IETF-PKIX] PKIX1 inconsistent with PKCS1") that dealt with my exact
issue.  We now return you to static-free programming.

I did find out something interesting about the OIW padding, however.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Thu, 07 May 1998 12:13:27 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

"Never overlook the bandwidth of a station wagon full of tapes."

Particularly since the means of distributing certificates still seems=20
somewhat problematic.

More seriously, though, where would the user get the logo in the first
place, from which to derive the hash in order to begin the search?

Or were you only addressing the qeustion of how to file a certificate=20
you already had in hand?

bob

>>> Tony Bartoletti <[email-masked]> 05/07 11:43 AM >>>
At 09:19 AM 5/7/98 -0600, you wrote, in part:

>It has even been suggested that we should take advantage of the "other
name" form, and allow a JPEG logo to be included in subjectAltName, and
presumably issuerAltName as well. I think that is a very reasonable
suggestion, as the logo is more likely to be recognized internationally
than the name, whether translated or not. but obviously I don't expect to
do a name search against a logo, much less a name subordination constraint.=

Once bandwidth grows to allow JPEG images for _displayable_ names, it may
make sense to provide a means to convey "HashOfJPEGID" in some field that
one _could_ search on.

I believe bandwidth WILL become so available, so one should plan for what
it will allow.

my two cents.

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Thu, 07 May 1998 10:43:17 -0700
To: "Bob Jueneman" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

At 09:19 AM 5/7/98 -0600, you wrote, in part:

>It has even been suggested that we should take advantage of the "other
name" form, and allow a JPEG logo to be included in subjectAltName, and
presumably issuerAltName as well. I think that is a very reasonable
suggestion, as the logo is more likely to be recognized internationally
than the name, whether translated or not. but obviously I don't expect to
do a name search against a logo, much less a name subordination constraint.

Once bandwidth grows to allow JPEG images for _displayable_ names, it may
make sense to provide a means to convey "HashOfJPEGID" in some field that
one _could_ search on.

I believe bandwidth WILL become so available, so one should plan for what
it will allow.

my two cents.

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Thu, 07 May 1998 12:36:36 -0400
To: Nada Kapidzic Cicovic <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Usage of Diffe-Hellman keys
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

You interpret by position correctly.  Diffie-Hellman keys and ElGamal keys
shoudl have different AlgorithmIdentifiers.

Russ

At 01:38 PM 5/7/98 +0200, Nada Kapidzic Cicovic wrote:
>Peter and Russ,
>
>It seems that you both have the same opinion on ElGamal encryption with
>Diffie-Hellman keys. What you are suggesting is to use separate usage and
>object identifier for ElGamal keys.
>
>To me it seems to be an overkill for users who would like to use ElGamal
>for encryption. They would then need to have three different types of keys:
>
>- a pair of DSA keys for signing (being mandatory in PKIX and S/MIME),
>- a pair of DH keys for Diffie-Hellman key exchange (being mandatory in
>PKIX and S/MIME),
>- a pair of DH keys (or ElGamal keys, but essentially they are the same)
>for ElGamal encryption,
>
>in spite the fact that the two latter keys are syntactically the same (I am
>not suggesting the usage of ElGamal signature, so the strength of the
>generators is not questionable).
>
>
>
>Regards,
>Nada
>
>
>At 16:20 5/6/98, Peter Gutmann wrote:
>>>Trying to put this into S/MIME context it seems that Diffie-Hellman keys
may
>>>only be used in the way suggested by Russ Housley, i.e. for each
>recipient to
>>>take recipient's Diffie-Hellman certificate (key agreement certificate),
get
>>>the public key from there, generate a shared key (Russ suggested 3DES)
>and use
>>>it to encrypt the content-encryption key.
>>>
>>>However, another possibility is to use El-Gamal algorithm with
>Diffie-Hellman
>>>keys and encrypt the content-encryption key directly with recipients
>>>Diffie-Hellman public key. This would be a very similar operation as if the
>>>recipient had RSA keys and keyEnchipherment certificate. This seems to be a
>>>much better way of using Diffie-Hellman keys, similar to the way RSA keys
>are
>>>used for keys encryption (unless I have missed some point here).
>> 
>>If you use the key this way then it's no longer DH but Elgamal, with its
own 
>>algorithm/object identifiers and usage requirements.  For example some 
>>generators which are OK for Elgamal encryption aren't secure for Elgamal 
>>signatures, so if you've got DH-pretending-to-be-Elgamal (which PGP does,
>for 
>>example) you can't just use it as if it were Elgamal.  If you want to use a 
>>key for Elgamal encryption/signatures, you should really call it Elgamal,
>and 
>>not take a DH key and use it for something it was never designed for.
>> 
>>(If you want to get really nitpicky, there are actually three different 
>> algorithms which use keys which look more or less the same: DH (key 
>> exchange), Elgamal encryption == DH-Vernam encryption (encryption), and 
>> Elgamal signatures (signature).  It'd be nicer to actually call it Elgamal
>> rather than overload DH further and further)
>> 
>>Peter.
>> 
>>
>>
> 

Date: Thu, 07 May 1998 12:26:17 -0400
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SHA-1 and RSA for signing certificates
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Blake:

This is fixed in a draft that will be posted this week.

Russ

At 12:08 AM 5/7/98 -0700, Blake Ramsdell wrote:
>Section 7.2 of PKIX part 1 documents that the object identifier that
>shall be used to identify certificates signed using SHA-1 with the RSA
>algorithm will be:
>
>        sha1WithRSASignature OBJECT IDENTIFIER  ::=  {
>            iso(1) identified-organization(3) oiw(14)
>            secsig(3) algorithm(2) 29  }
>
>In the S/MIME -msg draft, section A.4:
>
>sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
>   {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}
>
>Who's gonna fix their stuff?
>
>I believe that the interpretation of the value represented by both of
>these OIDs is exactly the same, only there are two different OIDs (only
>two?!?).
>
>In practice, I have not seen any certificates signed using the
>sha1WithRSASignature OID.  I have, however, seen certificates signed
>with sha-1WithRSAEncryption.
>
>I apologize if this has been brought up before -- I found a thread from
>'97 that documents confusion surrounding "sha1WithRSAEncryption" using
>the OIW OID, and the change to make it "sha1WithRSASignature".
>
>For compatibility, it seems that sha-1WithRSAEncryption (the rsadsi
>version) should be recognized on receipt, but that new certificates must
>use sha1WithRSASignature (the OIW version).
>
>Perhaps some of the well-rounded cert people can speak up about what is
>currently out there (Peter from That Country Without Electricity?)
>
>I apologize if this has already come up in the past.  I checked the
>subjects in the (newly available!) '97 archive and didn't find anything.
>
>Blake
> 

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: "'Tim Polk'" <[email-masked]>
Subject: RE: SHA-1 and RSA for signing certificates
Date: Thu, 7 May 1998 12:15:19 -0400 
Sender: [email-masked]

There was an earlier discussion of this OID. I believe that as a result of
that, Tim Polk was going to change it in the PKIX profile to use the RSA
defined OID 1 2 840 113549 1 1 5 (sha1WithRSAEncryption). Tim, I assume your
updated document will contain this fix?

> ----------
> From: 	Blake Ramsdell[SMTP:[email-masked]]
> Sent: 	May 7, 1998 3:08 AM
> To: 	[email-masked]'
> Subject: 	SHA-1 and RSA for signing certificates
> 
> Section 7.2 of PKIX part 1 documents that the object identifier that
> shall be used to identify certificates signed using SHA-1 with the RSA
> algorithm will be:
> 
>         sha1WithRSASignature OBJECT IDENTIFIER  ::=  {
>             iso(1) identified-organization(3) oiw(14)
>             secsig(3) algorithm(2) 29  }
> 
> In the S/MIME -msg draft, section A.4:
> 
> sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
>    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}
> 
> Who's gonna fix their stuff?
> 
> I believe that the interpretation of the value represented by both of
> these OIDs is exactly the same, only there are two different OIDs (only
> two?!?).
> 
> In practice, I have not seen any certificates signed using the
> sha1WithRSASignature OID.  I have, however, seen certificates signed
> with sha-1WithRSAEncryption.
> 
> I apologize if this has been brought up before -- I found a thread from
> '97 that documents confusion surrounding "sha1WithRSAEncryption" using
> the OIW OID, and the change to make it "sha1WithRSASignature".
> 
> For compatibility, it seems that sha-1WithRSAEncryption (the rsadsi
> version) should be recognized on receipt, but that new certificates must
> use sha1WithRSASignature (the OIW version).
> 
> Perhaps some of the well-rounded cert people can speak up about what is
> currently out there (Peter from That Country Without Electricity?)
> 
> I apologize if this has already come up in the past.  I checked the
> subjects in the (newly available!) '97 archive and didn't find anything.
> 
> Blake
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: SHA-1 and RSA for signing certificates
Cc: [email-masked]
Reply-To: [email-masked]
Date: Fri, 8 May 1998 03:35:04 (NZST)
Sender: [email-masked]

>Section 7.2 of PKIX part 1 documents that the object identifier that shall be
>used to identify certificates signed using SHA-1 with the RSA algorithm will
>be:
>
>        sha1WithRSASignature OBJECT IDENTIFIER  ::=  {
>            iso(1) identified-organization(3) oiw(14)
>            secsig(3) algorithm(2) 29  }
>
>In the S/MIME -msg draft, section A.4:
>
>sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
>   {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}
>
>Who's gonna fix their stuff?
>
>I believe that the interpretation of the value represented by both of these
>OIDs is exactly the same, only there are two different OIDs (only two?!?).
 
There are more than a dozen OID's covering SHA and DSA, but only two that I
know of for SHA and RSA.  The correct ones (well, the OIDs du jour anyway) are:
 
  SHA-1: sha1 (1 3 14 3 2 26)
  DSA: dsa (1 2 840 10040 4 1)
  SHA-1 and DSA: dsaWithSha1 (1 2 840 10040 4 3)
  SHA-1 and RSA: sha-1WithRSAEncryption (1 2 840 113549 1 1 5)
 
The SHA-1 OID is from the mostly-deprecated OIW arc, FIPS 180 never defined an
OID for it but presumably once SHA-1 appears in other standards (eg ISO
10118-3) it'll get a different OID.
 
Peter.

Date: Thu, 07 May 1998 09:19:16 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Alternate name semantics and usage
Sender: [email-masked]

John, Steve, et al,

My very strong preference is to mandate the use of DNs in certificates, =
both for end-entities and especially for CAs.  And the schema for these =
DNs ought to be drawn from a rather limited set of the allegedly "useful =
attributes" defined in X.520, unless or until PKIX gets around (after five =
years and counting) to defining an acceptable schema.

Given such a restriction, I can at least be guaranteed a way of finding =
and/or revoking a certificate, although adding the hash of the public key =
would be better yet.

I really can't take seriously any proposal to apply name subordination =
constraints, etc., on subjectAltNames when the intent was to be rather =
loose about what those names were intended to contain.

The question of who "owns" or registers name in the DN space is not only =
ludicrous, but moot.  CAs are going to define them, and directory service =
providers are going to decide whether or not that schema is acceptable for =
their directory, and everything else will spill on the floor.

The thread that John was discussing may or may not have been the one on =
cert-talk where I was discussing what to do about multilingual countries, =
but there is clearly a need to define at least "roughly equivalent" names =
that are either official or unofficial translations or transliterations of =
the presumably "official" primary DN.

I won't attempt to type it in in Cryllic, but if Russian newspaper xxx =
xxxxxx is transliterated to "Krasynia Isvestia" or translated to "Red =
Star", then assuming that the publisher of that newpaper has some reason =
to have his organization's certificates be reasonably meaningful or =
comprehensible to non-Russian speakers, he needs to be able to publish =
those alternatives somewhere.  The obvious (and perhaps only) choice at =
present is subjectAltNames.

In addition to transliterating the official name into the latin alphabet =
and perhaps trnaslating it into English, a savvy Russian marketeer (no =
longer an oxymoron!) might well want to include Japanese (Kanji and/or =
katakana), Chinese, Arabic, Hebrew, Bengali, Urdu, etc., in addition to =
the more popular European languages (French, German, etc.)

I believe that it is reasonable to require the CA do perform its due =
diligence on the DN, maybe even vouching for the organization's right to =
use.  However, I very much doubt that most CAs would step up to a due =
diligence verification of  all of the possible alternative spellings and =
translations. Nor should they have to, especially if such constructs are =
presented as alternate names.

Of course, having to select one and only one name for inclusion in the DN =
may cause political incorrectness in some countries that are aggressively =
bilingual, e.g. Canada. In that case I would suggest that two certificates,=
 one with the DN in lanuguage A and the other with the DN in language B =
may be appropriate. They might or might not have the same public key.

It has even been suggested that we should take advantage of the "other =
name" form, and allow a JPEG logo to be included in subjectAltName, and =
presumably issuerAltName as well. I think that is a very reasonable =
suggestion, as the logo is more likely to be recognized internationally =
than the name, whether translated or not. but obviously I don't expect to =
do a name search against a logo, much less a name subordination constraint.=

Although it is (normally) perfectly feasible for a directory provider to =
map the alternate names to directory aliases, this isn't a universal =
requirement. the relying party can either do it or not, as he sees fit.

So my bottom line is that the alternate names should be primarily intended =
for use as a human-readable confirmation of the subscriber's identity, but =
not necessarily for use as a means of searching for that name.

If someone requires that an RFC822 name or a DNS name be included, I would =
think that in most cases it would suffice to include it in the alternate =
name form, and comparisons at the application level can be done against =
that name. If it is absolutely essential to include such a construct in =
the DN, we ought to define an attribute and assign it a suitable OID.  I =
would hate to see the semantics of commonName being debased more and more, =
just because implementors (or standards groups) are too lazy to define =
something more precisely.

<rant off>

Bob

>>> <[email-masked]> 05/07 6:13 AM >>>
Stephen Kent <[email-masked]> writes:

>
>Also, in practice, folks have used a wide variety of DNs in certs, in =
part
>because we have no formal, binding schema, as I noted previously.  Still,
I
>could interpret your suggestion to be that if a DN consisted of all DC
>attributes (and matching values), then there would be no ambiguity and =
one
>could establish a convention in the IETF sphere of influence to consider
>such DNs as equivalent to an AltName of the DNS form, right?
>
>Well, I guess one might pursue that path.  Is the major benefit of having
>these DNS names in sheeps (I mean DN) clothing, to facilitate lookup in
>LDAP servers?  Given the availability of AltNames, we don't want to
>encourage this hack as an alternative to use of those constructs.  Also,
we
>will now find ourselves with two supposedly equivalent ways of
representing
>the same name, which would further complicate the matching problems we've
>already been discussing just due to the various string representations in
>DNs.  Also, this approach doesn't address what I assume is the major
legacy
>problem we are facing now.  Many of the legacy examples we see are hybrid
>names that look like DNs, but just happen to end with a CN that is a DNS
>name (c.f. ALL SSL server certificate Subject names).
>
>So, before considering your suggestionn further, I'd like to see a more
>complete analysis of what problems we are solving and what new problems =
we
>are creating, to better understand the tradeoffs.

The most basic problem is: what combinations of names and set of naming
syntaxes have to be understood (i.e. have code specially written for them)
by an end-system or CA or OCSP responder or other infrastructure component
that wants to claim PKIX compliance (and implied interoperability with
other end-systems that make the same claim).  The more choice there is in
naming certificate issuers, the larger this required task becomes, and the
more potential for ambiguity is introduced into the spec.  This has =
effects
throughout the system, some of which are:

i) Chain processing, certificate retrieval: Given a certificate, I need to
be able to find certificates for the issuer.  To do this, I need some
mapping that takes me from the set of names in the certificate's Issuer =
and
IssuerAltName fields to a query I can pass to whatever certificate store
I'm using.  As an implementor, faced with the choice between a single
syntax (DN) and a plethora of syntaxes (DN, rfc822Name, dNSName,
x400Address, DN(again), EDIPartyName, URI, ipAddress, registeredID and
"otherName") with the possibility of more than one name using these
syntaxes, I know which choice makes my life easiest.

ii) Chain processing, path validity checking: There was a thread back in
January that discussed the meaning of a certificate that contained =
multiple
subject names (either in the Subject or SubjectAltName fields, or in the
combination of these), and whether the certificate bound each name
individually or the combination of all names to the key.  This discussion
petered out without real resolution, and only addressed end-entity certs.
The problem is greatly magnified with CA-certs.  If I have a trusted
CA-cert that contains multiple subject names, can it be used to verify
another cert whose issuer field contains a subset of those names, a
superset, or do the sets have to exactly match?  How about if there's just
a non-empty intersection?  How about if there's only one name in each =
cert,
and it's the same DN, but in one cert it's expressed as the Subject, while
in the other it's expressed as the directoryName choice in the
IssuerAltName?  How is any of this affected by the setting of the critical
bit in the IssuerAltName or SubjectAltName fields of the two certificates
(PKIX-1 makes setting this bit mandatory if the corresponding "non-Alt"
name is empty, but is silent if there is a non-Alt name)?  PKIX-1, section
6 states that the Issuer and Subject fields shall be used to chain, unless
they're empty, in which case the Alt fields should be used, but I'm not
sure this is correct, particularly if there's a critical Alt field _and_ a
corresponding non-empty non-Alt field.  On the other hand, the presence of
the critical bit isn't supposed to change the semantics implied by an
extension, it's merely supposed to indicate whether the certificate may be
processed by an end-system that doesn't understand the extension, so it
would be wrong to overload this bit to change the semantics of trust-chain
processing by end-systems that fully understand the extension.

iii) Chain processing, name constraints: Subtree constraints are defined
for DNs, rfc822, dNSName, uri names and (possibly) x400Address.  No =
mention
of EDIPartyName, ipAddress, registeredID or "otherName".  Is a
PKIX-compliant end-system expected to be able to apply name-constraints =
for
all these name types?  Do subtree constraints have to be satisfied on all
name-types, or just one name-type (the answer to this may be determined by
the answer to (ii) above).

iv) OCSP (the subject of this thread):  I need to be able to unambiguously
identify a certificate when querying its status.  If a certificate's =
issuer
is identified by a single IssuerAltName, then I need a way in the OCSP
protocol to send that along instead of a DN, and if the certificate has
multiple IssuerAltNames or both a Issuer and IssuerAltName(s), then I
presumably need to be able to send multiple names to the responder.  Does
is matter whether the IssuerAltName(s) are marked critical?  Presumably it
does, since an end-system ought to be able to ignore any non-critical
extension it doesn't understand, so an end system that doesn't understand
the IssuerAltName extension ought to be able to make an OCSP query without
including anything from that extension in the query, without causing a
security problem.

Requiring the use of the Issuer field (combined with a prohibition on
setting the critical bit on the IssuerAltName extension) in all PKIX
certificates greatly simplifies these issues.  Alternatively, we need to
fully address all the ambiguities that the use of "distinguished-AltNames"
introduces.  Unless this can be done very quickly, we should go with just
DNs, as it's imperative that we advance the spec ASAP.  We can always add
back other issuer name types when we properly define the semantics of
certificates that use them.

John

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Thu, 7 May 1998 10:21:36 -0400
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

>> iii) Chain processing, name constraints: Subtree constraints are defined
>> for DNs, rfc822, dNSName, uri names and (possibly) x400Address.  No
mention
>> of EDIPartyName, ipAddress, registeredID or "otherName".  Is a
>> PKIX-compliant end-system expected to be able to apply name-constraints
for
>> all these name types?  Do subtree constraints have to be satisfied on
all
>> name-types, or just one name-type (the answer to this may be determined
by
>> the answer to (ii) above).
>
>This is the most important issue. If we can solve the case of name
>constraints with DNs, I see no reason why we could not solve it for
>rfc822 and dNSName. This would at least allow an issuer name to be
>either a DN or an rfc822 or a dNSName.

"Either" is the key qualifier.  Today, the PKIX-1 spec allows a certificate
to carry an Issuer name and a number of IssuerAltNames, and this is the
source of many of the problems I referred to in my earlier post.  If we
were to constrain PKIX CAs to identify themselves in certificates using
only a single name (i.e. either a DN which would go in the issuer field of
certificates they cut, or a single rfc822 or dNSName which would be placed
in the IssuerAltName extension of their certificates), that would go a long
way towards simplifying the problem.  Subtree constraints are already
defined for both of these AltName types.

The issue still remains of what do constraints mean in a certificate chain
that crosses over between name-spaces. Suppose I have a certificate chain
that starts in the DN namespace, and in which subtree constraints are
applied by some early certificate.  Can a later CA-certificate (with an
issuer DN permitted by the subtree constraints) contain a subject field
expressed using the dNSName syntax?  How about if the DN-namespace
constraints permit the use of names below the /DC=xxx root that matches the
first domain component in the dNSName of the certificate in question?  This
problem is one argument for preferring the use of RFC2247-format DNs names
over dNSNames when trying to put a DNS name into a certificate.

>> iv) OCSP (the subject of this thread):  I need to be able to
unambiguously
>> identify a certificate when querying its status.  If a certificate's
issuer
>> is identified by a single IssuerAltName, then I need a way in the OCSP
>> protocol to send that along instead of a DN, and if the certificate has
>> multiple IssuerAltNames or both a Issuer and IssuerAltName(s), then I
>> presumably need to be able to send multiple names to the responder.
Does
>> is matter whether the IssuerAltName(s) are marked critical?  Presumably
it
>> does, since an end-system ought to be able to ignore any non-critical
>> extension it doesn't understand, so an end system that doesn't
understand
>> the IssuerAltName extension ought to be able to make an OCSP query
without
>> including anything from that extension in the query, without causing a
>> security problem.
>
>I believe that the answer has already be given on this topic. Option 3,
>as originally proposed by Ambarish, is the preferred option. We could
>use either the DN or the Alternate name (in addition to the certificate
>serial and a hash of the CA public key).

That's fine, provided we insist that there may be only a single issue name
in every PKIX certificate (although the OCSP syntax will have to allow for
the name type to be conveyed in the protocol when IssuerAltName is used).

John

Date: Thu, 07 May 1998 15:38:29 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: [email-masked]
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

John,

Thank you for joinging us on this thread.

> Stephen Kent <[email-masked]> writes:

> >Also, in practice, folks have used a wide variety of DNs in certs, in part
> >because we have no formal, binding schema, as I noted previously.  Still,
> >I could interpret your suggestion to be that if a DN consisted of all DC
> >attributes (and matching values), then there would be no ambiguity and one
> >could establish a convention in the IETF sphere of influence to consider
> >such DNs as equivalent to an AltName of the DNS form, right?
> >
> >Well, I guess one might pursue that path.  Is the major benefit of having
> >these DNS names in sheeps (I mean DN) clothing, to facilitate lookup in
> >LDAP servers?  Given the availability of AltNames, we don't want to
> >encourage this hack as an alternative to use of those constructs.  Also,
> >we will now find ourselves with two supposedly equivalent ways of
> >representing the same name, which would further complicate the 
> >matching problems we've already been discussing just due to the 
> >various string representations in DNs.  Also, this approach doesn't 
> >address what I assume is the major legacy problem we are facing now.  
> >Many of the legacy examples we see are hybrid names that look like DNs,
> >but just happen to end with a CN that is a DNS name (c.f. ALL SSL 
> >server certificate Subject names).
> >
> >So, before considering your suggestion further, I'd like to see a more
> >complete analysis of what problems we are solving and what new problems we
> >are creating, to better understand the tradeoffs.
> 
> The most basic problem is: what combinations of names and set of naming
> syntaxes have to be understood (i.e. have code specially written for them)
> by an end-system or CA or OCSP responder or other infrastructure component
> that wants to claim PKIX compliance (and implied interoperability with
> other end-systems that make the same claim).  The more choice there is in
> naming certificate issuers, the larger this required task becomes, and the
> more potential for ambiguity is introduced into the spec.  This has effects
> throughout the system, some of which are:
> 
> i) Chain processing, certificate retrieval: Given a certificate, I need to
> be able to find certificates for the issuer.  To do this, I need some
> mapping that takes me from the set of names in the certificate's Issuer and
> IssuerAltName fields to a query I can pass to whatever certificate store
> I'm using.  As an implementor, faced with the choice between a single
> syntax (DN) and a plethora of syntaxes (DN, rfc822Name, dNSName,
> x400Address, DN(again), EDIPartyName, URI, ipAddress, registeredID and
> "otherName") with the possibility of more than one name using these
> syntaxes, I know which choice makes my life easiest.
> 
> ii) Chain processing, path validity checking: There was a thread back in
> January that discussed the meaning of a certificate that contained multiple
> subject names (either in the Subject or SubjectAltName fields, or in the
> combination of these), and whether the certificate bound each name
> individually or the combination of all names to the key.  This discussion
> petered out without real resolution, and only addressed end-entity certs.
> The problem is greatly magnified with CA-certs.  If I have a trusted
> CA-cert that contains multiple subject names, can it be used to verify
> another cert whose issuer field contains a subset of those names, a
> superset, or do the sets have to exactly match?  How about if there's just
> a non-empty intersection?  How about if there's only one name in each cert,
> and it's the same DN, but in one cert it's expressed as the Subject, while
> in the other it's expressed as the directoryName choice in the
> IssuerAltName?  How is any of this affected by the setting of the critical
> bit in the IssuerAltName or SubjectAltName fields of the two certificates
> (PKIX-1 makes setting this bit mandatory if the corresponding "non-Alt"
> name is empty, but is silent if there is a non-Alt name)?  PKIX-1, section
> 6 states that the Issuer and Subject fields shall be used to chain, unless
> they're empty, in which case the Alt fields should be used, but I'm not
> sure this is correct, particularly if there's a critical Alt field _and_ a
> corresponding non-empty non-Alt field.  On the other hand, the presence of
> the critical bit isn't supposed to change the semantics implied by an
> extension, it's merely supposed to indicate whether the certificate may be
> processed by an end-system that doesn't understand the extension, so it
> would be wrong to overload this bit to change the semantics of trust-chain
> processing by end-systems that fully understand the extension.
> 
> iii) Chain processing, name constraints: Subtree constraints are defined
> for DNs, rfc822, dNSName, uri names and (possibly) x400Address.  No mention
> of EDIPartyName, ipAddress, registeredID or "otherName".  Is a
> PKIX-compliant end-system expected to be able to apply name-constraints for
> all these name types?  Do subtree constraints have to be satisfied on all
> name-types, or just one name-type (the answer to this may be determined by
> the answer to (ii) above).

This is the most important issue. If we can solve the case of name
constraints with DNs, I see no reason why we could not solve it for
rfc822 and dNSName. This would at least allow an issuer name to be
either a DN or an rfc822 or a dNSName.

> iv) OCSP (the subject of this thread):  I need to be able to unambiguously
> identify a certificate when querying its status.  If a certificate's issuer
> is identified by a single IssuerAltName, then I need a way in the OCSP
> protocol to send that along instead of a DN, and if the certificate has
> multiple IssuerAltNames or both a Issuer and IssuerAltName(s), then I
> presumably need to be able to send multiple names to the responder.  Does
> is matter whether the IssuerAltName(s) are marked critical?  Presumably it
> does, since an end-system ought to be able to ignore any non-critical
> extension it doesn't understand, so an end system that doesn't understand
> the IssuerAltName extension ought to be able to make an OCSP query without
> including anything from that extension in the query, without causing a
> security problem.

I believe that the answer has already be given on this topic. Option 3,
as originally proposed by Ambarish, is the preferred option. We could
use either the DN or the Alternate name (in addition to the certificate
serial and a hash of the CA public key).
 
> Requiring the use of the Issuer field (combined with a prohibition on
> setting the critical bit on the IssuerAltName extension) in all PKIX
> certificates greatly simplifies these issues.  Alternatively, we need to
> fully address all the ambiguities that the use of "distinguished-AltNames"
> introduces.  Unless this can be done very quickly, we should go with just
> DNs, as it's imperative that we advance the spec ASAP.  We can always add
> back other issuer name types when we properly define the semantics of
> certificates that use them.

I would agree with you that we need a quick solution. However, if some
one has some time available to transpose what is applicable to DNs to
the two other naming formats, then we could progress. This seems to be a
manageable work. Any candidate ?

Denis 

> John

-- 
      Denis Pinkas     Bull S.A.          mailto:[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

From: [email-masked]
To: Stephen Kent <[email-masked]>
cc: [email-masked]
Date: Thu, 7 May 1998 08:13:02 -0400
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>
>Also, in practice, folks have used a wide variety of DNs in certs, in part
>because we have no formal, binding schema, as I noted previously.  Still,
I
>could interpret your suggestion to be that if a DN consisted of all DC
>attributes (and matching values), then there would be no ambiguity and one
>could establish a convention in the IETF sphere of influence to consider
>such DNs as equivalent to an AltName of the DNS form, right?
>
>Well, I guess one might pursue that path.  Is the major benefit of having
>these DNS names in sheeps (I mean DN) clothing, to facilitate lookup in
>LDAP servers?  Given the availability of AltNames, we don't want to
>encourage this hack as an alternative to use of those constructs.  Also,
we
>will now find ourselves with two supposedly equivalent ways of
representing
>the same name, which would further complicate the matching problems we've
>already been discussing just due to the various string representations in
>DNs.  Also, this approach doesn't address what I assume is the major
legacy
>problem we are facing now.  Many of the legacy examples we see are hybrid
>names that look like DNs, but just happen to end with a CN that is a DNS
>name (c.f. ALL SSL server certificate Subject names).
>
>So, before considering your suggestionn further, I'd like to see a more
>complete analysis of what problems we are solving and what new problems we
>are creating, to better understand the tradeoffs.

The most basic problem is: what combinations of names and set of naming
syntaxes have to be understood (i.e. have code specially written for them)
by an end-system or CA or OCSP responder or other infrastructure component
that wants to claim PKIX compliance (and implied interoperability with
other end-systems that make the same claim).  The more choice there is in
naming certificate issuers, the larger this required task becomes, and the
more potential for ambiguity is introduced into the spec.  This has effects
throughout the system, some of which are:

i) Chain processing, certificate retrieval: Given a certificate, I need to
be able to find certificates for the issuer.  To do this, I need some
mapping that takes me from the set of names in the certificate's Issuer and
IssuerAltName fields to a query I can pass to whatever certificate store
I'm using.  As an implementor, faced with the choice between a single
syntax (DN) and a plethora of syntaxes (DN, rfc822Name, dNSName,
x400Address, DN(again), EDIPartyName, URI, ipAddress, registeredID and
"otherName") with the possibility of more than one name using these
syntaxes, I know which choice makes my life easiest.

ii) Chain processing, path validity checking: There was a thread back in
January that discussed the meaning of a certificate that contained multiple
subject names (either in the Subject or SubjectAltName fields, or in the
combination of these), and whether the certificate bound each name
individually or the combination of all names to the key.  This discussion
petered out without real resolution, and only addressed end-entity certs.
The problem is greatly magnified with CA-certs.  If I have a trusted
CA-cert that contains multiple subject names, can it be used to verify
another cert whose issuer field contains a subset of those names, a
superset, or do the sets have to exactly match?  How about if there's just
a non-empty intersection?  How about if there's only one name in each cert,
and it's the same DN, but in one cert it's expressed as the Subject, while
in the other it's expressed as the directoryName choice in the
IssuerAltName?  How is any of this affected by the setting of the critical
bit in the IssuerAltName or SubjectAltName fields of the two certificates
(PKIX-1 makes setting this bit mandatory if the corresponding "non-Alt"
name is empty, but is silent if there is a non-Alt name)?  PKIX-1, section
6 states that the Issuer and Subject fields shall be used to chain, unless
they're empty, in which case the Alt fields should be used, but I'm not
sure this is correct, particularly if there's a critical Alt field _and_ a
corresponding non-empty non-Alt field.  On the other hand, the presence of
the critical bit isn't supposed to change the semantics implied by an
extension, it's merely supposed to indicate whether the certificate may be
processed by an end-system that doesn't understand the extension, so it
would be wrong to overload this bit to change the semantics of trust-chain
processing by end-systems that fully understand the extension.

iii) Chain processing, name constraints: Subtree constraints are defined
for DNs, rfc822, dNSName, uri names and (possibly) x400Address.  No mention
of EDIPartyName, ipAddress, registeredID or "otherName".  Is a
PKIX-compliant end-system expected to be able to apply name-constraints for
all these name types?  Do subtree constraints have to be satisfied on all
name-types, or just one name-type (the answer to this may be determined by
the answer to (ii) above).

iv) OCSP (the subject of this thread):  I need to be able to unambiguously
identify a certificate when querying its status.  If a certificate's issuer
is identified by a single IssuerAltName, then I need a way in the OCSP
protocol to send that along instead of a DN, and if the certificate has
multiple IssuerAltNames or both a Issuer and IssuerAltName(s), then I
presumably need to be able to send multiple names to the responder.  Does
is matter whether the IssuerAltName(s) are marked critical?  Presumably it
does, since an end-system ought to be able to ignore any non-critical
extension it doesn't understand, so an end system that doesn't understand
the IssuerAltName extension ought to be able to make an OCSP query without
including anything from that extension in the query, without causing a
security problem.

Requiring the use of the Issuer field (combined with a prohibition on
setting the critical bit on the IssuerAltName extension) in all PKIX
certificates greatly simplifies these issues.  Alternatively, we need to
fully address all the ambiguities that the use of "distinguished-AltNames"
introduces.  Unless this can be done very quickly, we should go with just
DNs, as it's imperative that we advance the spec ASAP.  We can always add
back other issuer name types when we properly define the semantics of
certificates that use them.

John

Date: Thu, 07 May 1998 13:38:42 +0200
To: [email-masked], [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: Re: Usage of Diffe-Hellman keys
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter and Russ,

It seems that you both have the same opinion on ElGamal encryption with
Diffie-Hellman keys. What you are suggesting is to use separate usage and
object identifier for ElGamal keys.

To me it seems to be an overkill for users who would like to use ElGamal
for encryption. They would then need to have three different types of keys:

- a pair of DSA keys for signing (being mandatory in PKIX and S/MIME),
- a pair of DH keys for Diffie-Hellman key exchange (being mandatory in
PKIX and S/MIME),
- a pair of DH keys (or ElGamal keys, but essentially they are the same)
for ElGamal encryption,

in spite the fact that the two latter keys are syntactically the same (I am
not suggesting the usage of ElGamal signature, so the strength of the
generators is not questionable).

Regards,
Nada

At 16:20 5/6/98, Peter Gutmann wrote:
>>Trying to put this into S/MIME context it seems that Diffie-Hellman keys may
>>only be used in the way suggested by Russ Housley, i.e. for each
recipient to
>>take recipient's Diffie-Hellman certificate (key agreement certificate), get
>>the public key from there, generate a shared key (Russ suggested 3DES)
and use
>>it to encrypt the content-encryption key.
>>
>>However, another possibility is to use El-Gamal algorithm with
Diffie-Hellman
>>keys and encrypt the content-encryption key directly with recipients
>>Diffie-Hellman public key. This would be a very similar operation as if the
>>recipient had RSA keys and keyEnchipherment certificate. This seems to be a
>>much better way of using Diffie-Hellman keys, similar to the way RSA keys
are
>>used for keys encryption (unless I have missed some point here).
> 
>If you use the key this way then it's no longer DH but Elgamal, with its own 
>algorithm/object identifiers and usage requirements.  For example some 
>generators which are OK for Elgamal encryption aren't secure for Elgamal 
>signatures, so if you've got DH-pretending-to-be-Elgamal (which PGP does,
for 
>example) you can't just use it as if it were Elgamal.  If you want to use a 
>key for Elgamal encryption/signatures, you should really call it Elgamal,
and 
>not take a DH key and use it for something it was never designed for.
> 
>(If you want to get really nitpicky, there are actually three different 
> algorithms which use keys which look more or less the same: DH (key 
> exchange), Elgamal encryption == DH-Vernam encryption (encryption), and 
> Elgamal signatures (signature).  It'd be nicer to actually call it Elgamal
> rather than overload DH further and further)
> 
>Peter.
> 
>
>

From: "Rich Ankney" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: SHA-1 and RSA for signing certificates
Date: Thu, 7 May 1998 07:37:40 -0400
Sender: [email-masked]

I used to run the OIW registry, although I'm not responsible
for the one below.  We never registered PKCS #1 OIDs
(just documented them).  RSASignature indicates the use
of ISO 9796-style padding.  I assume that sha1WithRSA-
Signature follows the same approach.  So PKIX-1 is wrong
and S/MIME is right.  (We went through this exercise for
SET, as well).

Regards,
Rich

----------
> From: Blake Ramsdell <[email-masked]>
> To: [email-masked]'
> Subject: SHA-1 and RSA for signing certificates
> Date: Thursday, May 07, 1998 3:08 AM
> 
> Section 7.2 of PKIX part 1 documents that the object identifier that
> shall be used to identify certificates signed using SHA-1 with the RSA
> algorithm will be:
> 
>         sha1WithRSASignature OBJECT IDENTIFIER  ::=  {
>             iso(1) identified-organization(3) oiw(14)
>             secsig(3) algorithm(2) 29  }
> 
> In the S/MIME -msg draft, section A.4:
> 
> sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
>    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}
> 
> Who's gonna fix their stuff?
> 
> I believe that the interpretation of the value represented by both of
> these OIDs is exactly the same, only there are two different OIDs (only
> two?!?).
> 
> In practice, I have not seen any certificates signed using the
> sha1WithRSASignature OID.  I have, however, seen certificates signed
> with sha-1WithRSAEncryption.
> 
> I apologize if this has been brought up before -- I found a thread from
> '97 that documents confusion surrounding "sha1WithRSAEncryption" using
> the OIW OID, and the change to make it "sha1WithRSASignature".
> 
> For compatibility, it seems that sha-1WithRSAEncryption (the rsadsi
> version) should be recognized on receipt, but that new certificates must
> use sha1WithRSASignature (the OIW version).
> 
> Perhaps some of the well-rounded cert people can speak up about what is
> currently out there (Peter from That Country Without Electricity?)
> 
> I apologize if this has already come up in the past.  I checked the
> subjects in the (newly available!) '97 archive and didn't find anything.
> 
> Blake

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: SHA-1 and RSA for signing certificates
Date: Thu, 7 May 1998 00:08:24 -0700
Sender: [email-masked]

Section 7.2 of PKIX part 1 documents that the object identifier that
shall be used to identify certificates signed using SHA-1 with the RSA
algorithm will be:

        sha1WithRSASignature OBJECT IDENTIFIER  ::=  {
            iso(1) identified-organization(3) oiw(14)
            secsig(3) algorithm(2) 29  }

In the S/MIME -msg draft, section A.4:

sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
   {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

Who's gonna fix their stuff?

I believe that the interpretation of the value represented by both of
these OIDs is exactly the same, only there are two different OIDs (only
two?!?).

In practice, I have not seen any certificates signed using the
sha1WithRSASignature OID.  I have, however, seen certificates signed
with sha-1WithRSAEncryption.

I apologize if this has been brought up before -- I found a thread from
'97 that documents confusion surrounding "sha1WithRSAEncryption" using
the OIW OID, and the change to make it "sha1WithRSASignature".

For compatibility, it seems that sha-1WithRSAEncryption (the rsadsi
version) should be recognized on receipt, but that new certificates must
use sha1WithRSASignature (the OIW version).

Perhaps some of the well-rounded cert people can speak up about what is
currently out there (Peter from That Country Without Electricity?)

I apologize if this has already come up in the past.  I checked the
subjects in the (newly available!) '97 archive and didn't find anything.

Blake

Date: Wed, 6 May 1998 20:49:33 -0400
To: Trevor Freeman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: [IETF-PKIX] OCSP: Method of Identifying Certificates
Cc: [email-masked]
Sender: [email-masked]

Trevor,

The question of who "owns" a name space is important to the question of
whether ones must "trust" a CA, or whether the CA is authoritative for the
name space in which it certifies (and thus "trust" is mostly an irrelevant
concept).  Certainly a (the?) traditional X.500 view holds that CAs are
just TTPs, and other folks are the authoritative sources of names.
However, in practice, this leads to complex certification systems that are
hard to manage, hard to understand, and possibly subject to legal liability
claims.

On a different level, though, the question still remains whether we ought
to encourage people to encode Internet identifiers as DNs when we have
well-defined name forms for doing just that.

Yes, some folks have expressed support for this position on the list, but
only recently.  An approximately equal number have expressed opposition,
and most members have been silent.  We'll see how this progresses.

Steve

From: "Blake Ramsdell" <[email-masked]>
To: "'John Lowry'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Role names in certificates
Date: Wed, 6 May 1998 14:58:15 -0700
Sender: [email-masked]

> From: John Lowry [mailto:[email-masked]]
> Sent: Tuesday, May 05, 1998 8:18 AM
> To: Blake Ramsdell; [email-masked]'
> Subject: Re: Role names in certificates
> 
> 	Including a domain controller (either human or agent) is an old
> 	established concept (1988 ?) and it has value at 
> several points in 
> 	the network.  One of the most interesting is at a 
> firewall or other
> 	domain controller where one wants to control the inflow
> 	(and outflow !) of things like viruses and other nasties.
> 	Further, the entire intrusion detection community needs
> 	to consider this technique because the widespread use of IPSEC
> 	will effectively remove their ability to deploy sensors.  I know
> 	that this can imply the development of "multicast 
> IPSEC", one key for the
> 	destination host and one for the FW, but that shouldn't stop
> 	PKIX from considering role-based certificates.

I would love to hear some specifics about these concepts.  Right now I
have been thinking about the specific case where an entity is identified
by an rfc822Name.  I fully agree that communicating that "this signed
thing was signed by an entity whose job in life is to make sure there
aren't any viruses in it", etc.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: Role names in certificates
Date: Wed, 6 May 1998 14:53:11 -0700
Sender: [email-masked]

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, May 05, 1998 2:50 PM
> To: Blake Ramsdell
> Cc: [email-masked]'
> Subject: Re: Role names in certificates
> 
> 
> > I have written a draft that I have submitted as an 
> individual (not under
> > IETF-PKIX).  It describes a concept of using "role" names in
> > certificates for several purposes that are not covered with 
> conventional
> > PKIX certificates.  
> 
> I am not sure that this thread is relevant to the PKIX WG. It might be
> more relevant to the S/MIME WG.

It may end up this way -- the original intent was to profile roles for
other name types besides rfc822Name (specifically, dNSName).  If we end
up just doing rfc822Name, it might end up in S/MIME, but roles in
rfc822Name may be applicable to other profiles that use email addresses
for end-entities.  We'll see how it hammers out, and where we end up.
 
> A requirement would be the need to sign a message as the 
> Sales Director
> of the Delta Company, who may happen to be John Walker. However John
> Walker may not have a private key of its own.

I think that this may be another use of role that has different
semantics -- in my case the role was "This certificate belongs to an
entity that is signing messages on behalf of individuals at this
organization", vs. your valid example of "This certificate belongs to
the Sales Director of the Delta Company".  This may be an additional
role that we can consider.

> For the other following cases related to encryption, I wonder 
> why a role
> is needed.

They may not be.  In the event that the sending agent is an MTA and it
wants to encrypt messages to another particular MTA, I didn't know if a
special semantic should be communicated so that there was no confusion
during configuration that the certificate was suitable for MTA-to-MTA
encryption.  It may not be.

The plaintext recovery role seems useful so that the sending agent can
provide user feedback to the effect of "You are encrypting for a
certificate that is being used for message recovery.  Is that cool?"

> 1) a signature server (from a company) is able to sign documents on
> behalf of an employee with its own key and indicate the appropriate
role
> used by the employee. The employee may authenticate to that signature
> server by whatever means. In that case the signer is the company which
> indicates the role of the employee.

I think that the server vouching for the role of the employee is a
separate problem.  The first point that I was hoping to get to was an
automated agent signing all messages leaving the organization, and then
associating semantics with that.

As a separate problem, the company gateway placing a signature on the
message based on his assessment that this individual is indeed the
"CFO", "CEO", or whatever, may be interesting.

> 2) a temporary certificate issued by a server of a company includes a
> role and a temporary public key. The employee is given back the
> temporary private key so that it can sign documens directly using that
> private key.

In the particular usage that I have in mind (signing at the MTA), this
would be self-defeating -- you still have to distribute keys, educate
users, and enforce policy at the individual level.

Thanks for the comments...

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Wed, 06 May 1998 17:51:08 -0400
To: [email-masked]
From: Alan Kotok <[email-masked]>
Subject: W3C DSig plans
Cc: "Phillip M. Hallam-Baker" <[email-masked]>
Sender: [email-masked]

A recent posting to this list of Phill's was forwarded to me, with the
suggestion that I might want to comment.  Phill said:

>...
>There are alternative porposals on the table, notably the FSTC 'SDML'
>proposal and W3C's DigSig project. I suspect however that it is easier
>to promote PKCS#7/CMS since the tools already exist and the PKIX
>integration has been considered to some extent already.
>
>It is not just the question of duplicating code. The W3C plan had the
>curious idea that building on the PICS censorware base made more
>sense than building on ASN.1. this would be fine if there was not a
>large quantity of extant ASN.1 OIDS to which semantics are already
>bound.
>

The present DSig 1.0 Proposed Recommendation from W3C does, indeed, only
apply to PICS.  However we view this as just a first step to developing a
more general "signed assertion" system.  Our plan is to move on to a system
based on XML and RDF (our XML-based metadata framework).  In the Web, XML
is the syntax of choice for most all new applications.  We plan to propose
such a project in the near future.

Alan
(Acting Leader, W3C Technology and Society Domain)

___________________________________________________________________________
Alan Kotok, Associate Chairman                          mailto:[email-masked]
World Wide Web Consortium                                 http://www.w3.org
MIT Laboratory for Computer Science,  545 Technology Square,  Room NE43-409
Cambridge, MA 02139, USA     Voice: +1-617-258-5728    Fax: +1-617-258-5999

Date: Wed, 06 May 1998 11:13:25 -0700
From: Slava Galperin <[email-masked]>
Organization: Teknowledge Corporation
To: [email-masked]
CC: [email-masked]
Subject: Re: OCSP status tally
Sender: [email-masked]

Denis Pinkas wrote:
> 
> Slava,
> 
> It may happen that an OCSP responder is in charge of multiple CAs.

Proposed scheme does not preclude supporting this case.

> Without that name, you would *mandate* the use an internal index that
> will have to be the hash of the issuer public key.

Agreed. Note however, that *with the name* we will *mandate* using the
name as an internal index ;-)

> 
> This would work fine, but would mandate an implementation design. Is it
> really needed to save a few bits and thus to omit to advertise the name
> of the issuer ?

My intent was not to save on the size(although if it is possible to fit
OCSP request(and response) for the *entire* certificate chain inside a
single packet it would be real help in reducing network overhead
considering high expected number of OCSP transactions. If one dealing
with relatively long cert chains (4-5)(e.g. in cross-certification
scenarios) then using names can really reach packet fragmentation
threshold (e.g. Verisign uses about 80 bytes for the issuer name, Thawte
is about 130)). My intent was to point out that
1. instead of identifying CA by a SET of names with relatively complex
matching rules and theoretical possibility of (malitiously created ?)
name clashes we may be better off with identifying CA by a SET of public
keys with straightforward matching rule and negligible chance of
collision

2. Name part in the cert id triple (Name,KeyHash,SerialNumber) (which
most of people agree with) is somewhat redundant.

> 
> I would prefer to let the choice of the implememtation to the
> implementors.
> 

Totally agree.

Let the group collective wisdom be the judge of what works best. I was
just trying to make sure that we evaluated all the possibilities and
implications carefully.

--
Slava

From: WHenry <[email-masked]>
To: "'Todd S. Glassey'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Standards for Digitally Signed Documents - This is where time stamping shines!
Date: Wed, 6 May 1998 13:08:51 -0400 
Sender: [email-masked]

 Todd,

 Agreed! This is a big issue, especially if one were going to use digitally
signed documents in a court of law.  I can see the O.J. DNA defusion defense
at work, unless a trusted time stamp is part of the document signing
process.

 Bill Henry
 Performance Engineering Corporation
 3949 Pender Drive
 Fairfax, VA  22030
 http://www.pec.com

> -----Original Message-----
> From:	Todd S. Glassey [SMTP:[email-masked]]
> Sent:	Wednesday, May 06, 1998 12:51 PM
> To:	[email-masked]
> Cc:	Rich Ankney; WHenry
> Subject:	Re: Standards for Digitally Signed Documents - This is where
> timestamping shines!
> 
> There is a bigger picture at work here and its about making digital
> documents as robust as paper based ones. This is composed of critical
> issues
> like storage live - validity life - and non-repudiated state management of
> the documents in question. When these questions are answered we can then
> resolve the legal issues and get on with document based EC systems.
> 
> With that in mind - IMHO - the key to this process is certifiable time and
> credible time data being inextricable bound into the process and context
> models that represent the methodologies. This, the inclusion of
> certifiable
> time data, is especially critical since today NO digital instrument can be
> built that claims to be the "one and only original instance" of a digital
> instrument. Unlike the paper based process where you have a Notary Seal
> embossing the paper to create the "instrument' there is no way to tell
> which
> copy of the certificate or the record structure was actually created
> first.
> 
> Simply put, until we can do electron spin and backspin mapping for a
> signature or some other physical method of finding which instance is which
> we, will have to settle for strong authentication, policy control,  and
> notary/document storage systems.
> 
> With this in mind the current document systems are really just built
> around
> authentication of the participants and the hash created. This in and of
> itself is a important step but without the context of certified time, it
> makes the document floating in a policy context anchored to little proofs.
> Bluntly,  without Certified Time it makes the the documents of limited use
> in the commercial world.
> 
> As to the S/MIME extensions in CMS and how they relate to the document
> management features, they like virtually all the standards that have been
> proffered to date do not take into account where the time data actually
> comes from and I think that as a group we need to address this.
> 
> 
> Todd
> 
> 
> -----Original Message-----
> From: Rich Ankney <[email-masked]>
> To: WHenry <[email-masked]>; [email-masked]' <[email-masked]>
> Date: Tuesday, May 05, 1998 12:19 PM
> Subject: Re: Standards for Digitally Signed Documents
> 
> 
> >I've also been fond of PKCS #7 (IETF CMS) to store signed documents.
> >This is basically S/MIME without the MIME headers and (possibly)
> >base64 encoding.  Note that CMS allows one to store the signature
> >structure (SignedData) separately from the content.
> >
> >I know of a couple of medical records standards that use this approach.
> >
> >Regards,
> >Rich
> >----------
> >> From: WHenry <[email-masked]>
> >> To: [email-masked]'
> >> Subject: Standards for Digitally Signed Documents
> >> Date: Tuesday, May 05, 1998 1:43 PM
> >>
> >>  I hope this isn't out of the context of PKIX, but I'll ask anyway. Is
> >there
> >> an IETF WG or other that is handling standards for digitally signed
> >> documents?
> >>
> >>  There is an email/message transfer (i.e. S/MIME) standard, but there
> >don't
> >> appear to be any similar standards for storage of digitally signed
> >> documents.
> >>
> >>  I see three options:
> >>  1) use a proprietary format (e.g. Entrust or Verisign) for storing
> >> documents; in which case all who need access to the documents require
> the
> >> same public key infrastructure.
> >>  2) actually store a signed document in S/MIME format.
> >>  3) create middleware/proprietary option(s) for appending digital
> >signatures
> >> to the likes of .doc or .ppt documents.
> >>
> >>  I'd greatly appreciate any comments or thoughts on the above.
> >>
> >>  Bill Henry
> >>  Performance Engineering Corporation
> >>  3949 Pender Drive
> >>  Farifax, VA  22030
> >>  [email-masked]
> >>
> >
> >

From: "Todd S. Glassey" <[email-masked]>
To: <[email-masked]>
Cc: "Rich Ankney" <[email-masked]>, "WHenry" <[email-masked]>
Subject: Re: Standards for Digitally Signed Documents - This is where timestamping shines!
Date: Wed, 6 May 1998 09:51:00 -0700
Sender: [email-masked]

There is a bigger picture at work here and its about making digital
documents as robust as paper based ones. This is composed of critical issues
like storage live - validity life - and non-repudiated state management of
the documents in question. When these questions are answered we can then
resolve the legal issues and get on with document based EC systems.

With that in mind - IMHO - the key to this process is certifiable time and
credible time data being inextricable bound into the process and context
models that represent the methodologies. This, the inclusion of certifiable
time data, is especially critical since today NO digital instrument can be
built that claims to be the "one and only original instance" of a digital
instrument. Unlike the paper based process where you have a Notary Seal
embossing the paper to create the "instrument' there is no way to tell which
copy of the certificate or the record structure was actually created first.

Simply put, until we can do electron spin and backspin mapping for a
signature or some other physical method of finding which instance is which
we, will have to settle for strong authentication, policy control,  and
notary/document storage systems.

With this in mind the current document systems are really just built around
authentication of the participants and the hash created. This in and of
itself is a important step but without the context of certified time, it
makes the document floating in a policy context anchored to little proofs.
Bluntly,  without Certified Time it makes the the documents of limited use
in the commercial world.

As to the S/MIME extensions in CMS and how they relate to the document
management features, they like virtually all the standards that have been
proffered to date do not take into account where the time data actually
comes from and I think that as a group we need to address this.

Todd

-----Original Message-----
From: Rich Ankney <[email-masked]>
To: WHenry <[email-masked]>; [email-masked]' <[email-masked]>
Date: Tuesday, May 05, 1998 12:19 PM
Subject: Re: Standards for Digitally Signed Documents

>I've also been fond of PKCS #7 (IETF CMS) to store signed documents.
>This is basically S/MIME without the MIME headers and (possibly)
>base64 encoding.  Note that CMS allows one to store the signature
>structure (SignedData) separately from the content.
>
>I know of a couple of medical records standards that use this approach.
>
>Regards,
>Rich
>----------
>> From: WHenry <[email-masked]>
>> To: [email-masked]'
>> Subject: Standards for Digitally Signed Documents
>> Date: Tuesday, May 05, 1998 1:43 PM
>>
>>  I hope this isn't out of the context of PKIX, but I'll ask anyway. Is
>there
>> an IETF WG or other that is handling standards for digitally signed
>> documents?
>>
>>  There is an email/message transfer (i.e. S/MIME) standard, but there
>don't
>> appear to be any similar standards for storage of digitally signed
>> documents.
>>
>>  I see three options:
>>  1) use a proprietary format (e.g. Entrust or Verisign) for storing
>> documents; in which case all who need access to the documents require the
>> same public key infrastructure.
>>  2) actually store a signed document in S/MIME format.
>>  3) create middleware/proprietary option(s) for appending digital
>signatures
>> to the likes of .doc or .ppt documents.
>>
>>  I'd greatly appreciate any comments or thoughts on the above.
>>
>>  Bill Henry
>>  Performance Engineering Corporation
>>  3949 Pender Drive
>>  Farifax, VA  22030
>>  [email-masked]
>>
>
>

From: "Phillip M. Hallam-Baker" <[email-masked]>
To: "Miklos, Sue A." <[email-masked]>, <[email-masked]>, "'WHenry'" <[email-masked]>
Subject: Re: Standards for Digitally Signed Documents
Date: Wed, 6 May 1998 11:51:40 -0400
Sender: [email-masked]

>May I suggest that those interested put together the appropriate request
>for a BOF at the Chicago IETF?

I would see the first step to be setting up a mailing list. The purpose of
a BOF is mainly to devise a group charter and define some schedule
for deliverables with a view to being approved by the IESG.

While I see PKCS#7 aka CMS as being the principle vehicle the IETF
should consider as a basis for this work  there are certainly issues that
have to be considered.

There are alternative porposals on the table, notably the FSTC 'SDML'
proposal and W3C's DigSig project. I suspect however that it is easier
to promote PKCS#7/CMS since the tools already exist and the PKIX
integration has been considered to some extent already.

It is not just the question of duplicating code. The W3C plan had the
curious idea that building on the PICS censorware base made more
sense than building on ASN.1. this would be fine if there was not a
large quantity of extant ASN.1 OIDS to which semantics are already
bound.

Perhaps another useful work item for such a group would be defining
a URI form of an ASN.1 OID. e.g. OID label followed by the attribute
in Base64 - ASN1:1.23.345.23:;l2i3u490ur9340u34==

Such an OID form would provide a powerful means of importing
semantics attached to ASN.1 OIDs into HTML and XML documents.
It would also be useful to define an OID to import URI semantics.

I would see XML inside CMS as being a key technology to be addressed.
What separation of concerns is appropriate? What information should
be in the object sighed, what information should be in the signature
wrapper.

Also to be addressed are issues such as the semantics of such signatures.
If messages are to be passed from computer to computer it is important
that a signing unit be protected from being fooled into signing something
that has a different meaning in another context.

It would also be appropriate for such a group to look at the question of
revocation of document signatures. This is no less necessary than
the revocation of compromised key certificates. For example a company
might announce a tender in a document, once a bidder was approved
however it could well be convenient to revoke the tender document.
Similarly a company might well want the ability to recall documents which
were fradulently obtained.

A better example might be a bank which would want to revoke a
letter of credit because the party that requested it is bankrupt.

In summary I think there is plenty of usefull work such a group could
do which would build on the PKIX base and further refine the notions
of what it means to sign documents with public keys. While the
technology approach is at this stage relatively straightforward
there are a lot of details to work out.

Whether such a group could make a worthwhile contribution would
of course depend on its ability to obtain industry buy in.

            Phill

From: Graham Bland <[email-masked]>
Date: Wed, 6 May 1998 15:38:26 +0000
To: [email-masked]
Subject: RE: Standards for Digitally Signed Docum
Sender: [email-masked]

This could be considered within the context of an IDUP-GSS mechanism

Graham
 ----------
From: samiklo@missi=2Encsc=2Emil
To: ietf-pkix@imc=2Eorg; WHenry@pec=2Ecom
Subject: RE: Standards for Digitally Signed Docum
Date: Wednesday, 06 May, 1998 3:28PM

May I suggest that those interested put together the appropriate request
for a BOF at the Chicago IETF?

Sandi

>----------
>From:    WHenry[SMTP:WHenry@pec=2Ecom]
>Sent:    Tuesday, May 05, 1998 1:43 PM
>To:      'ietf-pkix@imc=2Eorg'
>Subject:      Standards for Digitally Signed Documents
>
> I hope this isn't out of the context of PKIX, but I'll ask anyway=2E Is=20
there
>an IETF WG or other that is handling standards for digitally signed
>documents?
>
> There is an email/message transfer (i=2Ee=2E S/MIME) standard, but there=20=
don't
>appear to be any similar standards for storage of digitally signed
>documents=2E
>
> I see three options:
> 1) use a proprietary format (e=2Eg=2E Entrust or Verisign) for storing
>documents; in which case all who need access to the documents require the
>same public key infrastructure=2E
> 2) actually store a signed document in S/MIME format=2E
> 3) create middleware/proprietary option(s) for appending digital=20
signatures
>to the likes of =2Edoc or =2Eppt documents=2E
>
> I'd greatly appreciate any comments or thoughts on the above=2E
>
> Bill Henry
> Performance Engineering Corporation
> 3949 Pender Drive
> Farifax, VA  22030
> whenry@pec=2Ecom
>
>
>
>> -----Original Message-----
>> From:  Miklos, Sue A=2E [SMTP:samiklo@missi=2Encsc=2Emil]
>> Sent:  Tuesday, May 05, 1998 9:30 AM
>> To:    'Blake Ramsdell'; 'Denis=2EPinkas@bull=2Enet'
>> Cc:    'ietf-pkix@imc=2Eorg'
>> Subject:    RE: Role names in certificates
>>
>> I'm somewhat confused=2E  I had thought that certificates and roles coul=
d
>> be used in a variety of contexts (applications) for, among other things,
>> access control=2E  Therefore this would appear to extend beyond just the
>> S/MIME messaging context=2E  Is this of interest to the LDAP access
>> controls?  Is this useful for the web-based document retrieval
>> environments?
>>
>> Sandi Miklos
>>
>>
>> >----------
>> >From:      Denis Pinkas[SMTP:Denis=2EPinkas@bull=2Enet]
>> >Sent:      Tuesday, May 05, 1998 5:49 PM
>> >To:   Blake Ramsdell
>> >Cc:   'ietf-pkix@imc=2Eorg'
>> >Subject:   Re: Role names in certificates
>> >
>> >> I have written a draft that I have submitted as an individual (not
>> under
>> >> IETF-PKIX)=2E  It describes a concept of using "role" names in
>> >> certificates for several purposes that are not covered with
>> conventional
>> >> PKIX certificates=2E
>> >
>> >I am not sure that this thread is relevant to the PKIX WG=2E It might b=
e
>> >more relevant to the S/MIME WG=2E
>> >
>> >> I have currently profiled the rfc822Name choice, but
>> >> I have heard that there is interesting in profiling the dNSName choic=
e
>> >> also=2E  Cutting and pasting a little bit from the document, roles ar=
e
>> >> defined for:
>> >>
>> >> * The need to sign messages on behalf of people at a domain that may=20
or
>> >> may not have signature services available at the desktop=2E An outbou=
nd
>> >> message from a domain may be sent that is signed at the domain mail
>> >> server=2E
>> >
>> >A requirement would be the need to sign a message as the Sales Director
>> >of the Delta Company, who may happen to be John Walker=2E However John
>> >Walker may not have a private key of its own=2E
>> >
>> >> * The need to encrypt messages for people at a domain that may not=20
have
>> >> encryption services available at the desktop=2E A message may be
>> encrypted
>> >> for the domain mail server using a domain encrypting certificate, and
>> >> that message will be decrypted before local delivery=2E
>> >
>> >For the other following cases related to encryption, I wonder why a rol=
e
>> >is needed=2E
>> >
>> >> * The need to encrypt messages between two mail transfer agents=20
(MTAs)=2E
>> >> This is different than a domain encrypting certificate, in that the
>> >> message is never encrypted or decrypted at the mail user agent (MUA)
>> >> level=2E
>> >>
>> >> * The need to encrypt messages for a keypair that is controlled by th=
e
>> >> domain administrator for the purposes of plaintext access=2E A messag=
e
>> may
>> >> be encrypted for the domain mail server using a domain message=20
recovery
>> >> encryption certificate for the purpose of selective plaintext recover=
y
>> >> by the domain administrator=2E This differs from a domain encrypting
>> >> certificate in that the message is not necessarily decrypted before
>> >> local delivery=2E
>> >>
>> >> I know that the last one is going to be controversial, and this is no=
t
>> >> an all-or-nothing proposal (you can simply not implement it)=2E  Plea=
se
>> >> don't flame me for daring to speak its evil name, but keep an open=20
mind
>> >> for the other uses I have listed=2E
>> >
>> >> This is meant to get the ball rolling in a direction where we think
>> >> about PKIX representing entities that are not necessarily a specific
>> >> end-entity, but an end-entity with a particular role or=20
responsibility=2E
>> >
>> >This is the point=2E
>> >
>> >> Any insight welcome as to how to address these issues in an=20
alternative
>> >> way=2E
>> >
>> >> http://www=2Edeming=2Ecom/users/blaker/draft-ramsdell-role-names is a=
lways
>> >> the latest version
>> >> http://www=2Eietf=2Eorg/internet-drafts/draft-ramsdell-role-names-00=2E=
txt=20
is
>> >> the current draft at the IETF=2E
>> >>
>> >> Now where's my suit=2E=2E=2E
>> >
>> >There are several ways to address this issue=2E Among them:
>> >
>> >1) a signature server (from a company) is able to sign documents on
>> >behalf of an employee with its own key and indicate the appropriate rol=
e
>> >used by the employee=2E The employee may authenticate to that signature
>> >server by whatever means=2E In that case the signer is the company whic=
h
>> >indicates the role of the employee=2E
>> >
>> >2) a temporary certificate issued by a server of a company includes a
>> >role and a temporary public key=2E The employee is given back the
>> >temporary private key so that it can sign documens directly using that
>> >private key=2E
>> >
>> >If we would like to support such scheme(s), some arrangements would nee=
d
>> >to be done to the S/MIME specifications, so I would propose to shift
>> >this thread to the S/MIME WG=2E
>> >
>> >Denis
>> >
>> >> Blake
>> >> --
>> >> Blake C=2E Ramsdell
>> >> Worldtalk Corporation
>> >> For current info, check http://www=2Edeming=2Ecom/users/blaker
>> >> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>> >
>> >--
>> >      Denis Pinkas     Bull S=2EA=2E          mailto:Denis=2EPinkas@bul=
l=2Enet
>> >      Rue Jean Jaures  B=2EP=2E 68            Phone : 33 - 1 30 80 34 8=
7
>> >      78340 Les Clayes sous Bois=2E FRANCE   Fax  : 33 - 1 30 80 33 21
>> >
>

--
Zergo Limited, The Square, Basing View, Basingstoke, Hants=2E RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www=2Ezergo=2Ecom

Date: Tue, 05 May 1998 11:18:03 -0400
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: John Lowry <[email-masked]>
Subject: Re: Role names in certificates
Sender: [email-masked]

Blake,

	Including a domain controller (either human or agent) is an old
	established concept (1988 ?) and it has value at several points in 
	the network.  One of the most interesting is at a firewall or other
	domain controller where one wants to control the inflow
	(and outflow !) of things like viruses and other nasties.
	Further, the entire intrusion detection community needs
	to consider this technique because the widespread use of IPSEC
	will effectively remove their ability to deploy sensors.  I know
	that this can imply the development of "multicast IPSEC", one key for the
	destination host and one for the FW, but that shouldn't stop
	PKIX from considering role-based certificates.

	Consequently, I encourage you to expand your concept to
	domain controllers at any layer, not just email or messaging.

Regards,

John

At 02:23 PM 5/4/98 -0700, Blake Ramsdell wrote:
>I have written a draft that I have submitted as an individual (not under
>IETF-PKIX).  It describes a concept of using "role" names in
>certificates for several purposes that are not covered with conventional
>PKIX certificates.  I have currently profiled the rfc822Name choice, but
>I have heard that there is interesting in profiling the dNSName choice
>also.  Cutting and pasting a little bit from the document, roles are
>defined for:
>
>* The need to sign messages on behalf of people at a domain that may or
>may not have signature services available at the desktop. An outbound
>message from a domain may be sent that is signed at the domain mail
>server.
>
>* The need to encrypt messages for people at a domain that may not have
>encryption services available at the desktop. A message may be encrypted
>for the domain mail server using a domain encrypting certificate, and
>that message will be decrypted before local delivery.
>
>* The need to encrypt messages between two mail transfer agents (MTAs).
>This is different than a domain encrypting certificate, in that the
>message is never encrypted or decrypted at the mail user agent (MUA)
>level.
>
>* The need to encrypt messages for a keypair that is controlled by the
>domain administrator for the purposes of plaintext access. A message may
>be encrypted for the domain mail server using a domain message recovery
>encryption certificate for the purpose of selective plaintext recovery
>by the domain administrator. This differs from a domain encrypting
>certificate in that the message is not necessarily decrypted before
>local delivery.
>
>I know that the last one is going to be controversial, and this is not
>an all-or-nothing proposal (you can simply not implement it).  Please
>don't flame me for daring to speak its evil name, but keep an open mind
>for the other uses I have listed.
>
>This is meant to get the ball rolling in a direction where we think
>about PKIX representing entities that are not necessarily a specific
>end-entity, but an end-entity with a particular role or responsibility.
>Any insight welcome as to how to address these issues in an alternative
>way.
>
>http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
>the latest version
>http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
>the current draft at the IETF.
>
>Now where's my suit...
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

From: "Miklos, Sue A." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'WHenry'" <[email-masked]>
Subject: RE: Standards for Digitally Signed Documents
Date: Wed, 6 May 1998 08:39:58 -0400
Sender: [email-masked]

May I suggest that those interested put together the appropriate request
for a BOF at the Chicago IETF?  

Sandi

>----------
>From: 	WHenry[SMTP:[email-masked]]
>Sent: 	Tuesday, May 05, 1998 1:43 PM
>To: 	[email-masked]'
>Subject: 	Standards for Digitally Signed Documents
>
> I hope this isn't out of the context of PKIX, but I'll ask anyway. Is there
>an IETF WG or other that is handling standards for digitally signed
>documents?
>
> There is an email/message transfer (i.e. S/MIME) standard, but there don't
>appear to be any similar standards for storage of digitally signed
>documents.
>
> I see three options:
> 1) use a proprietary format (e.g. Entrust or Verisign) for storing
>documents; in which case all who need access to the documents require the
>same public key infrastructure.
> 2) actually store a signed document in S/MIME format.
> 3) create middleware/proprietary option(s) for appending digital signatures
>to the likes of .doc or .ppt documents.
>
> I'd greatly appreciate any comments or thoughts on the above.
>
> Bill Henry
> Performance Engineering Corporation
> 3949 Pender Drive
> Farifax, VA  22030
> [email-masked]
>
> 
>
>> -----Original Message-----
>> From:	Miklos, Sue A. [SMTP:[email-masked]]
>> Sent:	Tuesday, May 05, 1998 9:30 AM
>> To:	'Blake Ramsdell'; [email-masked]'
>> Cc:	[email-masked]'
>> Subject:	RE: Role names in certificates
>> 
>> I'm somewhat confused.  I had thought that certificates and roles could
>> be used in a variety of contexts (applications) for, among other things,
>> access control.  Therefore this would appear to extend beyond just the
>> S/MIME messaging context.  Is this of interest to the LDAP access
>> controls?  Is this useful for the web-based document retrieval
>> environments?  
>> 
>> Sandi Miklos
>> 
>> 
>> >----------
>> >From: 	Denis Pinkas[SMTP:[email-masked]]
>> >Sent: 	Tuesday, May 05, 1998 5:49 PM
>> >To: 	Blake Ramsdell
>> >Cc: 	[email-masked]'
>> >Subject: 	Re: Role names in certificates
>> >
>> >> I have written a draft that I have submitted as an individual (not
>> under
>> >> IETF-PKIX).  It describes a concept of using "role" names in
>> >> certificates for several purposes that are not covered with
>> conventional
>> >> PKIX certificates.  
>> >
>> >I am not sure that this thread is relevant to the PKIX WG. It might be
>> >more relevant to the S/MIME WG.
>> >
>> >> I have currently profiled the rfc822Name choice, but
>> >> I have heard that there is interesting in profiling the dNSName choice
>> >> also.  Cutting and pasting a little bit from the document, roles are
>> >> defined for:
>> >> 
>> >> * The need to sign messages on behalf of people at a domain that may or
>> >> may not have signature services available at the desktop. An outbound
>> >> message from a domain may be sent that is signed at the domain mail
>> >> server.
>> >
>> >A requirement would be the need to sign a message as the Sales Director
>> >of the Delta Company, who may happen to be John Walker. However John
>> >Walker may not have a private key of its own.
>> > 
>> >> * The need to encrypt messages for people at a domain that may not have
>> >> encryption services available at the desktop. A message may be
>> encrypted
>> >> for the domain mail server using a domain encrypting certificate, and
>> >> that message will be decrypted before local delivery.
>> >
>> >For the other following cases related to encryption, I wonder why a role
>> >is needed.
>> > 
>> >> * The need to encrypt messages between two mail transfer agents (MTAs).
>> >> This is different than a domain encrypting certificate, in that the
>> >> message is never encrypted or decrypted at the mail user agent (MUA)
>> >> level.
>> >> 
>> >> * The need to encrypt messages for a keypair that is controlled by the
>> >> domain administrator for the purposes of plaintext access. A message
>> may
>> >> be encrypted for the domain mail server using a domain message recovery
>> >> encryption certificate for the purpose of selective plaintext recovery
>> >> by the domain administrator. This differs from a domain encrypting
>> >> certificate in that the message is not necessarily decrypted before
>> >> local delivery.
>> >> 
>> >> I know that the last one is going to be controversial, and this is not
>> >> an all-or-nothing proposal (you can simply not implement it).  Please
>> >> don't flame me for daring to speak its evil name, but keep an open mind
>> >> for the other uses I have listed.
>> >
>> >> This is meant to get the ball rolling in a direction where we think
>> >> about PKIX representing entities that are not necessarily a specific
>> >> end-entity, but an end-entity with a particular role or responsibility.
>> >
>> >This is the point.
>> >
>> >> Any insight welcome as to how to address these issues in an alternative
>> >> way.
>> > 
>> >> http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
>> >> the latest version
>> >> http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
>> >> the current draft at the IETF.
>> >> 
>> >> Now where's my suit...
>> >
>> >There are several ways to address this issue. Among them: 
>> >
>> >1) a signature server (from a company) is able to sign documents on
>> >behalf of an employee with its own key and indicate the appropriate role
>> >used by the employee. The employee may authenticate to that signature
>> >server by whatever means. In that case the signer is the company which
>> >indicates the role of the employee.
>> >
>> >2) a temporary certificate issued by a server of a company includes a
>> >role and a temporary public key. The employee is given back the
>> >temporary private key so that it can sign documens directly using that
>> >private key.
>> >
>> >If we would like to support such scheme(s), some arrangements would need
>> >to be done to the S/MIME specifications, so I would propose to shift
>> >this thread to the S/MIME WG.
>> >
>> >Denis
>> > 
>> >> Blake
>> >> --
>> >> Blake C. Ramsdell
>> >> Worldtalk Corporation
>> >> For current info, check http://www.deming.com/users/blaker
>> >> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>> >
>> >-- 
>> >      Denis Pinkas     Bull S.A.          mailto:[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: Mon, 4 May 1998 18:28:39 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Cc: [email-masked]
Sender: [email-masked]

Peter,

>Subject field should contain anything you want. It is questionable
>whether one should impose any restriction on subjects. The CA
>(or the associated RA or naming authority) publishes its naming
>plan anyway (or should plan it), otherwise it would be somewhat
>difficult to interprete the content of the subject naming fields.
>All X.509v3 should be allowed (not necessarily new extensions
>with almost private oids)
>
>A CA can decide to use DN or other naming extension
>in whatever weird way as long as internal the names are ok and
>permit (to them) to find the individual etc, and to issue new
>certs for the same individual.
>
>Restrictions of issuer names and subject names may be the only
>way to organise a conspiracy of cooperating CAs, in whatever
>cross-certification environment you might imagine. Are we (who
>ever this might be?) in this context?

We want interoperability in general, although closed PKIs certainly shoulkd
be accommodated too.  We have a variety of name forms defined and certs
have to match one of those, so it's not a completely general space we're
dealing with.  My comments focus on representing names that already exist
in the Internet. Names for which we have authorutative registrars, and for
which we have a defined, native representation in X.509v3.  Yes,
cross-certification is a motivation for adopting appropriate conventions
for name use.

>The problem is not really the naming in the certs,
>the problem are applications (IMHO). It seems that one tries
>to solve a hen and egg problem by first creating a global
>unique naming structure for everything and everybody (big brother,
>please leave me alone that), and then of course this automagically
>solves many addressing and naming problems in applications,
>finding CAs, subjects and so on.

For the names in question, e.g., DNS names and IP addresses, we already DO
have global, unique name structures and folks who administer them.

>Reality might be different: the banking environment gives me a cert,
>THEY choose their naming convention, the administration who wants
>me to sign tax declarations will give me a cert. THEY choose THEIR
>naming convention, my electronic passport cert (bar or ocr coded
>on a real passport :-) ) again has its own naming conventions.

The SET standards already define conevntions for the X.509 certs issued to
credit card folks, and for U.S. taxpayers, the social security numbner
(combined with a CN) is the name form.  So, we already have answers for two
examples you cite.  I bet someone, somewhere in the EC is working on the
passport issue as we speak ;-)!

Steve

Date: Mon, 4 May 1998 18:20:33 -0400
To: [email-masked] (David P. Kemp)
From: Stephen Kent <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Cc: [email-masked]
Sender: [email-masked]

David,

>
>The question in my mind remains "can X.509 be used outside the context
>of the X.500 directory?".  Or, does the IETF, which defines the syntax
>of Name, RDNSequence, and RelativeDistinguishedName in PKIX Part 1,
>somehow have a sub-rosa importation of the semantics of Directory
>(or Distinguished) Names from X.500, including a requirement to use
>the ITU as a registrar?
>
>Note that Part 1 defines DistinguishedName ::= RDNSequence,
>but DistinguishedName is *never* used.  The subject and issuer
>fields of Certificate are Name, not DistinguishedName.  The syntax
>is the same, but the argument can be made that the IETF has the right
>to define its own attributes which may appear in RDNSequence, and
>to serve as the registrar for it's own namespaces.

For backward compatibility with v1 and v2 certs, Name is a DN, imported
from X.500 (even if we don't say so explicitly in the text).  Otherwise we
would substitute GeneralName and not have AltNames.  Since ITU is not
acting as a registrar, your comment above does not seem germane to our
discussion.

>I would put forth the claim that a Name which began with "C=" would be
>registered under the ITU, a Name which began with "DC=" would be
>registered under the IETF, and a Name which began with a private
>attribute "FOO=" would be registered under the organization which owns
>the attribute's OID.

Well, it's not that easy, though I appreciate your point.  A name that
begins with O (organizatoion) is also consistent with the X.500 DIT model,
e.g., for the United Nations, the ICRC, etc.  The notion that the first RDN
defines a name space is definately not consistent with the X.500 model,
although I appreciate the apparent attraction.  After all, ifthey
envisioned that approach, why define AltNames?

Also, in practice, folks have used a wide variety of DNs in certs, in part
because we have no formal, binding schema, as I noted previously.  Still, I
could interpret your suggestion to be that if a DN consisted of all DC
attributes (and matching values), then there would be no ambiguity and one
could establish a convention in the IETF sphere of influence to consider
such DNs as equivalent to an AltName of the DNS form, right?

Well, I guess one might pursue that path.  Is the major benefit of having
these DNS names in sheeps (I mean DN) clothing, to facilitate lookup in
LDAP servers?  Given the availability of AltNames, we don't want to
encourage this hack as an alternative to use of those constructs.  Also, we
will now find ourselves with two supposedly equivalent ways of representing
the same name, which would further complicate the matching problems we've
already been discussing just due to the various string representations in
DNs.  Also, this approach doesn't address what I assume is the major legacy
problem we are facing now.  Many of the legacy examples we see are hybrid
names that look like DNs, but just happen to end with a CN that is a DNS
name (c.f. ALL SSL server certificate Subject names).

So, before considering your suggestionn further, I'd like to see a more
complete analysis of what problems we are solving and what new problems we
are creating, to better understand the tradeoffs.

Steve

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Usage of Diffe-Hellman keys
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Date: Wed, 6 May 1998 16:20:37 (NZST)
Sender: [email-masked]

>Trying to put this into S/MIME context it seems that Diffie-Hellman keys may
>only be used in the way suggested by Russ Housley, i.e. for each recipient to
>take recipient's Diffie-Hellman certificate (key agreement certificate), get
>the public key from there, generate a shared key (Russ suggested 3DES) and use
>it to encrypt the content-encryption key.
>
>However, another possibility is to use El-Gamal algorithm with Diffie-Hellman
>keys and encrypt the content-encryption key directly with recipients
>Diffie-Hellman public key. This would be a very similar operation as if the
>recipient had RSA keys and keyEnchipherment certificate. This seems to be a
>much better way of using Diffie-Hellman keys, similar to the way RSA keys are
>used for keys encryption (unless I have missed some point here).
 
If you use the key this way then it's no longer DH but Elgamal, with its own 
algorithm/object identifiers and usage requirements.  For example some 
generators which are OK for Elgamal encryption aren't secure for Elgamal 
signatures, so if you've got DH-pretending-to-be-Elgamal (which PGP does, for 
example) you can't just use it as if it were Elgamal.  If you want to use a 
key for Elgamal encryption/signatures, you should really call it Elgamal, and 
not take a DH key and use it for something it was never designed for.
 
(If you want to get really nitpicky, there are actually three different 
 algorithms which use keys which look more or less the same: DH (key 
 exchange), Elgamal encryption == DH-Vernam encryption (encryption), and 
 Elgamal signatures (signature).  It'd be nicer to actually call it Elgamal
 rather than overload DH further and further)
 
Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Cc: [email-masked]
Reply-To: [email-masked]
Date: Wed, 6 May 1998 16:12:53 (NZST)
Sender: [email-masked]

>RFC2247 names are perfectly valid X.500 names, and as there are no 
>restrictions on the attribute types used within Name objects in the PKIX-1 
>spec, there should be no problem with putting them into the Subject or Issuer 
>fields of PKIX certificates.  But I agree that it would be good if the PKIX 
>documents were to explicitly recommend the use of the RFC2247 'DC' attribute 
>type to represent names from the DNS namespace, for situations where a key is 
>owned by some entity identified by a DNS name.  This might prevent someone 
>from inventing a different way to represent DNS names.
 
As several others have already pointed out, there's already a perfectly valid 
way of specifying a DNS name to identify a certificate, namely the dNSName 
component of the altName.  Why the insistence on stuffing DNS names into 
something which was never intended for this purpose?  There's no need to 
invent anything new, or misuse an existing mechanism, because DNS names are 
already handled.
 
Peter.

From: Trevor Freeman <[email-masked]>
To: [email-masked]
Subject: RE: [IETF-PKIX] OCSP: Method of Identifying Certificates
Date: Tue, 5 May 1998 17:23:02 -0700 
Sender: [email-masked]

Steve,
I see little to justify exclusion of RFC2247 names in your comments. This is
not a turf war of who's name space is it. What does it matter who "owns" the
name space. What matters is do we want to use RFC2247 to generate RDN's for
pkix. It sound to me if a number of people see value in doing so.
Trevor

From: =?ISO-8859-1?Q?H=E4ger=F6=2C_Per?= <[email-masked]>
To: "'WHenry'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: SV: Standards for Digitally Signed Documents
Date: Tue, 5 May 1998 23:28:42 +0200 
Sender: [email-masked]

Hi !

I=B4d say that PKCS7 is what your looking for.

-------------------------------------------
Med V=E4nlig H=E4lsning / Best Regards
Per H=E4ger=F6
Senior Consultant & Product Manager
WM-data
Tel +46 8 7758204 | Fax +46 8 7758322=20
E-post: [email-masked]
------------------------------------------------------------------------=
----
---

> -----Ursprungligt meddelande-----
> Fr=E5n:	WHenry [SMTP:[email-masked]]
> Skickat:	 den 5 maj 1998 19:44
> Till:	[email-masked]'
> =C4mne:	Standards for Digitally Signed Documents
>=20
>  I hope this isn't out of the context of PKIX, but I'll ask anyway. =
Is
> there
> an IETF WG or other that is handling standards for digitally signed
> documents?
>=20
>  There is an email/message transfer (i.e. S/MIME) standard, but there
> don't
> appear to be any similar standards for storage of digitally signed
> documents.
>=20
>  I see three options:
>  1) use a proprietary format (e.g. Entrust or Verisign) for storing
> documents; in which case all who need access to the documents require =
the
> same public key infrastructure.
>  2) actually store a signed document in S/MIME format.
>  3) create middleware/proprietary option(s) for appending digital
> signatures
> to the likes of .doc or .ppt documents.
>=20
>  I'd greatly appreciate any comments or thoughts on the above.
>=20
>  Bill Henry
>  Performance Engineering Corporation
>  3949 Pender Drive
>  Farifax, VA  22030
>  [email-masked]
>=20
> =20
>=20
> > -----Original Message-----
> > From:	Miklos, Sue A. [SMTP:[email-masked]]
> > Sent:	Tuesday, May 05, 1998 9:30 AM
> > To:	'Blake Ramsdell'; [email-masked]'
> > Cc:	[email-masked]'
> > Subject:	RE: Role names in certificates
> >=20
> > I'm somewhat confused.  I had thought that certificates and roles =
could
> > be used in a variety of contexts (applications) for, among other =
things,
> > access control.  Therefore this would appear to extend beyond just =
the
> > S/MIME messaging context.  Is this of interest to the LDAP access
> > controls?  Is this useful for the web-based document retrieval
> > environments? =20
> >=20
> > Sandi Miklos
> >=20
> >=20
> > >----------
> > >From: 	Denis Pinkas[SMTP:[email-masked]]
> > >Sent: 	Tuesday, May 05, 1998 5:49 PM
> > >To: 	Blake Ramsdell
> > >Cc: 	[email-masked]'
> > >Subject: 	Re: Role names in certificates
> > >
> > >> I have written a draft that I have submitted as an individual =
(not
> > under
> > >> IETF-PKIX).  It describes a concept of using "role" names in
> > >> certificates for several purposes that are not covered with
> > conventional
> > >> PKIX certificates. =20
> > >
> > >I am not sure that this thread is relevant to the PKIX WG. It =
might be
> > >more relevant to the S/MIME WG.
> > >
> > >> I have currently profiled the rfc822Name choice, but
> > >> I have heard that there is interesting in profiling the dNSName
> choice
> > >> also.  Cutting and pasting a little bit from the document, roles =
are
> > >> defined for:
> > >>=20
> > >> * The need to sign messages on behalf of people at a domain that =
may
> or
> > >> may not have signature services available at the desktop. An =
outbound
> > >> message from a domain may be sent that is signed at the domain =
mail
> > >> server.
> > >
> > >A requirement would be the need to sign a message as the Sales =
Director
> > >of the Delta Company, who may happen to be John Walker. However =
John
> > >Walker may not have a private key of its own.
> > >=20
> > >> * The need to encrypt messages for people at a domain that may =
not
> have
> > >> encryption services available at the desktop. A message may be
> > encrypted
> > >> for the domain mail server using a domain encrypting =
certificate, and
> > >> that message will be decrypted before local delivery.
> > >
> > >For the other following cases related to encryption, I wonder why =
a
> role
> > >is needed.
> > >=20
> > >> * The need to encrypt messages between two mail transfer agents
> (MTAs).
> > >> This is different than a domain encrypting certificate, in that =
the
> > >> message is never encrypted or decrypted at the mail user agent =
(MUA)
> > >> level.
> > >>=20
> > >> * The need to encrypt messages for a keypair that is controlled =
by
> the
> > >> domain administrator for the purposes of plaintext access. A =
message
> > may
> > >> be encrypted for the domain mail server using a domain message
> recovery
> > >> encryption certificate for the purpose of selective plaintext
> recovery
> > >> by the domain administrator. This differs from a domain =
encrypting
> > >> certificate in that the message is not necessarily decrypted =
before
> > >> local delivery.
> > >>=20
> > >> I know that the last one is going to be controversial, and this =
is
> not
> > >> an all-or-nothing proposal (you can simply not implement it).  =
Please
> > >> don't flame me for daring to speak its evil name, but keep an =
open
> mind
> > >> for the other uses I have listed.
> > >
> > >> This is meant to get the ball rolling in a direction where we =
think
> > >> about PKIX representing entities that are not necessarily a =
specific
> > >> end-entity, but an end-entity with a particular role or
> responsibility.
> > >
> > >This is the point.
> > >
> > >> Any insight welcome as to how to address these issues in an
> alternative
> > >> way.
> > >=20
> > >> http://www.deming.com/users/blaker/draft-ramsdell-role-names is
> always
> > >> the latest version
> > >> =
http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt
> is
> > >> the current draft at the IETF.
> > >>=20
> > >> Now where's my suit...
> > >
> > >There are several ways to address this issue. Among them:=20
> > >
> > >1) a signature server (from a company) is able to sign documents =
on
> > >behalf of an employee with its own key and indicate the =
appropriate
> role
> > >used by the employee. The employee may authenticate to that =
signature
> > >server by whatever means. In that case the signer is the company =
which
> > >indicates the role of the employee.
> > >
> > >2) a temporary certificate issued by a server of a company =
includes a
> > >role and a temporary public key. The employee is given back the
> > >temporary private key so that it can sign documens directly using =
that
> > >private key.
> > >
> > >If we would like to support such scheme(s), some arrangements =
would
> need
> > >to be done to the S/MIME specifications, so I would propose to =
shift
> > >this thread to the S/MIME WG.
> > >
> > >Denis
> > >=20
> > >> Blake
> > >> --
> > >> Blake C. Ramsdell
> > >> Worldtalk Corporation
> > >> For current info, check http://www.deming.com/users/blaker
> > >> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
> > >
> > >--=20
> > >      Denis Pinkas     Bull S.A.          =
mailto:[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
> > >

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "WHenry" <[email-masked]>, <[email-masked]>
Subject: Re: Standards for Digitally Signed Documents
Date: Tue, 5 May 1998 16:48:57 -0400
Sender: [email-masked]

> I see three options:
> 1) use a proprietary format (e.g. Entrust or Verisign) for storing
>documents; in which case all who need access to the documents require the
>same public key infrastructure.

I'm not aware of any proprietary VeriSign document storage format.
I strongly approve of the idea of using PKCS#7 aka CMS for this
purpose however.

The detached signature block technique is particularly powerful
in combination with S/MIME. An S/MIME message might be
placed in a document repository with the content placed in one
vault and the signature in another. If necessary the S/MIME 
message can always be reassembled.

        Phill

Date: Tue, 05 May 1998 22:22:12 +0200
To: WHenry <[email-masked]>, "[email-masked]'" <[email-masked]>
From: "Patrik Nilsson" <[email-masked]>
Subject: Re: Standards for Digitally Signed Documents
Sender: [email-masked]

At 01:43 PM 98-05-05 -0400, WHenry wrote:
> I hope this isn't out of the context of PKIX, but I'll ask anyway. Is there
>an IETF WG or other that is handling standards for digitally signed
>documents?
>
> There is an email/message transfer (i.e. S/MIME) standard, but there don't
>appear to be any similar standards for storage of digitally signed
>documents.
>
> I see three options:
> 1) use a proprietary format (e.g. Entrust or Verisign) for storing
>documents; in which case all who need access to the documents require the
>same public key infrastructure.
> 2) actually store a signed document in S/MIME format.
> 3) create middleware/proprietary option(s) for appending digital signatures
>to the likes of .doc or .ppt documents.
>
> I'd greatly appreciate any comments or thoughts on the above.

I think that separating Cryptographic Message Syntax (CMS) into a separate
document, independent of the email specific parts of the S/MIME standards,
was an effort to address these kind of needs.

>From ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-04.txt
- - - - - - - - - - - - 
1  Introduction

   This document describes the Cryptographic Message Syntax.  This
   syntax is used to digitally sign or encrypt arbitrary messages.

   The Cryptographic Message Syntax describes an encapsulation syntax
   for data protection.  It supports digital signatures and encryption.
   The syntax allows multiple encapsulation, so one encapsulation
   envelope can be nested inside another.  Likewise, one party can
   digitally sign some previously encapsulated data.  It also allows
   arbitrary attributes, such as signing time, to be authenticated along
   with the message content, and provides for other attributes such as
   countersignatures to be associated with a signature.

   The Cryptographic Message Syntax can support a variety of
   architectures for certificate-based key management, such as the one
   defined by the PKIX working group.
- - - - - - - - - - - - 

Patrik
---------------------------------------------------------------------
Patrik Nilsson     |    [email-masked]    |     +46 (0)708 452 859
---------------------------------------------------------------------

From: "Rich Ankney" <[email-masked]>
To: "WHenry" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Standards for Digitally Signed Documents
Date: Tue, 5 May 1998 15:25:24 -0400
Sender: [email-masked]

I've also been fond of PKCS #7 (IETF CMS) to store signed documents.
This is basically S/MIME without the MIME headers and (possibly)
base64 encoding.  Note that CMS allows one to store the signature
structure (SignedData) separately from the content.

I know of a couple of medical records standards that use this approach.

Regards,
Rich
----------
> From: WHenry <[email-masked]>
> To: [email-masked]'
> Subject: Standards for Digitally Signed Documents
> Date: Tuesday, May 05, 1998 1:43 PM
> 
>  I hope this isn't out of the context of PKIX, but I'll ask anyway. Is
there
> an IETF WG or other that is handling standards for digitally signed
> documents?
> 
>  There is an email/message transfer (i.e. S/MIME) standard, but there
don't
> appear to be any similar standards for storage of digitally signed
> documents.
> 
>  I see three options:
>  1) use a proprietary format (e.g. Entrust or Verisign) for storing
> documents; in which case all who need access to the documents require the
> same public key infrastructure.
>  2) actually store a signed document in S/MIME format.
>  3) create middleware/proprietary option(s) for appending digital
signatures
> to the likes of .doc or .ppt documents.
> 
>  I'd greatly appreciate any comments or thoughts on the above.
> 
>  Bill Henry
>  Performance Engineering Corporation
>  3949 Pender Drive
>  Farifax, VA  22030
>  [email-masked]
> 

From: WHenry <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Standards for Digitally Signed Documents
Date: Tue, 5 May 1998 13:43:32 -0400 
Sender: [email-masked]

 I hope this isn't out of the context of PKIX, but I'll ask anyway. Is there
an IETF WG or other that is handling standards for digitally signed
documents?

 There is an email/message transfer (i.e. S/MIME) standard, but there don't
appear to be any similar standards for storage of digitally signed
documents.

 I see three options:
 1) use a proprietary format (e.g. Entrust or Verisign) for storing
documents; in which case all who need access to the documents require the
same public key infrastructure.
 2) actually store a signed document in S/MIME format.
 3) create middleware/proprietary option(s) for appending digital signatures
to the likes of .doc or .ppt documents.

 I'd greatly appreciate any comments or thoughts on the above.

 Bill Henry
 Performance Engineering Corporation
 3949 Pender Drive
 Farifax, VA  22030
 [email-masked]

> -----Original Message-----
> From:	Miklos, Sue A. [SMTP:[email-masked]]
> Sent:	Tuesday, May 05, 1998 9:30 AM
> To:	'Blake Ramsdell'; [email-masked]'
> Cc:	[email-masked]'
> Subject:	RE: Role names in certificates
> 
> I'm somewhat confused.  I had thought that certificates and roles could
> be used in a variety of contexts (applications) for, among other things,
> access control.  Therefore this would appear to extend beyond just the
> S/MIME messaging context.  Is this of interest to the LDAP access
> controls?  Is this useful for the web-based document retrieval
> environments?  
> 
> Sandi Miklos
> 
> 
> >----------
> >From: 	Denis Pinkas[SMTP:[email-masked]]
> >Sent: 	Tuesday, May 05, 1998 5:49 PM
> >To: 	Blake Ramsdell
> >Cc: 	[email-masked]'
> >Subject: 	Re: Role names in certificates
> >
> >> I have written a draft that I have submitted as an individual (not
> under
> >> IETF-PKIX).  It describes a concept of using "role" names in
> >> certificates for several purposes that are not covered with
> conventional
> >> PKIX certificates.  
> >
> >I am not sure that this thread is relevant to the PKIX WG. It might be
> >more relevant to the S/MIME WG.
> >
> >> I have currently profiled the rfc822Name choice, but
> >> I have heard that there is interesting in profiling the dNSName choice
> >> also.  Cutting and pasting a little bit from the document, roles are
> >> defined for:
> >> 
> >> * The need to sign messages on behalf of people at a domain that may or
> >> may not have signature services available at the desktop. An outbound
> >> message from a domain may be sent that is signed at the domain mail
> >> server.
> >
> >A requirement would be the need to sign a message as the Sales Director
> >of the Delta Company, who may happen to be John Walker. However John
> >Walker may not have a private key of its own.
> > 
> >> * The need to encrypt messages for people at a domain that may not have
> >> encryption services available at the desktop. A message may be
> encrypted
> >> for the domain mail server using a domain encrypting certificate, and
> >> that message will be decrypted before local delivery.
> >
> >For the other following cases related to encryption, I wonder why a role
> >is needed.
> > 
> >> * The need to encrypt messages between two mail transfer agents (MTAs).
> >> This is different than a domain encrypting certificate, in that the
> >> message is never encrypted or decrypted at the mail user agent (MUA)
> >> level.
> >> 
> >> * The need to encrypt messages for a keypair that is controlled by the
> >> domain administrator for the purposes of plaintext access. A message
> may
> >> be encrypted for the domain mail server using a domain message recovery
> >> encryption certificate for the purpose of selective plaintext recovery
> >> by the domain administrator. This differs from a domain encrypting
> >> certificate in that the message is not necessarily decrypted before
> >> local delivery.
> >> 
> >> I know that the last one is going to be controversial, and this is not
> >> an all-or-nothing proposal (you can simply not implement it).  Please
> >> don't flame me for daring to speak its evil name, but keep an open mind
> >> for the other uses I have listed.
> >
> >> This is meant to get the ball rolling in a direction where we think
> >> about PKIX representing entities that are not necessarily a specific
> >> end-entity, but an end-entity with a particular role or responsibility.
> >
> >This is the point.
> >
> >> Any insight welcome as to how to address these issues in an alternative
> >> way.
> > 
> >> http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
> >> the latest version
> >> http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
> >> the current draft at the IETF.
> >> 
> >> Now where's my suit...
> >
> >There are several ways to address this issue. Among them: 
> >
> >1) a signature server (from a company) is able to sign documents on
> >behalf of an employee with its own key and indicate the appropriate role
> >used by the employee. The employee may authenticate to that signature
> >server by whatever means. In that case the signer is the company which
> >indicates the role of the employee.
> >
> >2) a temporary certificate issued by a server of a company includes a
> >role and a temporary public key. The employee is given back the
> >temporary private key so that it can sign documens directly using that
> >private key.
> >
> >If we would like to support such scheme(s), some arrangements would need
> >to be done to the S/MIME specifications, so I would propose to shift
> >this thread to the S/MIME WG.
> >
> >Denis
> > 
> >> Blake
> >> --
> >> Blake C. Ramsdell
> >> Worldtalk Corporation
> >> For current info, check http://www.deming.com/users/blaker
> >> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
> >
> >-- 
> >      Denis Pinkas     Bull S.A.          mailto:[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: Tue, 05 May 1998 11:11:43 -0400
To: Nada Kapidzic Cicovic <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Usage of Diffe-Hellman keys
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 11:00 AM 5/5/98 +0200, Nada Kapidzic Cicovic wrote:
>Hi all,

Hi.

>Sorry for cross-posting this letter to PKIX and S/MIME lists, but it seems
>to me that this topic belongs to both of them. I was wondering about the
>usage of Diffie-Hellman keys and the suggested values of keyUsage extension. 
>
>PKIX part1 section 7.3.2 suggests three possible values for keyUsage
>extension in a certificate containing Diffie-Hellman public key:
>keyAgreement, enchipherOnly and dechiperOnly.
>
>Trying to put this into S/MIME context it seems that Diffie-Hellman keys
>may only be used in the way suggested by Russ Housley, i.e. for each
>recipient to take recipient's Diffie-Hellman certificate (key agreement
>certificate), get the public key from there, generate a shared key (Russ
>suggested 3DES) and use it to encrypt the content-encryption key.

Obviously, I support this approach.  I envision the keyAgreement bit set in
the certificate containing the D-H public key.

>However, another possibility is to use El-Gamal algorithm with
>Diffie-Hellman keys and encrypt the content-encryption key directly with
>recipients Diffie-Hellman public key. This would be a very similar
>operation as if the recipient had RSA keys and keyEnchipherment
>certificate. This seems to be a much better way of using Diffie-Hellman
>keys, similar to the way RSA keys are used for keys encryption (unless I
>have missed some point here).

As you describe the process, it is not key agreement.  Rather it is
keyEnchipherment.  Althought the process for key generation is the same, I
would not coniser it a Diffie-Hellman key.  Similalry, a DSA key can
mathematically be used for key agreement (in either Diffie-Hellman or KEA),
yet I do not consider a DSA key to be a key agreement key.

>In order to use El-Gamal in the described way, keyUsage extension in
>certificates containing Diffie-Hellman keys would need to have
>keyEnchipherment bit set. Therefore, if I am not mistaking in my above
>decryption, I suggest the following changes in PKIX part1:
>
>- Changing the name of section 7.3.2 from "Diffie-Hellman Key Exchange Key"
>into "Diffie-Hellman Keys" (in accordance with 7.3.1 RSA Keys).
>
>- Adding keyEnchipherment as a possible value of the keyUsage extension.
>
>- Adding the following decryption at the end of the section: When
>keyEnchipherment bit is set in keyUsage extension, the public key may be
>used for encrypting session keys by using El-Gamal algorithm.
>
>
>In order to use El-Gamal for encrypting content-encryption keys in S/MIME,
>an object identifier would need to be assigned for El-Gamal algorithm (I
>have failed to find an existing one; does anybody have some info about
>it?). I suppose this would be a task of S/MIME group, and contained in one
>of the S/MIME drafts.
>
>
>Again, if I am not mistaking here, I would suggest this changes to be made
>in both drafts, since this would aid a lot in usage of Diffie-Hellman keys.
>
>
>I am looking forward to hearing your opinions.
>
>Regards,
>
>Nada
>______________________________________________________________
>
>Nada Kapidzic Cicovic
>COST - Computer Security Technologies CST AB 
>(subsidiary of Entegrity Solutions Corporation)
>office:   + 46 (0)8 477 77 37
>mobile:   + 46 (0)70 495 09 03
>fax:      + 46 (0)8 477 77 31
>e-mail:   [email-masked] or [email-masked]
>address:  Finlandsgatan 60, 164 74 Kista, Sweden
> 

Date: Tue, 05 May 1998 17:23:42 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Miklos, Sue A." <[email-masked]>
CC: "'Blake Ramsdell'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Role names in certificates
Sender: [email-masked]

Miklos, Sue A. wrote:
 
> I'm somewhat confused.  I had thought that certificates and roles could
> be used in a variety of contexts (applications) for, among other things,
> access control.  Therefore this would appear to extend beyond just the
> S/MIME messaging context.  

Your are right. Role-based access control for "real-time" transactions
(as opposed to store and forward schemes) is another area where the
solutions may be different. Examples of such solutions are DCE and
SESAME where in both cases PAC "Privilege Attribute Certificates" are
used. 

> Is this of interest to the LDAP access controls?  
> Is this useful for the web-based document retrieval environments?

This could be. 

Denis

> Sandi Miklos
> 
> >----------
> >From:  Denis Pinkas[SMTP:[email-masked]]
> >Sent:  Tuesday, May 05, 1998 5:49 PM
> >To:    Blake Ramsdell
> >Cc:    [email-masked]'
> >Subject:       Re: Role names in certificates
> >
> >> I have written a draft that I have submitted as an individual (not under
> >> IETF-PKIX).  It describes a concept of using "role" names in
> >> certificates for several purposes that are not covered with conventional
> >> PKIX certificates.
> >
> >I am not sure that this thread is relevant to the PKIX WG. It might be
> >more relevant to the S/MIME WG.
> >
> >> I have currently profiled the rfc822Name choice, but
> >> I have heard that there is interesting in profiling the dNSName choice
> >> also.  Cutting and pasting a little bit from the document, roles are
> >> defined for:
> >>
> >> * The need to sign messages on behalf of people at a domain that may or
> >> may not have signature services available at the desktop. An outbound
> >> message from a domain may be sent that is signed at the domain mail
> >> server.
> >
> >A requirement would be the need to sign a message as the Sales Director
> >of the Delta Company, who may happen to be John Walker. However John
> >Walker may not have a private key of its own.
> >
> >> * The need to encrypt messages for people at a domain that may not have
> >> encryption services available at the desktop. A message may be encrypted
> >> for the domain mail server using a domain encrypting certificate, and
> >> that message will be decrypted before local delivery.
> >
> >For the other following cases related to encryption, I wonder why a role
> >is needed.
> >
> >> * The need to encrypt messages between two mail transfer agents (MTAs).
> >> This is different than a domain encrypting certificate, in that the
> >> message is never encrypted or decrypted at the mail user agent (MUA)
> >> level.
> >>
> >> * The need to encrypt messages for a keypair that is controlled by the
> >> domain administrator for the purposes of plaintext access. A message may
> >> be encrypted for the domain mail server using a domain message recovery
> >> encryption certificate for the purpose of selective plaintext recovery
> >> by the domain administrator. This differs from a domain encrypting
> >> certificate in that the message is not necessarily decrypted before
> >> local delivery.
> >>
> >> I know that the last one is going to be controversial, and this is not
> >> an all-or-nothing proposal (you can simply not implement it).  Please
> >> don't flame me for daring to speak its evil name, but keep an open mind
> >> for the other uses I have listed.
> >
> >> This is meant to get the ball rolling in a direction where we think
> >> about PKIX representing entities that are not necessarily a specific
> >> end-entity, but an end-entity with a particular role or responsibility.
> >
> >This is the point.
> >
> >> Any insight welcome as to how to address these issues in an alternative
> >> way.
> >
> >> http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
> >> the latest version
> >> http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
> >> the current draft at the IETF.
> >>
> >> Now where's my suit...
> >
> >There are several ways to address this issue. Among them:
> >
> >1) a signature server (from a company) is able to sign documents on
> >behalf of an employee with its own key and indicate the appropriate role
> >used by the employee. The employee may authenticate to that signature
> >server by whatever means. In that case the signer is the company which
> >indicates the role of the employee.
> >
> >2) a temporary certificate issued by a server of a company includes a
> >role and a temporary public key. The employee is given back the
> >temporary private key so that it can sign documens directly using that
> >private key.
> >
> >If we would like to support such scheme(s), some arrangements would need
> >to be done to the S/MIME specifications, so I would propose to shift
> >this thread to the S/MIME WG.
> >
> >Denis
> >
> >> Blake
> >> --
> >> Blake C. Ramsdell
> >> Worldtalk Corporation
> >> For current info, check http://www.deming.com/users/blaker
> >> Voice +1 425 882 8861 x103  Fax +1 425 882 8060

-- 
      Denis Pinkas     Bull S.A.          mailto:[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

From: "Scott, Greg" <[email-masked]>
To: [email-masked]
Subject: Question re ipki2opp-07
Date: Tue, 5 May 1998 09:53:00 -0400 
Sender: [email-masked]

   This is probably painfully obvious to most, but I'm just asking to be 
   sure.
   
   In section 6.2.1 the filter is defined as:
   
           Filter ::=
             CHOICE {
                     present       [7] AttributeType, -- "objectclass" only
                    }
   
   In 7.2.1 the text states that an element added to this service is:
   
     "- Enhanced filter capability"
   
   but there is no ASN.1 code redefining Filter.  
   
   Does this mean that the full range of filter conditions defined in RFC 
   1777 section 4.3 is now available?
   
   Thanks,
   
   Greg
   
   PS. Spelling and grammar nits:
      
       Section 6.2.2, I believe that "The application/relying party may 
       ..." should read "The application/replying party may ..."
       
       Section 7, "To search ,using ..." should read "To search, using ..."

From: "Miklos, Sue A." <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Role names in certificates
Date: Tue, 5 May 1998 09:29:38 -0400
Sender: [email-masked]

I'm somewhat confused.  I had thought that certificates and roles could
be used in a variety of contexts (applications) for, among other things,
access control.  Therefore this would appear to extend beyond just the
S/MIME messaging context.  Is this of interest to the LDAP access
controls?  Is this useful for the web-based document retrieval
environments?  

Sandi Miklos

>----------
>From: 	Denis Pinkas[SMTP:[email-masked]]
>Sent: 	Tuesday, May 05, 1998 5:49 PM
>To: 	Blake Ramsdell
>Cc: 	[email-masked]'
>Subject: 	Re: Role names in certificates
>
>> I have written a draft that I have submitted as an individual (not under
>> IETF-PKIX).  It describes a concept of using "role" names in
>> certificates for several purposes that are not covered with conventional
>> PKIX certificates.  
>
>I am not sure that this thread is relevant to the PKIX WG. It might be
>more relevant to the S/MIME WG.
>
>> I have currently profiled the rfc822Name choice, but
>> I have heard that there is interesting in profiling the dNSName choice
>> also.  Cutting and pasting a little bit from the document, roles are
>> defined for:
>> 
>> * The need to sign messages on behalf of people at a domain that may or
>> may not have signature services available at the desktop. An outbound
>> message from a domain may be sent that is signed at the domain mail
>> server.
>
>A requirement would be the need to sign a message as the Sales Director
>of the Delta Company, who may happen to be John Walker. However John
>Walker may not have a private key of its own.
> 
>> * The need to encrypt messages for people at a domain that may not have
>> encryption services available at the desktop. A message may be encrypted
>> for the domain mail server using a domain encrypting certificate, and
>> that message will be decrypted before local delivery.
>
>For the other following cases related to encryption, I wonder why a role
>is needed.
> 
>> * The need to encrypt messages between two mail transfer agents (MTAs).
>> This is different than a domain encrypting certificate, in that the
>> message is never encrypted or decrypted at the mail user agent (MUA)
>> level.
>> 
>> * The need to encrypt messages for a keypair that is controlled by the
>> domain administrator for the purposes of plaintext access. A message may
>> be encrypted for the domain mail server using a domain message recovery
>> encryption certificate for the purpose of selective plaintext recovery
>> by the domain administrator. This differs from a domain encrypting
>> certificate in that the message is not necessarily decrypted before
>> local delivery.
>> 
>> I know that the last one is going to be controversial, and this is not
>> an all-or-nothing proposal (you can simply not implement it).  Please
>> don't flame me for daring to speak its evil name, but keep an open mind
>> for the other uses I have listed.
>
>> This is meant to get the ball rolling in a direction where we think
>> about PKIX representing entities that are not necessarily a specific
>> end-entity, but an end-entity with a particular role or responsibility.
>
>This is the point.
>
>> Any insight welcome as to how to address these issues in an alternative
>> way.
> 
>> http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
>> the latest version
>> http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
>> the current draft at the IETF.
>> 
>> Now where's my suit...
>
>There are several ways to address this issue. Among them: 
>
>1) a signature server (from a company) is able to sign documents on
>behalf of an employee with its own key and indicate the appropriate role
>used by the employee. The employee may authenticate to that signature
>server by whatever means. In that case the signer is the company which
>indicates the role of the employee.
>
>2) a temporary certificate issued by a server of a company includes a
>role and a temporary public key. The employee is given back the
>temporary private key so that it can sign documens directly using that
>private key.
>
>If we would like to support such scheme(s), some arrangements would need
>to be done to the S/MIME specifications, so I would propose to shift
>this thread to the S/MIME WG.
>
>Denis
> 
>> Blake
>> --
>> Blake C. Ramsdell
>> Worldtalk Corporation
>> For current info, check http://www.deming.com/users/blaker
>> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>-- 
>      Denis Pinkas     Bull S.A.          mailto:[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
>

From: [email-masked]
To: Anne Anderson - Sun Microsystems <[email-masked]>
cc: [email-masked]
Date: Tue, 5 May 1998 08:51:28 -0400
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Anne Anderson <[email-masked]> writes:

>There currently is no way to encode DNS and other alternative
>names as RDNs that is supported by PKIX.  If there were, then
>I agree completely with Dave's argument.
>
>The DC= format is in RFC2247, and this has not been incorporated
>into either X.501/X.509 or PKIX.

RFC2247 names are perfectly valid X.500 names, and as there are no
restrictions on the attribute types used within Name objects in the PKIX-1
spec, there should be no problem with putting them into the Subject or
Issuer fields of PKIX certificates.  But I agree that it would be good if
the PKIX documents were to explicitly recommend the use of the RFC2247 'DC'
attribute type to represent names from the DNS namespace, for situations
where a key is owned by some entity identified by a DNS name.  This might
prevent someone from inventing a different way to represent DNS names.

Other messages have interpreted the use of X.500 names as implying some
sort of control by the ITU.  I don't see where this comes from at all.
X.500 RDNs are typed, those types being specified using OIDs which are
expressly designed to support federated allocation and control.  "Control"
of any particular subtree within the X.500 namespace belongs to whatever
body is responsible for the OID of the top-level RDN of that subtree.  For
RFC2247 names, the 'DC' OID has been specified by its owner as representing
DNS components, and therefore such names are "controlled" by the DNS.

If I wanted to invent my own attribute-type for use in names I generate, I
could do so, and I would retain control of all such names.  I wouldn't have
to register this attribute type with the ITU or anyone else (assuming I
already have an OID register).  I can think of two reasons for not doing so
(or at least for not putting such names in PKIX certificates), neither of
which has anything to do with control of a portion of the namespace, but
instead have to do with interoperability:

i) PKIX implementations won't know what matching rules to apply to
attribute types they don't recognize.  The proposed new PKIX-1 text
specifies some universal matching rules, regardless of what might be
specified in my attribute definition, which would eliminate this problem,
although I'd prefer to see the new rules specified only as a fallback
mechanism, to be used when the "real" matching rules aren't known to the
implementation.

ii) Broken PKIX implementations might reject names that use attributes they
don't recognize.  Can some text be added to PKIX-1 to alert implementors to
the fact that names can use varied name forms and attribute types, and that
names shouldn't be rejected simply because they use unfamiliar attributes?

John

Date: Tue, 05 May 1998 14:49:30 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Blake Ramsdell <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Role names in certificates
Sender: [email-masked]

> I have written a draft that I have submitted as an individual (not under
> IETF-PKIX).  It describes a concept of using "role" names in
> certificates for several purposes that are not covered with conventional
> PKIX certificates.  

I am not sure that this thread is relevant to the PKIX WG. It might be
more relevant to the S/MIME WG.

> I have currently profiled the rfc822Name choice, but
> I have heard that there is interesting in profiling the dNSName choice
> also.  Cutting and pasting a little bit from the document, roles are
> defined for:
> 
> * The need to sign messages on behalf of people at a domain that may or
> may not have signature services available at the desktop. An outbound
> message from a domain may be sent that is signed at the domain mail
> server.

A requirement would be the need to sign a message as the Sales Director
of the Delta Company, who may happen to be John Walker. However John
Walker may not have a private key of its own.
 
> * The need to encrypt messages for people at a domain that may not have
> encryption services available at the desktop. A message may be encrypted
> for the domain mail server using a domain encrypting certificate, and
> that message will be decrypted before local delivery.

For the other following cases related to encryption, I wonder why a role
is needed.
 
> * The need to encrypt messages between two mail transfer agents (MTAs).
> This is different than a domain encrypting certificate, in that the
> message is never encrypted or decrypted at the mail user agent (MUA)
> level.
> 
> * The need to encrypt messages for a keypair that is controlled by the
> domain administrator for the purposes of plaintext access. A message may
> be encrypted for the domain mail server using a domain message recovery
> encryption certificate for the purpose of selective plaintext recovery
> by the domain administrator. This differs from a domain encrypting
> certificate in that the message is not necessarily decrypted before
> local delivery.
> 
> I know that the last one is going to be controversial, and this is not
> an all-or-nothing proposal (you can simply not implement it).  Please
> don't flame me for daring to speak its evil name, but keep an open mind
> for the other uses I have listed.

> This is meant to get the ball rolling in a direction where we think
> about PKIX representing entities that are not necessarily a specific
> end-entity, but an end-entity with a particular role or responsibility.

This is the point.

> Any insight welcome as to how to address these issues in an alternative
> way.
 
> http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
> the latest version
> http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
> the current draft at the IETF.
> 
> Now where's my suit...

There are several ways to address this issue. Among them: 

1) a signature server (from a company) is able to sign documents on
behalf of an employee with its own key and indicate the appropriate role
used by the employee. The employee may authenticate to that signature
server by whatever means. In that case the signer is the company which
indicates the role of the employee.

2) a temporary certificate issued by a server of a company includes a
role and a temporary public key. The employee is given back the
temporary private key so that it can sign documens directly using that
private key.

If we would like to support such scheme(s), some arrangements would need
to be done to the S/MIME specifications, so I would propose to shift
this thread to the S/MIME WG.

Denis
 
> Blake
> --
> Blake C. Ramsdell
> Worldtalk Corporation
> For current info, check http://www.deming.com/users/blaker
> Voice +1 425 882 8861 x103  Fax +1 425 882 8060

-- 
      Denis Pinkas     Bull S.A.          mailto:[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: Tue, 05 May 1998 13:56:45 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Slava Galperin <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP status tally
Sender: [email-masked]

Slava,

It may happen that an OCSP responder is in charge of multiple CAs.
Without that name, you would *mandate* the use an internal index that
will have to be the hash of the issuer public key.

This would work fine, but would mandate an implementation design. Is it
really needed to save a few bits and thus to omit to advertise the name
of the issuer ?

I would prefer to let the choice of the implememtation to the
implementors.

Denis

> Michael Myers wrote:
> >
> > Marc, All:
> >
> > I would like to propose we move forward with the following simplified
> > construction:
> >
> > CertStatusType ::= ENUMERATED {
> >     notRevoked     (0),
> >     revoked        (1),
> >     onHold         (2),
> >     unknownCA      (3),
> >     unknownCert    (4) }
> >
> > In the unknownCA case, a repository may not have acquired information
> > necessary to produce any other assertion.  The unknownCert value addresses
> > all other states not explicitly address by notRevoked or revoked.  In
> > particular, it may be the case that a certain repositories can be proven to
> > have only received a subset of a CA's information via mechanisms such as
> > CRL Distribution Points, CRLList or other means of delegating authority.
> >
> 
> I think it might be reasonable to include revocation reason or
> revocation date when sending "revoked" status (and in this case it may
> be combined with "onHold" case).
> Also various "do not know"s can be folded into single "unknown" response
> since it seems unlikely that OCSP requester cares about the difference.
> 
> May I reintroduce my original suggestion to have the following
> RevocationStauts definition with small variations (hoping that after
> numerous discussions we had the intent here will be a little clearer
> this time):
> 
> RevocationStatus ::= CHOICE {
>         unknown      [0] IMPLICIT UnknownInfo,
>         notRevoked   [1] IMPLICIT NULL,
>         revoked      [2] IMPLICIT RevokedInfo,
> 
> }
> 
> UnknownInfo ::= NULL -- this can be replaced with an enumeration
>                      -- for various specific reasons such as
> doNotKnowAboutCA etc.
> 
> RevokedInfo ::= SEQUENCE {
>         revocationTime GeneralizedTime,
>         revocationReason RevocationReason OPTIONAL -- this could include
> "onHold"
> }
> 
> I would like to stress that if OCSP requester does not care about the
> details attached to specific status it can stop after parsing the CHOICE
> tag and is not required to parse CHOICE inner content. Therefore for
> less sophisticated OCSP requresters this definitions is just as simple
> as ENUMERATED whereas more sophisticated ones can take advantage of the
> information associated with a particular status code.
> 
> --
> 
> Slava

-- 
      Denis Pinkas     Bull S.A.          mailto:[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: Tue, 05 May 1998 11:00:34 +0200
To: [email-masked], [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: Usage of Diffe-Hellman keys
Sender: [email-masked]

Hi all,

Sorry for cross-posting this letter to PKIX and S/MIME lists, but it seems
to me that this topic belongs to both of them. I was wondering about the
usage of Diffie-Hellman keys and the suggested values of keyUsage extension. 

PKIX part1 section 7.3.2 suggests three possible values for keyUsage
extension in a certificate containing Diffie-Hellman public key:
keyAgreement, enchipherOnly and dechiperOnly.

Trying to put this into S/MIME context it seems that Diffie-Hellman keys
may only be used in the way suggested by Russ Housley, i.e. for each
recipient to take recipient's Diffie-Hellman certificate (key agreement
certificate), get the public key from there, generate a shared key (Russ
suggested 3DES) and use it to encrypt the content-encryption key.

However, another possibility is to use El-Gamal algorithm with
Diffie-Hellman keys and encrypt the content-encryption key directly with
recipients Diffie-Hellman public key. This would be a very similar
operation as if the recipient had RSA keys and keyEnchipherment
certificate. This seems to be a much better way of using Diffie-Hellman
keys, similar to the way RSA keys are used for keys encryption (unless I
have missed some point here).

In order to use El-Gamal in the described way, keyUsage extension in
certificates containing Diffie-Hellman keys would need to have
keyEnchipherment bit set. Therefore, if I am not mistaking in my above
decryption, I suggest the following changes in PKIX part1:

- Changing the name of section 7.3.2 from "Diffie-Hellman Key Exchange Key"
into "Diffie-Hellman Keys" (in accordance with 7.3.1 RSA Keys).

- Adding keyEnchipherment as a possible value of the keyUsage extension.

- Adding the following decryption at the end of the section: When
keyEnchipherment bit is set in keyUsage extension, the public key may be
used for encrypting session keys by using El-Gamal algorithm.

In order to use El-Gamal for encrypting content-encryption keys in S/MIME,
an object identifier would need to be assigned for El-Gamal algorithm (I
have failed to find an existing one; does anybody have some info about
it?). I suppose this would be a task of S/MIME group, and contained in one
of the S/MIME drafts.

Again, if I am not mistaking here, I would suggest this changes to be made
in both drafts, since this would aid a lot in usage of Diffie-Hellman keys.

I am looking forward to hearing your opinions.

Regards,

Nada
______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB 
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Date: Mon, 04 May 1998 18:54:29 -0700
From: Slava Galperin <[email-masked]>
Organization: Teknowledge Corporation
To: Ambarish Malpani <[email-masked]>
CC: IETF PKIX <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------D1F529F87476838B12F5530C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

Most of the people who responded to this message agree that only option
3 (IssuerDN, Hash(IssuerPublicKey) and CertSerialNumber) is usable.
However there is still an unsettled issue of whether to mandate use of
issuer DN for EE cert and subject DNs for CA cert or relax it to use
respective AltName extensions. 

I have suggested earlier that <em> in the context of OCSP </em> we may
get away from using names altogether (and thus avoid name-related
arguments). At that time the proposal did not have much support. I would
like to revisit it again and analyze scenarios and arguments. To restore
context I quoted my original message as well as some relevant responses
from Dave Kemp and Stephen Kent. My analysis and summary is at the end
of this message.

Slava Galperin wrote:

> 
> Technically I am proposing to use either
> 
> CertID                  ::=     SEQUENCE {
>          issuerKeyHash            Hash,
>          serialNumber                    CertificateSerialNumber,
> }
> 
> where issuerKeyHash is a hash of subjectPublicKeyInfo field from the
> corresponding CA certificate, or
> 
> CertID                  ::=     SEQUENCE {
>          issuerKey          SubjectPublicKeyInfo,
>          serialNumber                    CertificateSerialNumber,
> }
> 
> in case we are afraid of the hash collisions and are willing to
> sacrifice some bandwidth for some peace of mind.
> 
> Note however, that both in the original RCSP spec and in my proposed
> scheme above there is another interesting open problem of dealing with
> the CA
> key change-over, i.e. when various subsets of the set of all issued
> certificates (and CRLs !) are signed by different signing keys
> 

Stephen Kent ([email-masked]) wrote:

> Slava,
> 
> While the hash of a CA's key would likely be unique, it also is a terrible
> search key in many instances. One has to be careful about the context in
> which a pointer to a CA cert is being used. In a cert, having a CA "key ID"
> that is based on the hash of the CA is fine, because we already have the CA
> name, and maybe even a locator.  In other protocol context we should have a
> similar level of naming for search purposes, and rely on something like a
> key hash just for disambiguation among multiple possible keys associated
> with the same CA.

David P. Kemp ([email-masked]) wrote:

> 
> This is a reasonable approach if you ignore the cert retrieval and
> multiple-key issues, however you still need to specify the hash
> algorithm since it's inappropriate to hard code a single algorithm
> into the standard:
> 
>    CertID ::= SEQUENCE {
>       issuerKeyID       KeyID,
>       serialNumber      CertificateSerialNumber }
> 
>    KeyID  ::= CHOICE {
>       publicKey         [0] SubjectPublicKeyInfo,
>       sha1KeyHash       [1] OCTET STRING,     -- SHA1 of SubjectPublicKeyInfo
>       ripemd160KeyHash  [2] OCTET STRING,
>        ...       }
> 
> 
> All in all, it gets pretty ugly if you want to make it work in all cases.
> It may be easier just to use the existing authority and subject key
> identifier extensions instead of trying to design something new.
> 

I would like to start analyzing possible contexts for certificate
identification in OCSP. 

OCSP client (I am assuming fat OCSP client that has already verified
signatures, validity and other extension-constrained semantics on the
certificate chain and only needs to check revocation status of ALL the
certificates in the chain) knows the public key of CA used to sign any
certificate in the chain. It must already know this because this is how
it verifies signatures in the chain (it will be using some sort of
chaining algorithm based on a combination of issuer primary/alternative
name and key identifier which I leave for PKIX 1 to define, the bottom
line is : for every certificate in the chain CA's public key is
inambiguosly known to the OCSP client).

On the other side, OCSP responder needs to map cert identification
information from the OCSP request onto some certificate status record.
It achieves it by converting cert id into query which can produce none,
one or multiple results. Cert id chosen for OCSP should satisfy two
goals: to be unique and to provide OCSP responder implementations with
basis for efficient indexing. Steve in his response makes a very valid
point that public key hash may be a lousy index. I guess our recent
discussion shows that issuer name could be even more lousy one. Aside
from canonicalization, two main disadvantages are: multiple name forms
(needed by different people and different applications) and absence of
the reliable infrastructure that guarantees uniqueness of the name (is
not it this very point that brings Hash(IssuerPublicKey) into all of the
certificate identification schemes proposed by Ambarish ?). 

If we do agree to include Hash(IssuerPublicKey) in the cert ID to
disambiguate potential issuer name collisions, then OCSP responder must
be prepared to use it (otherwise it serves no purpose) and thus deal
with issues like CA using multiple signing keys over time. This means
that it needs to have information on all public keys (past and present)
used by a CA to sign certificates. For OCSP responder implementation
closely integrated with a CA having access to this info should not be a
problem. For an OCSP responder working off CRL it needs CA
certificates/keys anyway to verify signature on CRLs (assuming that the
same key used for certifcates and CRL). At any rate I do not see
maintaining a list of past and present CA public keys in  OCSP responder
configuration to be a serious implementation constraint and in most
cases it will be available there for other reasons. Also CA key
change-over is not likely to be a very frequent event so number of the
CA certificates(or public keys) OCSP responder implementation needs to
remember is not an issue.

Having said all of that I would like to repropose using just a pair
(Hash(IssuerPublicKey),CertSerialNumber) as cert id in OCSP. It is
unique (by definition), free from multiple name form/canonicalization
problems and does allow efficient indexing on OCSP responder side
(provided CA public key history is maintained).

If it does get accepted we can work out ASN.1 syntax details
(incorporating open set of hash algorithms etc.)

HTH
--
Slava
--------------D1F529F87476838B12F5530C
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Slava Galperin
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Slava Galperin
n:              Galperin;Slava
org:            Teknowledge Corporation
adr:            1810 Embarcadero Road;;;Palo Alto;CA;94303;USA
email;internet: [email-masked]
title:          Senior Scientist
tel;work:       (650)242-0500x519
tel;fax:        (650)493-2645
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

--------------D1F529F87476838B12F5530C--

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "pkix" <[email-masked]>
Subject: OCDP and Smartcards and progressing to proposed standard
Date: Mon, 4 May 1998 17:51:35 -0400
Sender: [email-masked]

Last week I attended the CardTech/SecureTech conference in Washington DC.

This set me thinking about the practicallity of acheiving OFFLINE
authorisation using a smartcard to store a private key, certificate and
associated authorisation and validity information.

Offline authorisation is interesting for two reasons:

First, it is not always possible to ensure that a terminal is connected to
the Internet. Consider that it is relatively cheap to add a smartcard reader
and solenoid to a door (order $100) but running a wire to the door can be
very expensive indeed (Installation cost typically $10-$50/meter).

Second, it is not always possible to guarantee network availability. The
question of how a system reacts when temporarily disconnected must therefore
be considered. I call this situation 'quasi-offline', the key point is to
avoid denial of service attacks in which loss of connection to head office
stops all local access.

The use of smartcards introduces a major space constraint, The private key,
certificate and validity information must certainly occupy no more than 8Kb
and preferably occupies very much less. Conventional CRLs which might grow
to millions of certificates are clearly unacceptable. Indeed the practical
limit on a CRL to fit on a smartcard is probably no more than 25 entries.

Static Certificate Distribution Points (ie those which may or may not be in
PKIX part 1) aford a brute force solution of the problem, albeit one
unlikely to be very acceptable. Simply divide the certificate population
into partitions of 35 certificates and issue a CRL for each.

The scoping part of OCDP allows the CRL partitions to be much larger.
Because partitions may be defined at the time of issue the limit of
partition size is the number of certificates actually revoked rather than a
particular number of certificates. Thus is 10% of certificates are revoked
the average partition will consist of 350 certificates (35 of which are
revoked) and the CA does 10% of the work which would be required with static
 partitions. If the proportion of revoked certificates is smaller the work
factor reduces even further!

Observe that a CA issuing such CRLs on a daily basis would on average spend
roughly an equal amount of time signing CRLs and actual certificates.
(Assume certificates are valid for a year). A scoped CRL may thus constitute
a sufficient solution to the offline revocation/statement of validity
problem.

[BTW a smartcard may aquire its CRL partition whenever it is used in an
online transaction. The smartcard having the ability to check the CRL
signature for validity and also check that it is more recent than its
current CRL partition]

CRLList allows the effort required by the CA to be reduced still further
however. Using CRLList the CA does not need to re-sign each CRL partition
each day. Only those partitions which have changed need to be re-signed.

While it may not be practical to place the CRLList on the smartcard at
present there are many 'quasi-offline' cases in which it is possible to
assume the party needing to validate a certificate has access to the CRLList
even though it is not practical to assume that they have access to
individual CRL partitions. Consider the case in which a remote office
downloads the CRLList at the start of each business day but does not have
adequate bandwidth to perform on-demand downloading of CRLs.

In summary I believe that OCDP is a very useful tool which solves a set of
important problems which are not addressed by static CDPs, OCSP, revocation
trees etc. That is not to say that these do not also have a place.

OCDP is certainly far more than a 'work arround' the Entrust patent. While
the case for OCDP becomes hard to argue against if the licensing terms
themselves prove unacceptable (at present we have only statements concerning
what those terms would be which is not the same thing), the case is still
strong if an acceptable covenant is offered and made.

The question is then how to go forward with OCDP within the IETF. I
certainly do not want to derail the PKIX part 1 standards track process, on
the other hand OCDP is quite logically a part of the PKIX CRL profile. What
I propose is that we progress the current draft towards Proposed Standard as
a separate RFC. We then have the option of 'docking' OCDP with the main
standards document as we go through the process of progressing that to Draft
Standard. Alternatively the docking maneuver could take place much later on
as part of PKIXv2.

        Phill

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "pkix" <[email-masked]>
Subject: OCDP and Smartcards and progressing to proposed standard
Date: Mon, 4 May 1998 17:51:35 -0400
Sender: [email-masked]

Last week I attended the CardTech/SecureTech conference in Washington DC.

This set me thinking about the practicallity of acheiving OFFLINE
authorisation using a smartcard to store a private key, certificate and
associated authorisation and validity information.

Offline authorisation is interesting for two reasons:

First, it is not always possible to ensure that a terminal is connected to
the Internet. Consider that it is relatively cheap to add a smartcard reader
and solenoid to a door (order $100) but running a wire to the door can be
very expensive indeed (Installation cost typically $10-$50/meter).

Second, it is not always possible to guarantee network availability. The
question of how a system reacts when temporarily disconnected must therefore
be considered. I call this situation 'quasi-offline', the key point is to
avoid denial of service attacks in which loss of connection to head office
stops all local access.

The use of smartcards introduces a major space constraint, The private key,
certificate and validity information must certainly occupy no more than 8Kb
and preferably occupies very much less. Conventional CRLs which might grow
to millions of certificates are clearly unacceptable. Indeed the practical
limit on a CRL to fit on a smartcard is probably no more than 25 entries.

Static Certificate Distribution Points (ie those which may or may not be in
PKIX part 1) aford a brute force solution of the problem, albeit one
unlikely to be very acceptable. Simply divide the certificate population
into partitions of 35 certificates and issue a CRL for each.

The scoping part of OCDP allows the CRL partitions to be much larger.
Because partitions may be defined at the time of issue the limit of
partition size is the number of certificates actually revoked rather than a
particular number of certificates. Thus is 10% of certificates are revoked
the average partition will consist of 350 certificates (35 of which are
revoked) and the CA does 10% of the work which would be required with static
 partitions. If the proportion of revoked certificates is smaller the work
factor reduces even further!

Observe that a CA issuing such CRLs on a daily basis would on average spend
roughly an equal amount of time signing CRLs and actual certificates.
(Assume certificates are valid for a year). A scoped CRL may thus constitute
a sufficient solution to the offline revocation/statement of validity
problem.

[BTW a smartcard may aquire its CRL partition whenever it is used in an
online transaction. The smartcard having the ability to check the CRL
signature for validity and also check that it is more recent than its
current CRL partition]

CRLList allows the effort required by the CA to be reduced still further
however. Using CRLList the CA does not need to re-sign each CRL partition
each day. Only those partitions which have changed need to be re-signed.

While it may not be practical to place the CRLList on the smartcard at
present there are many 'quasi-offline' cases in which it is possible to
assume the party needing to validate a certificate has access to the CRLList
even though it is not practical to assume that they have access to
individual CRL partitions. Consider the case in which a remote office
downloads the CRLList at the start of each business day but does not have
adequate bandwidth to perform on-demand downloading of CRLs.

In summary I believe that OCDP is a very useful tool which solves a set of
important problems which are not addressed by static CDPs, OCSP, revocation
trees etc. That is not to say that these do not also have a place.

OCDP is certainly far more than a 'work arround' the Entrust patent. While
the case for OCDP becomes hard to argue against if the licensing terms
themselves prove unacceptable (at present we have only statements concerning
what those terms would be which is not the same thing), the case is still
strong if an acceptable covenant is offered and made.

The question is then how to go forward with OCDP within the IETF. I
certainly do not want to derail the PKIX part 1 standards track process, on
the other hand OCDP is quite logically a part of the PKIX CRL profile. What
I propose is that we progress the current draft towards Proposed Standard as
a separate RFC. We then have the option of 'docking' OCDP with the main
standards document as we go through the process of progressing that to Draft
Standard. Alternatively the docking maneuver could take place much later on
as part of PKIXv2.

        Phill

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Role names in certificates
Date: Mon, 4 May 1998 14:23:29 -0700
Sender: [email-masked]

I have written a draft that I have submitted as an individual (not under
IETF-PKIX).  It describes a concept of using "role" names in
certificates for several purposes that are not covered with conventional
PKIX certificates.  I have currently profiled the rfc822Name choice, but
I have heard that there is interesting in profiling the dNSName choice
also.  Cutting and pasting a little bit from the document, roles are
defined for:

* The need to sign messages on behalf of people at a domain that may or
may not have signature services available at the desktop. An outbound
message from a domain may be sent that is signed at the domain mail
server.

* The need to encrypt messages for people at a domain that may not have
encryption services available at the desktop. A message may be encrypted
for the domain mail server using a domain encrypting certificate, and
that message will be decrypted before local delivery.

* The need to encrypt messages between two mail transfer agents (MTAs).
This is different than a domain encrypting certificate, in that the
message is never encrypted or decrypted at the mail user agent (MUA)
level.

* The need to encrypt messages for a keypair that is controlled by the
domain administrator for the purposes of plaintext access. A message may
be encrypted for the domain mail server using a domain message recovery
encryption certificate for the purpose of selective plaintext recovery
by the domain administrator. This differs from a domain encrypting
certificate in that the message is not necessarily decrypted before
local delivery.

I know that the last one is going to be controversial, and this is not
an all-or-nothing proposal (you can simply not implement it).  Please
don't flame me for daring to speak its evil name, but keep an open mind
for the other uses I have listed.

This is meant to get the ball rolling in a direction where we think
about PKIX representing entities that are not necessarily a specific
end-entity, but an end-entity with a particular role or responsibility.
Any insight welcome as to how to address these issues in an alternative
way.

http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
the latest version
http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
the current draft at the IETF.

Now where's my suit...

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Mon, 04 May 1998 18:29:30 -0300
From: Rodrigo Botafogo <[email-masked]>
Organization: Certisign
To: ietf <[email-masked]>
Subject: X.509 definition
Sender: [email-masked]

I'm new to this list, so I'm sorry if this is not the right place for
this kind of question.

I'm trying to compile the X.509 Certificate and CRL Profile as defined
in the March 25, 1998 document.  I have a couple of questions about this
definition:

===========
1) In this document a certificate is defined as:

Certificate ::=  EXPLICIT  SIGNED { SEQUENCE {
             version       [0] Version DEFAULT v1,
             serialNumber  CertificateSerialNumber,
             signature  AlgorithmIdentifier,
            .
            .
            . }

I did ask some ASN.1 specialists and I was told that the keyword
EXPLICIT in this position is not a legal ASN.1 construct.  What does it
mean here?

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

2)  The following is never used in the definition:

supportedAlgorithms ATTRIBUTE ::= {
        WITH SYNTAX SupportedAlgorithm
        EQUALITY MATCHING RULE algorithmIdentifierMatch
        ID { id-at 52 } }

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

3) Would it be possible to give me some hints on how to construct the
EXTENSION table and the ALGORITHM table.

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

Thanks for any help,

Rodrigo Botafogo

Date: Mon, 4 May 1998 15:10:36 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

 >> From: Stephen Kent <[email-masked]>
 >> 
 >> When we encode anything as a DN it becomes part of the DN space,
 >> for which ITU claims responsibility, but for which we lack an
 >> authoritative registrar.

 David> ...
 David> Note that Part 1 defines DistinguishedName ::= RDNSequence,
 David> but DistinguishedName is *never* used.  The subject and issuer
 David> fields of Certificate are Name, not DistinguishedName.  The
 David> syntax is the same, but the argument can be made that the IETF
 David> has the right to define its own attributes which may appear in
 David> RDNSequence, and to serve as the registrar for it's own
 David> namespaces.

If that's valid, it certainly is not intuitive.  Applying the duck
test ("if it walks like a duck...") on the subject name would
certainly lead many people to believe that those things are
distinguished names controlled by ITU.

If that assumption is true only for some subject names and not others
(i.e., we're applying the ITUish syntax withouth also applying its
semantics) then this deserves to be pointed out very clearly.  In
particular, it becomes critical to spell out which portion of the name 
space is controlled by which registrar (real or hypothetical).

DNS names have the nice property that "everyone knows" where they come 
from.  When I see "X=foo, Y=bar" I immediately think "ITU X.mumble"
with all that seems to imply.

	paul

From: Peter Sylvester <[email-masked]>
Date: Mon, 4 May 1998 19:34:37 +0200
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

I have written this comment without reading the thread title.
having done so and assuming that the text contains some
not completely unuseful information, I send the message anyway.

> 
> I am requesting that RFC2247 names (or a functional equivalent)
> be explicitly allowed as Distinguished Names in the "subject"
> and "issuer" name fields.
> 
Subject field should contain anything you want. It is questionable
whether one should impose any restriction on subjects. The CA
(or the associated RA or naming authority) publishes its naming
plan anyway (or should plan it), otherwise it would be somewhat
difficult to interprete the content of the subject naming fields.
All X.509v3 should be allowed (not necessarily new extensions
with almost private oids)

A CA can decide to use DN or other naming extension
in whatever weird way as long as internal the names are ok and
permit (to them) to find the individual etc, and to issue new
certs for the same individual. 

Restrictions of issuer names and subject names may be the only
way to organise a conspiracy of cooperating CAs, in whatever
cross-certification environment you might imagine. Are we (who 
ever this might be?) in this context?

The problem is not really the naming in the certs,
the problem are applications (IMHO). It seems that one tries
to solve a hen and egg problem by first creating a global
unique naming structure for everything and everybody (big brother,
please leave me alone that), and then of course this automagically
solves many addressing and naming problems in applications,
finding CAs, subjects and so on. 

Reality might be different: the banking environment gives me a cert,
THEY choose their naming convention, the administration who wants
me to sign tax declarations will give me a cert. THEY choose THEIR
naming convention, my electronic passport cert (bar or ocr coded 
on a real passport :-) ) again has its own naming conventions. 

Ah, well, I forgot to read the title of the thread: 

I am not sure whether a service to OBTAIN a cert and
its status based on some info other than the cert
itself is really necessary. If an application already
knows the issuer, the subject (how?), wouldn't it be
so unreasonable to assume that it already a cert? 

The counter example is a REAL passport (at least an EU one):
one the passport there is enough information to identify
the subject (in a multinational environment), but there
is of course no cert. 

So be it. Is it necessary to fully specify the required information
in the OCSP protocol: The protocol description could just say
that the requestor gives a list of something like AVAs.
and that these "AVAs" should be sufficient to identify an entity. 
Specifying a concrete set of such "avas" seems too restrictive
to me. Doesn't this belong to a policy statement or cps? 

Peter Sylvester -- EdelWeb France

Date: Mon, 4 May 1998 12:55:06 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

> From: Stephen Kent <[email-masked]>
>
> When we encode anything as a DN it becomes part of the DN space, for which
> ITU claims responsibility, but for which we lack an authoritative
> registrar.

I see.

The question in my mind remains "can X.509 be used outside the context
of the X.500 directory?".  Or, does the IETF, which defines the syntax
of Name, RDNSequence, and RelativeDistinguishedName in PKIX Part 1,
somehow have a sub-rosa importation of the semantics of Directory
(or Distinguished) Names from X.500, including a requirement to use
the ITU as a registrar?

Note that Part 1 defines DistinguishedName ::= RDNSequence,
but DistinguishedName is *never* used.  The subject and issuer
fields of Certificate are Name, not DistinguishedName.  The syntax
is the same, but the argument can be made that the IETF has the right
to define its own attributes which may appear in RDNSequence, and
to serve as the registrar for it's own namespaces.

I would put forth the claim that a Name which began with "C=" would be
registered under the ITU, a Name which began with "DC=" would be
registered under the IETF, and a Name which began with a private
attribute "FOO=" would be registered under the organization which owns
the attribute's OID.

Dave Kemp

Date: Mon, 04 May 1998 11:17:05 -0500
From: Dale Gustafson <[email-masked]>
Organization: Datakey, Inc.
To: Marc Branchaud <[email-masked]>
CC: Ambarish Malpani <[email-masked]>, [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
Sender: [email-masked]

I think I agree with Marc :-)

Also, the standard should not preclude service providers from performing some
type of "synchronous" read of the CA database entry for the certificate in
question before returning the current cert-status within it's response.  It's
probably not a good idea to create a protocol that makes two distinctly different
services appear to be the same:

 1) read current CA cert-status
 2) read CRL(s), copies of CA data, etc.

BTW, are there other documents that present the big picture with respect to how
OCSP will scale over time?  I suspect that no matter how this is implemented
there will be a lot of wasted bandpass if clients always have to poll  for
cert-status.  Most OCSP transactions will result in "dry polls" that return no
new information to the cert user (e.g., cert-status hasn't changed since the last
time it was checked).

Intuitively, for OCSP to scale effectively there also needs to be a way to
proactively deliver cert-status updates to users of all kinds.  Presumably, such
updates would only be created/sent when a cert-status actually changes.  I assume
a push capability for cert-status could be the subject of another document
if/when appropriate.

Regards,

Dale Gustafson
Datakey, Inc.
407 West Travelers Trail
Burnsville, MN 55337
612.808.2360
612.890.2726 fax

------------------------
Marc Branchaud wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
>
> Content-Type: text/plain; charset=us-ascii
>
> Ambarish Malpani <[email-masked]> scrawled:
> >
> > Hi Marc,
> >     I don't agree with your first sentence. A CA might have a policy of
> > only updating its database periodically (for example because it keeps
> > the database itself offline and a read-only copy online). In that case,
> > even a responder that has direct access to the CAs database, might
> > still want to set nextUpdate.
> >
>
> It seems we have a different idea of what "direct access" means.  I won't
> debate that here, but consider that the meaning of nextUpdate in this case is
> different than it is in the CRL world.  In this case, there's no possibility
> of fresh information being available before nextUpdate.  As such, a client
> might get confused and apply CRL-like semantics to the value, and might try
> to query the responder before nextUpdate even though there's no way that any
> new information will be returned.
>
> I'm not saying that this "update period" information is unimportant or
> useless.  But stuffing it into a field that is to be interpreted the same
> way as a CRL's nextUpdate value is wrong.
>
> > In a spec like this, I would rather tell people what it means if they
> > do something rather than dictate policy to them.
> >
>
> I agree completely.  That's why I'm arguing so much about this stuff.
> nextUpdate has to be made clear or it will get misinterpreted and people
> will get burned by it.
>
>                 Marc
>
> +------------------------------------------------------------------------+
>  Marc Branchaud                                  \/
>  Chief PKI Architect                             /\CERT INTERNATIONAL INC.
>  [email-masked]        PKI References page:              www.xcert.com
>  604-640-6227          www.xcert.com/~marcnarc/PKI/
> +------------------------------------------------------------------------+
>   PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQB1AwUBNUpTS1rdFXNdDxPlAQHtwQMAlk3n1JOSr7Qjn/oWHF4ndBPPOcQr/2xn
> boOytgmivp0uoufW9tFS1hWubO8gAD4UJ5EbeZV7qu8Y1uQ4d5Xcl5ulG587v/0K
> fwcrXYR89qZvM9pK9D+WIo2GuVZyXFIa
> =Obaz
> -----END PGP SIGNATURE-----

Date: Mon, 4 May 1998 11:52:32 -0400
To: [email-masked] (David P. Kemp)
From: Stephen Kent <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Cc: [email-masked]
Sender: [email-masked]

Dave

>I would note that this is not an argument for or against the encoding
>of DNS/RFC822/IPAddress names as AltNames.
>
>One of the purposes of the v3 standard extensions is to enable
>separation of the function Naming Authority from the function
>Certification Authority.  In the case of DNS, etc, the existing naming
>mechanisms assign authoritative, unique names.  Those names remain just
>as authoritative and unique when encoded as RDNs
>(e.g. DC=sun, DC=east, DC=bcn, CN=anne) as when encoded as AltNames
>(e.g. DNSName=anne.bcn.east.sun.com).

I disagree, though I understand your point re naming authorities and CAs.
It is a well established distinction in the X.500 arena, but X.500 is not
being widely adopted and we have lost years of possible deployment
opportunities because of the inability of folks to resolve various aspects
of X.500.  Look back at all the traffic re the NADF and ask how we are
better off today as a result.

When we encode anything as a DN it becomes part of the DN space, for which
ITU claims responsibility, but for which we lack an authoritative
registrar.  When the equivalent data is encoded in its appropriate AltName,
it belongs to a space that the ITU acknowledges is managed by another
standards body (IETF for DNS, RFC 822, and IP addresses) and for which we
do have authoritative registrars. Thus it seems both natural and important
that we make use of these name forms.  The mapping to DNs for other name
forms is a hack to accommodate DNS data in X.500 directories.  PKIX
explicitly acknowledges that we are developing certificate standards that
do not rely on the existance of X.500 directories.

Steve

Date: Mon, 4 May 1998 10:56:23 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[email-masked]>
Reply-To: Anne Anderson - Sun Microsystems <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

There currently is no way to encode DNS and other alternative
names as RDNs that is supported by PKIX.  If there were, then
I agree completely with Dave's argument.

The DC= format is in RFC2247, and this has not been incorporated
into either X.501/X.509 or PKIX.

I am requesting that RFC2247 names (or a functional equivalent)
be explicitly allowed as Distinguished Names in the "subject"
and "issuer" name fields.

-Anne Anderson

>>Date: Mon, 4 May 1998 10:11:44 -0400
>>From: [email-masked] (David P. Kemp)
>>To: [email-masked]
>>Subject: Re: [IETF-PKIX] OCSP: Method of Identifying 
Certificates
>>
>>> From: Stephen Kent <[email-masked]>
>>> 
>>> On a separate note: Bob, I observe that we have essentially no
>>> authoritative sorce for DNs, but we do have authoritative 
sources (existing
>>> infrastrustures) for DNS names, RFC822 names, and IP 
addresses.  These have
>>> a much better basis for authoritative, unique names (modulo 
NAT!) than DNs.
>>
>>Steve,
>>
>>I would note that this is not an argument for or against the 
encoding
>>of DNS/RFC822/IPAddress names as AltNames.
>>
>>One of the purposes of the v3 standard extensions is to enable
>>separation of the function Naming Authority from the function
>>Certification Authority.  In the case of DNS, etc, the existing 
naming
>>mechanisms assign authoritative, unique names.  Those names 
remain just
>>as authoritative and unique when encoded as RDNs
>>(e.g. DC=sun, DC=east, DC=bcn, CN=anne) as when encoded as 
AltNames
>>(e.g. DNSName=anne.bcn.east.sun.com).
>>
>>Dave Kemp

Anne Anderson                  Email: [email-masked]
Sun Microsystems Laboratories  Tel: (978) 442-0928
2 Elizabeth Drive, CHL03-205   Fax: (978) 250-5067
Chelmsford, MA 01824 USA

Date: Mon, 4 May 1998 10:11:44 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

> From: Stephen Kent <[email-masked]>
> 
> On a separate note: Bob, I observe that we have essentially no
> authoritative sorce for DNs, but we do have authoritative sources (existing
> infrastrustures) for DNS names, RFC822 names, and IP addresses.  These have
> a much better basis for authoritative, unique names (modulo NAT!) than DNs.

Steve,

I would note that this is not an argument for or against the encoding
of DNS/RFC822/IPAddress names as AltNames.

One of the purposes of the v3 standard extensions is to enable
separation of the function Naming Authority from the function
Certification Authority.  In the case of DNS, etc, the existing naming
mechanisms assign authoritative, unique names.  Those names remain just
as authoritative and unique when encoded as RDNs
(e.g. DC=sun, DC=east, DC=bcn, CN=anne) as when encoded as AltNames
(e.g. DNSName=anne.bcn.east.sun.com).

Dave Kemp

Date: Sat, 02 May 1998 17:38:05 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-ipki-part4-03.txt
Sender: [email-masked]

For the information of the list, this newly-posted I-D is the final version
of the "Part 4" document, for forwarding to the RFC Editor with a request
for publication as an Informational RFC as agreed in Washington.  Changes
since the 02 version are all editorial in nature.

Warwick

At 10:01 AM 4/29/98 -0400, [email-masked] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the Public-Key Infrastructure (X.509) Working
Group of the IETF.
>
>	Title		: Internet X.509 Public Key Infrastructure 
>                          Certificate Policy and Certification Practices
Framework
>	Author(s)	: W. Ford, S. Chokhani
>	Filename	: draft-ietf-pkix-ipki-part4-03.txt
>	Pages		: 45
>	Date		: 28-Apr-98

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Date: Sat, 2 May 1998 11:27:42 -0400
To: Anne Anderson - Sun Microsystems <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Cc: [email-masked]
Sender: [email-masked]

Folks,

I agree with Anne, which is why I am still opposed to mandating use of a DN
in the Issuer field for ALL PKIX compliant certs.  We ought not be putting
DNS names, Ip addresses, and RFC 822 names in DNs after having gone to the
trouble of creating altName construsts to accommoadte them.  DNs are
already mushy enough (see my comment below wrt who is authoritative for
DNs) without further complicating matters.

The primary arguments in favor of this seem to be based on three valid, but
remediable, concerns (although I admit to having been out of touch and
maybe I missed a different class of concern):

	1. we have other protocols (e.g., S/MIME and TLS) that refer only
to DNs (rather than altnames) in several places for processing

	2.  we have repositories (e.f., LDAP) that use DNs as indices

	3. internal to PKIX part 1, we have instances where we assume an
issuer DN (e.g., for one choice of how we do back pointers from a subject
to an issuer cery)

In the case of 1, we can fix this by having the protocols deal with either
the base cert fields or altName fields.  After all, if we don't start doing
this at some time, why bother having altName fields anyway.  For case 2, I
note that LDAP is not the only game in  town.  We have a profile for
storing certs and CRLs in DNS and it knows how to make use of DNS names and
IP addresses as indices.  Thus it seems unduly narrow to mandate use of DNs
for all PKIX certs when there are other, well-established repositories that
are oriented toward other indices.  Finally, we can fix PKIX part 1 to be
more liberal in dealing with issuer name forms.  After all, it's our
standard and we can fix it.

On a separate note: Bob, I observe that we have essentially no
authoritative sorce for DNs, but we do have authoritative sources (existing
infrastrustures) for DNS names, RFC822 names, and IP addresses.  These have
a much better basis for authoritative, unique names (modulo NAT!) than DNs.

Steve

To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt 
Date: Fri, 01 May 1998 15:57:40 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

 <[email-masked]> scrawled:
> 
> I agree with Mike and Paul that the first three sentences (not lines)
> be deleted.  I also believe that the final sentence should go, because
> it is content-free: it doesn't add anything to the specification to
> say clients SHOULD (or MUST) use their own local policies - what else
> would they use?

Just because it's obvious to us technocrats doesn't mean that it shouldn't 
be spelt out in the standard.  We shouldn't assume that everyone reading 
the document will know these things.

> If the implication is that clients SHOULD have a local
> policy of ignoring the contents of nextUpdate, I strongly disagree.
> 

Happily, that isn't what I'm getting at.  Clients can and will have a local 
policy that tells them how to interpret things.  If we're going to allow a
nextUpdate field, we have to be very clear about what it means so that 
clients' policies aren't mislead.

> I believe that nextUpdate should be recommended (SHOULD) rather than
> purely optional (MAY).  Other than that, I agree with the center
> sentence of Marc's proposed text.  Which leaves:
> 
>   The nextUpdate field SHOULD be included in the response.
>   When it is included, the nextUpdate field indicates that fresh
>   revocation information will be available no later than the specified
>   time, and may be available sooner.
> 

Making it a SHOULD will cause interoperability problems.  Implementations 
for which nextUpdate is meaningless will be forced to include a dummy 
nextUpdate value to be compatible with all the clients that think that 
nextUpdate SHOULD be there and so they're not the ones that are broken.

nextUpdate has to be OPTIONAL.  How's about this:

  The nextUpdate field MAY be included if the responder has an accurate
  estimate of the latest time at which it will receive fresh information.
  When it is included, the nextUpdate field indicates that fresh revocation
  information will be available no later than the specified time, and may be
  available sooner.  The value of nextUpdate SHOULD NOT be interpreted to
  imply anything about the duration of a response's validity.  Client
  implementations MUST be able to process responses with or without a
  nextUpdate value.

That last sentence is an implication of the optional nature of the field, but
I think it's important because it emphasizes that client's shouldn't just 
blindly rely on nextUpdate.  That'll be more likely to happen if clients are 
told to expect respopnses that might not have a nextUpdate value.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

To: Ambarish Malpani <[email-masked]>
Cc: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt 
Date: Fri, 01 May 1998 15:57:16 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

Ambarish Malpani <[email-masked]> scrawled:
> 
> Hi Marc,
>     I don't agree with your first sentence. A CA might have a policy of
> only updating its database periodically (for example because it keeps
> the database itself offline and a read-only copy online). In that case,
> even a responder that has direct access to the CAs database, might
> still want to set nextUpdate.
> 

It seems we have a different idea of what "direct access" means.  I won't
debate that here, but consider that the meaning of nextUpdate in this case is
different than it is in the CRL world.  In this case, there's no possibility
of fresh information being available before nextUpdate.  As such, a client
might get confused and apply CRL-like semantics to the value, and might try
to query the responder before nextUpdate even though there's no way that any
new information will be returned.

I'm not saying that this "update period" information is unimportant or 
useless.  But stuffing it into a field that is to be interpreted the same 
way as a CRL's nextUpdate value is wrong.

> In a spec like this, I would rather tell people what it means if they
> do something rather than dictate policy to them.
> 

I agree completely.  That's why I'm arguing so much about this stuff.  
nextUpdate has to be made clear or it will get misinterpreted and people 
will get burned by it.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date: Fri, 01 May 1998 15:14:08 -0700
To: [email-masked] (David P. Kemp), [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate,   producedAt
Sender: [email-masked]

I agree with Dave's proposed text.

Are there any furhter comments out there on Ambarish's positions?  We want
to get these issues off the table for a new draft.

At 01:45 PM 5/1/98 -0400, David P. Kemp wrote:
>> From: Paul Hoffman / IMC <[email-masked]>
>> 
>> At 03:34 PM 4/30/98 -0700, Michael Myers wrote:
>> >For these reasons, I would agree with the proposed text with the first
>> >three lines deleted.  There is no way for anyone to implement a client
that
>> >would enforce them.
>> 
>> I agree with Mike. The source of the data is not important here, and trying
>> to force heuristics on it seems inappropriate.
>
>I agree with Mike and Paul that the first three sentences (not lines)
>be deleted.  I also believe that the final sentence should go, because
>it is content-free: it doesn't add anything to the specification to
>say clients SHOULD (or MUST) use their own local policies - what else
>would they use?  If the implication is that clients SHOULD have a local
>policy of ignoring the contents of nextUpdate, I strongly disagree.
>
>I believe that nextUpdate should be recommended (SHOULD) rather than
>purely optional (MAY).  Other than that, I agree with the center
>sentence of Marc's proposed text.  Which leaves:
>
>  The nextUpdate field SHOULD be included in the response.
>  When it is included, the nextUpdate field indicates that fresh
>  revocation information will be available no later than the specified
>  time, and may be available sooner.
>
>
>This is consistent with PKIX part 1 section 5.1.2.5, which says:
>
>  This field indicates the date by which the next CRL will be issued.
>  The next CRL could be issued before the indicated date, but it will
>  not be issued any later than the indicated date.
>
>
>

From: Stephen Samson <[email-masked]>
To: [email-masked]
Subject: Entrust Technologies Announces License Terms for CRL Distribution Points Patent
Date: Fri, 1 May 1998 15:14:27 -0400 
Sender: [email-masked]

My personal apologies for any difficulty you have encountered accessing the
summary of license terms.

Entrust Technologies previously published the information in PDF file format
on our website. (I personally checked the links over 20 times on our
internal site in order to be convinced there would be no problems when we
published live.) Nevertheless, subsequent to the posting, we have been
informed that some browsers do not support the PDF version we used. To
correct the problem, the summary is now published in HTML so you should be
able to view regardless of the browser being used.

Please follow the link below to our announcement and then follow either
pointer named "view now" or "view". Thank you for your patience and
understanding.

Steve Samson

> ----------
> From: 	Stephen Samson
> Sent: 	30 April, 1998 1:26 PM
> To: 	[email-masked]'
> Cc: 	'Jeff Schiller'; 'Steve Kent'; 'Tim Polk'; 'Warwick Ford'
> Subject: 	Entrust Technologies Announces License Terms for CRL
> Distribution Points Patent
> 
> Members of the IETF Community;
> 
> Entrust Technologies is very pleased to provide details of its previously
> announced royalty-free license for the CRL Distribution Points Patent.
> 
> By following the link:  http://www.entrust.com/products/patent.htm to our
> website, you will be able to read a summary of the license terms. In the
> spirit of open Standards, Entrust has fashioned the license in fair,
> reasonable and equitable terms that should appeal to all interested
> parties.
> 
> A party interested in taking a license should contact the author directly,
> so that appropriate license documentation can be drafted. Please direct
> any questions to:
> 
> Steve Samson
> 
> Entrust Technologies Inc.
> 750 Heron Rd.,  8th Floor
> Ottawa, Ontario, Canada, K1V 1A7
> 
> voice:			613-247-3725
> fax:			613-247-3412
> email:			[email-masked]
> Entrust Validation String:	SCKM-HQDL-X75G
> 

From: Carlisle Adams <[email-masked]>
To: Stephen Samson <[email-masked]>, [email-masked], "'Michael Myers'" <[email-masked]>
Cc: Jeff Schiller <[email-masked]>, Steve Kent <[email-masked]>, Tim Polk <[email-masked]>, Warwick Ford <[email-masked]>
Subject: RE: Entrust Technologies Announces License Terms for CRL Distribu tion Points Patent
Date: Fri, 1 May 1998 14:59:19 -0400 
Sender: [email-masked]

All,

After some frantic searching (and with the kind assistance of some external
interested parties, Paul Hoffman in particular), the problem has been
located.  Last Tuesday we moved our web site from a host that was externally
managed to one that was internally managed.  However, the update to the DNS
mapping tables did not happen correctly and therefore was not being
propagated around the net.  Consequently, when people went to
www.entrust.com they hit the ip address for our old site instead of our new
site.  The result of this was that when we put the patent terms on the site
on Thursday, nobody outside Entrust could see them because they were getting
to our old site (which has not been updated since last Monday because it was
assumed that the DNS servers were mapping people to the new site...).

We've now updated the old site, so everyone should have access to the Ts &
Cs regardless of the site (old or new) to which DNS points you.  We will, of
course, also get the correct update to the mapping tables done ASAP.

We all sincerely apologize for this confusion at such a critical time.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

> ----------
> From: 	Michael Myers[SMTP:[email-masked]]
> Sent: 	Thursday, April 30, 1998 2:14 PM
> To: 	Stephen Samson; [email-masked]
> Cc: 	Jeff Schiller; Steve Kent; Tim Polk; Warwick Ford
> Subject: 	Re: Entrust Technologies Announces License Terms for CRL
> Distribution Points Patent
> 
> Stephen,
> 
> It appears the text is not yet posted at this URL.  On reference, I
> receive
> a page that states:
> 
> "Our Apologies
> 
> This link is either outdated or missing at this time. Please refer
> yourself
> to our homepage or feel free to use the sitemap."
> 
> Mike
> 
> 
> 
> At 01:26 PM 4/30/98 -0400, Stephen Samson wrote:
> >Members of the IETF Community;
> >
> >Entrust Technologies is very pleased to provide details of its previously
> >announced royalty-free license for the CRL Distribution Points Patent.
> >
> >By following the link:  http://www.entrust.com/products/patent.htm to our
> >website, you will be able to read a summary of the license terms. In the
> >spirit of open Standards, Entrust has fashioned the license in fair,
> >reasonable and equitable terms that should appeal to all interested
> parties.
> >
> >A party interested in taking a license should contact the author
> directly,
> >so that appropriate license documentation can be drafted. Please direct
> any
> >questions to:
> >
> >Steve Samson
> >
> >Entrust Technologies Inc.
> >750 Heron Rd.,  8th Floor
> >Ottawa, Ontario, Canada, K1V 1A7
> >
> >voice:			613-247-3725
> >fax:			613-247-3412
> >email:			[email-masked]
> >Entrust Validation String:	SCKM-HQDL-X75G
> >
> >
> 

Date: Fri, 01 May 1998 10:54:18 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
Sender: [email-masked]

Hi Marc,
    I don't agree with your first sentence. A CA might have a policy of
only updating its database periodically (for example because it keeps
the database itself offline and a read-only copy online). In that case,
even a responder that has direct access to the CAs database, might
still want to set nextUpdate.

In a spec like this, I would rather tell people what it means if they
do something rather than dictate policy to them.

Regards,
Ambarish

Marc Branchaud wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Content-Type: text/plain; charset=us-ascii
> 
> Mike, Paul;
> 
> Yer right, specifying just "CRL" is way too restrictive.  Just to make sure
> we agree, the text is the same as before with the first two sentecnes
> removed, i.e.:
> 
>   The nextUpdate field SHOULD NOT be included if the responder has direct
>   access to the CA's revocation database (i.e. it can obtain revocation
>   information in real time).  When it is included, the nextUpdate field
>   SHOULD be interpreted to mean that fresh revocation information should be
>   available no later than nextUpdate's time, and may be available sooner.  In
>   general, nextUpdate is not a guarantee of the lifetime of a response's
>   validity.  Clients SHOULD use their own local policies to determine how
>   long they believe a response to be valid, regardless of the presence of the
>   nextUpdate field in the response.
> 
> S'cool?
> 
>                 Marc
> 
> 
-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Fri, 1 May 1998 13:45:56 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate,  producedAt
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> 
> At 03:34 PM 4/30/98 -0700, Michael Myers wrote:
> >For these reasons, I would agree with the proposed text with the first
> >three lines deleted.  There is no way for anyone to implement a client that
> >would enforce them.
> 
> I agree with Mike. The source of the data is not important here, and trying
> to force heuristics on it seems inappropriate.

I agree with Mike and Paul that the first three sentences (not lines)
be deleted.  I also believe that the final sentence should go, because
it is content-free: it doesn't add anything to the specification to
say clients SHOULD (or MUST) use their own local policies - what else
would they use?  If the implication is that clients SHOULD have a local
policy of ignoring the contents of nextUpdate, I strongly disagree.

I believe that nextUpdate should be recommended (SHOULD) rather than
purely optional (MAY).  Other than that, I agree with the center
sentence of Marc's proposed text.  Which leaves:

  The nextUpdate field SHOULD be included in the response.
  When it is included, the nextUpdate field indicates that fresh
  revocation information will be available no later than the specified
  time, and may be available sooner.

This is consistent with PKIX part 1 section 5.1.2.5, which says:

  This field indicates the date by which the next CRL will be issued.
  The next CRL could be issued before the indicated date, but it will
  not be issued any later than the indicated date.

Date: Fri, 1 May 1998 12:37:33 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[email-masked]>
Reply-To: Anne Anderson - Sun Microsystems <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

I think it is unreasonable to require ALL applications to use
X.501-style names UNLESS there is support for conversion of
alternate names to an X.501 format, such as RFC2247.

Example: Using DNS as my PKI certificate repository

In this case, I am known as "anne.bcn.east.sun.com".  My PKI
hierarchy may look as follows:

  CA "sun.com" issues and stores certificates for
     CA "east.sun.com", which issues and stores certificates for
        "CA bcn.east.sun.com", which issues certificates for
           "anne.bcn.east.sun.com"

The DNS protocols know how to find "anne.bcn.east.sun.com", "bcn.east.sun.com",
"east.sun.com", and "sun.com" from any host that supports DNS.  DNS is a working
global naming hierarchy and repository (sort of what X.500 wanted to be, but 
never became, although more specialized).

If DNS does what I need (and in this case it does), why should I have to
make up a set of X.501 Distinguished Names that have no
function in either locating the certificates that I need or in
reflecting the trust chain?  I would rather leave issuer and subject
empty, and user issuerAltName and subjectAltName with the DNS names
and chain through them.  If I present a server with a DNS name, I
would like the server to be able to locate my certificate using that
name and to verify the certificate chain using that name.

If all names must be expressible in X.501 format, then at least allow
RFC2247 names (e.g. DC=sun, DC=east, DC=bcn, CN=anne) !!!

Anne Anderson                  Email: [email-masked]
Sun Microsystems Laboratories  Tel: (978) 442-0928
2 Elizabeth Drive, CHL03-205   Fax: (978) 250-5067
Chelmsford, MA 01824 USA

To: Michael Myers <[email-masked]>
Cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt 
Date: Fri, 01 May 1998 09:16:02 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

Mike, Paul;

Yer right, specifying just "CRL" is way too restrictive.  Just to make sure
we agree, the text is the same as before with the first two sentecnes
removed, i.e.:

  The nextUpdate field SHOULD NOT be included if the responder has direct
  access to the CA's revocation database (i.e. it can obtain revocation
  information in real time).  When it is included, the nextUpdate field
  SHOULD be interpreted to mean that fresh revocation information should be
  available no later than nextUpdate's time, and may be available sooner.  In
  general, nextUpdate is not a guarantee of the lifetime of a response's
  validity.  Clients SHOULD use their own local policies to determine how
  long they believe a response to be valid, regardless of the presence of the
  nextUpdate field in the response.

S'cool?

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date: Fri, 01 May 1998 09:57:57 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Denis,

I would like to restrict the means of identifying the certificate to the =
Issuer DN,
Hash(IssuerPublicKey) and CertSerialNumber, as opposed to allowing =
either=20
the DN or the altSubjectName.

The reason is that I do not believe that we have a well-understood and
adequate characterization of the semantics of alternate names at present =
to
be sure that they are globally unique, and hence we cannot be sure that=20
they will serve the purpose intended.

I will start another thread on the subject of alternate name semantics to =
avoid
cluttering this one, but I have not seen anyone advance a compelling =
argument
as to why DNs are not sufficient, nor any good reason why a CA would not
always have a DN (as opposed to end entities.)

DNs are sufficient, they are always there, and the use of a single DN=20
for database indexing purposes is much more definitive that having=20
to index all possible alternate names, just in case that's the way the =
certificate=20
is to be identified.

What possible advantage would be gained from using alternate names=20
in this context?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,=20
although a step in the right direction, will not prove=20
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

>>> Denis Pinkas <[email-masked]> 04/30 12:12 PM >>>
Ambarish Malpani wrote:
=20
> Hi All,
>     Would like to get closure on the method of identifying
> certificates. I think nobody has any objections to including the
> issuer's public key in the information that is used to identify the
> issuer. The main point of contention is whether to send the whole
> DN or the hash of the DN.
>=20
> Tim, hopefully your issue with sending over the hash of the DN can
> be addressed by canonicalizing the issuer's DN before hashing it
> (are there any such canonicalization rules)?
>=20
> So, here are the options:
>=20
> 1. Hash(IssuerDN and IssuerPublicKey) and CertSerialNumber
> 2. Hash(IssuerDN), Hash(IssuerPublicKey) and CertSerialNumber
> 3. IssuerDN, Hash(IssuerPublicKey) and CertSerialNumber

>From the option that are proposed, option 3 is the only one that is
working for all environments.=20

The argument is that neither Hash(IssuerDN) nor Hash(IssuerDN and
IssuerPublicKey) can be used to find which CA has issued a certificate
unless you get an hint by some other means.

In the option 3, we should allow either IssuerDN or alternate name to be
used, since I do not think it is appropriate to mandate DNs for CAs (no
argument has been given on the list up to now to explain why DNs would
work better that alternate names as long as the latter are unique).

Regards,

Denis

> What are the opinions of the group? I would like to have a quick
> flurry of opinions before we decide to go one way or the other.
>=20
> Regards,
> Ambarish

--=20
      Denis Pinkas     Bull S.A.          mailto:[email-masked]=20
      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

From: [email-masked]
DATE: 30 May 98 8:54:12 PM
TO: [email-masked]
SUBJECT: Jazz It Up
Sender: [email-masked]

   LET US DO YOUR BULK E-MAIL ADVERTISING!!!

$600 PER MILLION (5 MILLION OR MORE $500 PER MILLION)
$450 PER 1/2 MILLION
These prices are non-targeted.

THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS!

Let our company do mailing for your product/service, 
newsletter/report or client list.

Addresses are extracted 24 hours a day 7 days a week, 
scanning the net for new addresses.  Estimated 
150-200,000 addresses extracted daily.  They are fresh!  
Over 55 million addresses on file.

No more than 2 pages (50 lines), no porn, no sexual 
relative material and no foul language.  Each ad must 
be no more than 50 characters wide by 50 lines deep.

***Targeted mailings: 
$200 per 50,000 addresses or less extracted.
$125 per 25,000 addresses or less extracted.
We can extract by city, country, occupation, 
organizations, associations, product, website, state, 
megatags (keywords), etc.  If we can not search and 
extract what you need, then nobody can.  No one can 
target your mailing for less.

***AND NOW WE CAN EXTRACT BY CITY!

If interested in purchasing targeted addresses:
$10 per 1,000 up to 100,000 (min. 10,000)
$7.50 per 1,000 over 100,000 & up to 500,000
$5.00 per 1,000 over 500,000

***SPECIAL*** Targeted US ADDRESSES ONLY $750 per 1/2 
million.  A savings of $1,250.  We have over 10 million 
addresses, non AOL, and collecting more each day.

There are no lower prices on the net.  Your mailing 
can be done in a matter of hours, instead of days.  

For the fastest service, cheapest prices and cleanest
mailings call our processing and new accounts department
at 904-282-0945, Monday - Friday 9 - 5 EST.  If the line 
is busy or no answer, please keep trying, as bulk mailing 
is growing fast.  We do want to work with you to advertise 
your product.  Check out our prices and compare with 
other bulk emailers, you will find we have the BESt prices 
anywhere.  In fact, we do bulk mailings for many other 
bulk emailers.

To have yourname@domain removed, call our processing 
department.  Any negative responses will be dealt with 
accordingly.

Date: Fri, 29 May 1998 11:10:13 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: INFORMATION SECURITY COMMITTEE MEETING NOTICE
Sender: [email-masked]

For the information of list subscribers...

------------------
INFORMATION SECURITY COMMITTEE MEETING NOTICE
                                      June 16-18, 1998
                                        Linthicum, MD

Please correspond with: 
     Michael S. Baum, Esq. 
     1390 Shorebird Way
      Mountain View, CA  94043
      V: +1 650-4293444 
      F: +1 617-961-7300 
      N: [email-masked] 

Dear Committee Member and Prospective Members: 

     You are cordially invited to participate in a meeting of the
Information Security Committee, Section of Science & Technology, American
Bar Association, on June 16-18 1998 (Tuesday through Thursday). Sponsored
by the National Security Agency, the meeting will be held at the Double
Tree Guest Suites Hotel BWI and the Merchant Institute in Linthicum,
Maryland (by the Baltimore-Washington Airport). The Committee will continue
its advancement of public key infrastructure legal and control issues, and
will include further work on CA accreditation, commercial key recovery
guidelines, PKI evidentiary issues, certificate policy, and user liability,
among other matters. 

     Consistent with Section policy, ISC meeting participants must be
members of both the ABA and the ABA Section of Science and Technology.
Please contact Ann Kowalsky, Manager Section of Science & Technology, at
ABA headquarters in Chicago by phone: +1 (312) 988.5599, fax: +1 (312)
988.5628, or email:  [email-masked] for membership information. You
can become a paid member of the ABA and the ISC at the June 16-18 meeting
-- and associate ABA membership is available for non-lawyers. 

     Special thanks to Jan Manning and Theresa Wheeler of the NSA's
Security Management Infrastructure Office (X3), Network Security Group (X)
for their efforts to coordinate this meeting, including the planned social
at the NSA's Cryptologic Museum, and their facilitation of the NSA
sponsorship. It is greatly appreciated.

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

     Sincerely, 

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

                                                  Proposed Agenda
                           INFORMATION SECURITY COMMITTEE
                              Section of Science & Technology, ABA
                                                   16-18 June 1998

     Proposed Agenda (in extended sessions, breaks will be taken as needed.) 

     16 June 1998	 Tuesday (business attire recommended for all sessions) 
     08:30 - 09:00	Greetings, coffee, administrative matters (note: all
times are "local") 
     09:00 - 09:30	Introductions, meeting logistics, general announcements 
     09:30 - 1030	Working Group updates 
     10:30 - 12:00	WG breakouts 
     12:00 - 13:00	Lunch speaker: Jim Wallner, Sr. Security Analyst, NSA
"Threat and Vulnerability Model
 for A Public Key Infrastructure"(tentative)
     13:00 - 17:00	WG breakouts 
     17:00 - ????	Watering hole discussions; possible continuation of WG
meetings 

     17 June1998 - Wednesday 
     08:30 - 09:00 Greetings, coffee, administrative matters 
     09:00 - 09:30 Updates -- logistics, administrative, WG related, etc. 
     09:30 - 12:00 WG breakouts 
     12:00 - 13:00 Lunch speaker: TBD
     13:00 - 17:00 WG breakouts 
     18:30 - 20:20  Social event: Reception at the NSA Cryptologic Museum,
hosted by the National Security 
Agency. Bus transportation to the Museum provided from/to the Doubletree.
Bus departs
 from the hotel at ~18:30 and departs from the Museum at 20:30.

     18 June 1998 - Thursday 
     08:30 - 09:00 Greetings, coffee, administrative matters 
     09:00 - 09:30 Updates -- logistics, administrative, WG related, etc. 
     09:30 - 12:00 WG breakouts 
     12:00 - 13:00 Lunch speakers: Dean Adams, The Open Group; John
Nagengast, Chief Network Security
Group, NSA, "The DoD's Information Assurance Program" 
     13:00 - 15:00 WG wrap-ups 
     15:00 - 16:00 WG presentations 
     16:00 - 16:30 Path Forward, close 

     Additional proposed agenda items and speakers should be E-mailed to
Michael Baum ([email-masked]). 

                                            Working Groups
                                 Information Security Committee
          Electronic Commerce Division, Section of Science and Technology
                                      MEETING DETAILS
                                         16-18 June 1998

     Members are urged to participate in at least one of the Working Groups
that will be presenting/meeting during the ISC's meeting. Please contact
Ruven Schwartz, committee vice chair, or a working group co-chair directly,
for further information. 

     **Accreditation Working Group 
     Contacts: Bill Burr ([email-masked]) 
     Charlie Merrill, Esq. ([email-masked]) 
     Lynn McNulty ([email-masked]) 

     The Accreditation WorkGroup will continue work on its draft document,
with a view toward distributing a draft on the Internet for industry
comments by year-end.  An ad hoc editorial group recently met in NYC to
restructure the material and suggest a more descriptive title for the work
as follows: "PKI Evaluation Guidelines--A Process to Assure Trustworthy PKI
by Developing Certificate Policies and Accreditation Guidelines for
Evaluators of CAs and other PKI Components."  The editorial group also
considered a suggested extension to Section 2 of the Chokhani-Ford
Framework, providing more detail for treatment of legal issues, as well as
certain other adjustments to reflect the life-cycle of a certificate.  At
and prior to the June meeting, members of the Accreditation WG will have
the opportunity to review the editorial group's suggestions and continue
drafting assigned sections following the structure of the Framework and
some model provisions which will be distributed in advance.

     **Audit and Controls Working Group
     Contact: Kevin Coleman ([email-masked])
     Charles Le Grand ([email-masked])

     The Audit and Controls Working Group will continue to focus on the
requirements for the audit of certificate authorities, defining the audit
scope, model audit program, extent of test work and form of reporting.

     **Certificate Services Agreements Working Group 
     Contacts: Kevin O'Neill ([email-masked]) 
     Stephen Wu ([email-masked]) 

     The Certification Services Agreements Work Group is charged with
writing "Certification Services Agreements," which is an outgrowth of the
ISC's accreditation and cert. policies activity. The purpose of
"Certification Services Agreements" is to assist the authors of a
certificate policy definition, certification practice statement, subscriber
agreement, relying party agreement, or other agreement relating to
certification services by providing model forms and a menu of alternative
legal wording for use in particular clauses of such documents. The document
will include comments and annotations to the Guidelines for Certificate
Policies and Accreditation Criteria. The group will review the current
draft of the document and discuss plans for further development.  The group
will also advance their draft "Cross-Certification" Agreement."

     **Comparative Law Working Group 
     Contacts: Serge Parisien, Esq. ([email-masked]) 
     Suzanne Thibodeau ([email-masked])

     The Comparative Law work group will continue its exploration of the
requirements for PKI in civil law and other legal jurisdictions. It will
also continue efforts to harmonize legal infrastructure with the common law. 

     **Digital Signatures Laws & Regulations Working Group 
     Contacts: Kenneth Allen, Esq. ([email-masked]) 
     David Danner, Esq. ([email-masked]) 
     Dan Greenwood, Esq. ([email-masked]) 

     The Legislative and Regulatory Working Group will hold its periodic
conference call, to discuss updates to legislation and regulation regarding
electronic authentication. The Leg./Reg. Working Group will
continue/finalize its study of a need for model regulations to support the
electronic and digital signature legislative laws enacted in several states
to date. 

     **Evidentiary Working Group 
     Contacts: Gary Fresen, Esq. ([email-masked]) 
     Serge Parisien, Esq. ([email-masked]) 

     The Evidentiary Work Group will continue its drafting of the judicial
tutorial (a tutorial for judges to admit technology into evidence) and
report on its coordination activities with record management standards
authorities. The working group members will also assist the other working
groups on their evidentiary issues. 

     **Global Trade Working Group 
     Contacts: Joseph Alhadeff, Esq. ([email-masked]) 
     Lisa Kinard ([email-masked]) 
     Linda Macintosh ([email-masked]) 

     The Global Trade Work Group identifies and collaborates with trade
groups whose work influences secure global trade and reports critical
issues back to the ISC. The WG is developing an overall framework to
structure and analyze secure trade issues; and is preparing an issues
statement concerning cooperation between legal, business and technological
professionals to reduce secure electronic international trade barriers. 

     **Key Recovery Working Group (KRWG) 
     Contacts: Emily Frye, Esq. ([email-masked]) 
     Dwight Olson, Esq. ([email-masked]) 
     Randy Sabett, Esq. ([email-masked]) 

     The KRWG monitors proposed legislation and regulations, both here and
abroad, that address key recovery, and offers comments where appropriate.
The KRWG's major initiative documents the framework and operation of a key
recovery center. Work is in the advanced outline stage and will focus on
fleshing out draft text. In addition, a Task Group convened by Ken Bass,
Esq. will develop and propose general criteria for "trustworthy entities"
to expand the current BXA limitations to banks and certain financial
institutions.

     **Liability Working Group 
     Contacts: Maureen Adamache, Esq. ([email-masked]) 
     Elise Reed, Esq. ([email-masked]) 

     The Liability Work Group will continue its work with the Accreditation
Group on the liability issues, including preparing liability policy
statements and also suitable clauses for inclusion in PKI/CA-user and
PKI/CA cross-certification agreements. It will also continue its analyses
of the liability of application software providers, and for other
(non-digital signature, non-confidentiality encryption) applications of
public key cryptography. Finally, it will consider technical methods of
solving the legal problem of binding relying parties. 

     Logistics

     Recommended attire: business attire at all times.

     First-time participants planning to attend the June 16-18 meeting:
Please contact Ruven Schwartz, ISC ViceChair, at 612-687-8095 or
[email-masked] to coordinate meeting work-product
contributions. 

     Meeting Location: 
June 16 - Doubletree Guest Suites BWI Hotel 
June 17 - Maritime Institute (transportation provided from the Doubletree)
June 17 - Doubletree Guest Suites BWI Hotel

     Meals: Lunches will be provided at cost.

Lodging:  The primary hotel for the Information Security Committee's
meeting is the:

Doubletree Guest Suites BWI Hotel
1300 Concourse Drive
Linthicum, MD  21090
Tel. +1 410-850-0747
Fax. +1 410-850-0895

Free hourly transportation is available to/from the BWI airport.

A block of rooms have been reserved (all rooms in the hotel are suites) for
the evenings of June 15-17. The rooms will be held ONLY until May 25th --
so please reserve immediately!   The one bedroom suites/single cost $126.00
per night, plus tax (the hotels regular published rates are $150.00/suite).
 We recommend that you stay at the Doubletree because the first and third
day of our meeting will be held *in* the hotel (that is, on June 16th and
18th). Request the "American Bar Association's - ABA ISC" special rate.

There will be a one-time ~ $ 95 fee to cover transportation to/from the
Maritime Institute, the Cryptologic Museum, food at the reception, and
lunch for each day of our meeting. 

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

     See you in Linthicum.

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

From: "Peter Lipp" <[email-masked]>
To: "PKIX Mailinglist" <[email-masked]>
Subject: question on Subject Key Identifier ipki-part1-07
Date: Fri, 29 May 1998 10:17:00 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0036_01BD8AEA.EB898300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This document sais:

>The hash shall  be calculated over the value (excluding tag and length) of
the BIT
>STRING subjectPublicKey in the certificate.

I assume that excluding tag and length comes from the fact that this was the
same
in PEM - and PKCS. Currently, PKCS#7 specs changed this behaviour and
tag and length get included into the hash. Wouldn't it make sense to do the
same here
or is there any specific reason not to?

Peter

------=_NextPart_000_0036_01BD8AEA.EB898300
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0036_01BD8AEA.EB898300--

From: "Robert Klerer" <[email-masked]>
To: <[email-masked]>
Subject: comment on draft-ietf-pkix-ipki2opp-07
Date: Thu, 28 May 1998 13:52:36 -0400
Sender: [email-masked]

The concept of "reading" a certificate from a repository as described in
section 6 is insufficient for accommodating the use of alternate names.

In order for an application, such as e-mail, to find the certificate using
it's natural alternate name (RFC822 address or labeledURI), would require a
"search" (section 7).

Why is the classifying a read as a search a problem?  The read SHOULD be
allowed via anonymous access.  (Some current version e-mail clients can
operate only with anonymous access).  The search MAY require authenticated
access, depending of the perception of the propriety of the information.

This misfit of the standard verses the reality, is understandable given the
desire to adhere to ldapv2.  But, this issue forces the implementers to go
through hoops trying to restrict the search to the appropriate information
appropriately.  For example, I feel that it is inappropriate to allow a
wildcard search of my repository on RFC822 address using anonymous access.
I believe that a junk mail mass marketer could easily use this hole to
gather mailing lists and swamping them with junk mail.

Hence my customers who want to use secure mail, would not be happy to be
subjected to a deluge of junk mail.  The widespread availability of
certificates is critical to the success of the pki.

The reason the correction should be made here is to give guidance so that
the certificate requestors would use the same message set (subsets) for the
read by alternate name.  If no action is taken then the risk of the
multiplicity of how requestors execute the read exists and has already
occurred.  So limiting anonymous access to read, reserving search for
authenticated access becomes an insurmountable task.

Date: Thu, 28 May 1998 13:42:05 -0400
From: Gene Passarelli <[email-masked]>
Subject: signoff ietf-pkix
Cc: [email-masked]
Sender: [email-masked]

signoff ietf-pkix

Date: Thu, 28 May 98 13:40:38 EDT
From: Gene Passarelli <[email-masked]>
To: [email-masked]
Subject: signoff ietf-pkix
Sender: [email-masked]

signoff ietf-pkix

From: "Peter Lipp" <[email-masked]>
To: "Ed Gerck" <[email-masked]>, "Tony Bartoletti" <[email-masked]>
Cc: "Carl Ellison" <[email-masked]>, "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Date: Thu, 28 May 1998 17:34:38 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_01DA_01BD8A5E.E38E13A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>>The point being, such paper is at heart "not to be relied upon"
>>in the pure mathematical sense, and yet we do rely upon it, and
>>it works for us "most" of the time.
Yes - and thats what I claim should hold for certificates as well.
If their issuing is based on passports, they obviously must be
less-or-equally reliable though.

>transfer. Further, they are being developed into a useful set of
>protocols which will not be patented (strange as it may seem) but
>available to anyone, under copyright protection and worldwide
>non-partisan development/distribution by a neutral group (MCG) with
>participants from 26 countries.

Will these be solving the same problems inherent in passports as well :-)
There are some basic problems that cannot be overcome with any system
using central authorties and claiming to set up trust chains leading to
people
I, as a user, do not know personally, except by adding personal information,
like signed keys ala PGP or relative names from SDSI, or by flawing
privacy issues. And if you try to redefine trust you might have difficulties
explaining that to the users....... correction, YOU won't have any
difficulties
explaining anything, they just might not be able to understand..... :-)

Peter

------=_NextPart_000_01DA_01BD8A5E.E38E13A0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_01DA_01BD8A5E.E38E13A0--

Date: Thu, 28 May 1998 15:52:10 +0200
To: Santosh Chokhani <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ipki-part4-03.txt
Sender: [email-masked]

Hi Santoch, Thank you for your reply.

I know that the structure allows definitions for CAs, RAs, Subscribers
etc. The problem is how to include general exceptions for RAs versus
the requirements on CA. Many times this is differing depending on what
kind of services the RA is involved in and I need a place to define these 
provisions.

It comes to my mind that it might be better to include general
exceptions and provisions regarding the divisions of duties between
the CA and its RAs, in the top section of the topic instead of creating
a new subsection. I.e. including my 5.1.9 under 5.1, 5.2.1.2
under 5.2.1 and 5.3.9 under 5.3. Thus avoiding un logic changes
in the structure.

The drawback of this is of course to start defining exceptions before
the actual requirements are presented in the subsections. This may
feel the wrong way round, but I'm not sure.

My main question about "2.10 Contractual Agreements" remain unanswered.

Again I higly welcome every view on this topic since I only have a few
days left to finalise this policy before approval.

Stefan 

At 08.58 1998-05-28 -0400, Santosh Chokhani wrote:
>Please note that the PKIX Part 4 allows for the security controls,
>roles, etc. to be defined for the various PKI entities, including
>issuing CA, subject CAs, RAs, subscribers, repositories, etc (see
>section 4.5 and 4.6 of the framework)
>
>Thus, all of Stefan's inclusions  in Section 5 are within the scope of
>the framework.
>
>> -----Original Message-----
>> From:	Stefan Santesson [SMTP:[email-masked]]
>> Sent:	Wednesday, May 27, 1998 5:48 PM
>> To:	[email-masked]
>> Subject:	Comments on draft-ietf-pkix-ipki-part4-03.txt
>> 
>> I'm project leader of a joint Swedish project with the
>> purpose to form a certificate policy for a Swedish national 
>> "bas-ID" certificate.
>> 
>> The project is formed by the Swedish non-profit organization
>> SEIS (Secured Electronic Information in Society) which is 
>> formed by members from Government, Banking, Industry, Military,
>> Post and Health care sectors.
>> 
>> The policy can be obtain from SEIS WWW at:
>> 
>> http://www.seis.se/regler/normer/S10_v093.doc
>> 
>> This policy is now ready for official approval on June 16
>> by the SEIS board.
>> 
>> The policy almost follows the structure of
>> draft-ietf-pkix-ipki-part4-03.txt 
>> We have, however, been forced to expand the structure with the 
>> following sections.
>> 
>> 2.10 Contractual agreements.
>> In the policy we state requirements on the CA to establish a 
>> number of contractual agreements according to some minimum 
>> standards. This is contracts with the subscriber, employer of the 
>> subscriber with which the subscriber is affiliated in the 
>> certificate, Subcontractors (such as RA:s), etc. We could not find 
>> any suitable sections in the PKIX draft to put such requirements.
>> 
>> 5.1.9 Physical Security Controls for Registration Authorities
>> A section like this was originally formed by ABA. We know that 
>> physical security for RA:s can be defined in sections 5.1 to 5.8 
>> but it is much easier to define some general exception rules for 
>> RA:s in a section of its own.
>> 
>> 5.2.1.2 Trusted Roles for Registration Authorities
>> This section was formed by the same reason as 5.1.9 above.
>> 
>> 5.3.9 Personal Security Controls for Registration Authorities
>> The same as for 5.1.9
>> 
>> 
>> Could someone comment on this. Have we misunderstood anything.
>> Should we have acted differently or should the PKIX draft be 
>> expanded.
>> 
>> Thank you in advance.
>> 
>> Stefan
>> 
>> 
>> 
>> ----------------------------------------------------------------
>> Stefan Santesson                <[email-masked]>
>> Accurata Systemsäkerhet AB     
>> Lotsgatan 27 D                  Tel. +46-40 152211              
>> 216 42  Malmö                   Fax. +46-40 150790              
>> Sweden                        Mobile +46-70 5247799
>> ----------------------------------------------------------------
>
>
----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

From: Santosh Chokhani <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, [email-masked]
Subject: RE: Comments on draft-ietf-pkix-ipki-part4-03.txt
Date: Thu, 28 May 1998 08:58:17 -0400
Sender: [email-masked]

Please note that the PKIX Part 4 allows for the security controls,
roles, etc. to be defined for the various PKI entities, including
issuing CA, subject CAs, RAs, subscribers, repositories, etc (see
section 4.5 and 4.6 of the framework)

Thus, all of Stefan's inclusions  in Section 5 are within the scope of
the framework.

> -----Original Message-----
> From:	Stefan Santesson [SMTP:[email-masked]]
> Sent:	Wednesday, May 27, 1998 5:48 PM
> To:	[email-masked]
> Subject:	Comments on draft-ietf-pkix-ipki-part4-03.txt
> 
> I'm project leader of a joint Swedish project with the
> purpose to form a certificate policy for a Swedish national 
> "bas-ID" certificate.
> 
> The project is formed by the Swedish non-profit organization
> SEIS (Secured Electronic Information in Society) which is 
> formed by members from Government, Banking, Industry, Military,
> Post and Health care sectors.
> 
> The policy can be obtain from SEIS WWW at:
> 
> http://www.seis.se/regler/normer/S10_v093.doc
> 
> This policy is now ready for official approval on June 16
> by the SEIS board.
> 
> The policy almost follows the structure of
> draft-ietf-pkix-ipki-part4-03.txt 
> We have, however, been forced to expand the structure with the 
> following sections.
> 
> 2.10 Contractual agreements.
> In the policy we state requirements on the CA to establish a 
> number of contractual agreements according to some minimum 
> standards. This is contracts with the subscriber, employer of the 
> subscriber with which the subscriber is affiliated in the 
> certificate, Subcontractors (such as RA:s), etc. We could not find 
> any suitable sections in the PKIX draft to put such requirements.
> 
> 5.1.9 Physical Security Controls for Registration Authorities
> A section like this was originally formed by ABA. We know that 
> physical security for RA:s can be defined in sections 5.1 to 5.8 
> but it is much easier to define some general exception rules for 
> RA:s in a section of its own.
> 
> 5.2.1.2 Trusted Roles for Registration Authorities
> This section was formed by the same reason as 5.1.9 above.
> 
> 5.3.9 Personal Security Controls for Registration Authorities
> The same as for 5.1.9
> 
> 
> Could someone comment on this. Have we misunderstood anything.
> Should we have acted differently or should the PKIX draft be 
> expanded.
> 
> Thank you in advance.
> 
> Stefan
> 
> 
> 
> ----------------------------------------------------------------
> Stefan Santesson                <[email-masked]>
> Accurata Systemsäkerhet AB     
> Lotsgatan 27 D                  Tel. +46-40 152211              
> 216 42  Malmö                   Fax. +46-40 150790              
> Sweden                        Mobile +46-70 5247799
> ----------------------------------------------------------------

Date: Thu, 28 May 1998 04:27:26 -0300 (EST)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: Bud <[email-masked]>
cc: Tony Bartoletti <[email-masked]>, Peter Lipp <[email-masked]>, Carl Ellison <[email-masked]>, E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: RE: [E-CARM] Pseudonyms
Sender: [email-masked]

On Wed, 27 May 1998, Bud wrote:

>> You are aware, perhaps, that dialectic is a non-word... but, I have
>> tried to answer to the best of my abilities. I am sorry if they are
>> less than what you expect and I sure welcome your help!

>Merriam-Webster would disagree - sorry
>

Bud:

It is always amusing to watch "hollier than thou" attitudes -- just
supports my thesis already expressed here: "Funny enough, when
emotions are lacking, we fill them in...perhaps to a larger extent. 
We overshoot the control target, fearing that our voice might not
carry enough strength to the other side!" 

However, there is nothing for you to feel sorry about ;-)

My phrase that "dialectic is a nonword" is:

(i) an inside joke, because in a recent past it was stated in some
lists that "trust is a nonword", as some said: "I dislike the use of
trust because so many meanings have been associated with trust that
trust has lost any possible meaning -- it can be anything you want".
However, paradoxically, I have shown that trust turns out to be ...
the basis for meaning. In other words, trust is that which allows you
to link references to referents. 

(ii) a fact, in some contexts. Just look at Socrates' meaning for it
and then compare with Hegel's. Socrates is pure logic, Hegel is pure
presumption -- as history has shown rather tragically. 

(iii) a teaser, in pure Socratic dialectic.

Cheers,

Ed Gerck

>Main Entry: di·a·lec·tic
>Pronunciation: "dI-&-'lek-tik
>Function: noun
>Etymology: Middle English dialetik, from Middle French dialetique, from
>Latin dialectica, from Greek dialektikE, from feminine of dialektikos of
>conversation, from dialektos
>Date: 14th century
>1 : LOGIC 1a(1)
>2 a : discussion and reasoning by dialogue as a method of intellectual
>investigation; specifically : the Socratic techniques of exposing false
>beliefs and eliciting truth b : the Platonic investigation of the eternal
>ideas
>3 : the logic of fallacy
>4 a : the Hegelian process of change in which a concept or its realization
>passes over into and is preserved and fulfilled by its opposite; also : the
>critical investigation of this process b (1) usually plural but singular or
>plural in construction : development through the stages of thesis,
>antithesis, and synthesis in accordance with the laws of dialectical
>materialism (2) : the investigation of this process (3) : the theoretical
>application of this process especially in the social sciences
>5 usually plural but singular or plural in construction a : any systematic
>reasoning, exposition, or argument that juxtaposes opposed or contradictory
>ideas and usually seeks to resolve their conflict b : an intellectual
>exchange of ideas
>6 : the dialectical tension or opposition between two interacting forces or
>elements
>
>

______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

From: "Bud" <[email-masked]>
To: "Ed Gerck" <[email-masked]>, "Tony Bartoletti" <[email-masked]>
Cc: "Peter Lipp" <[email-masked]>, "Carl Ellison" <[email-masked]>, "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: RE: [E-CARM] Pseudonyms
Date: Wed, 27 May 1998 23:39:09 -0700
Importance: Normal
Sender: [email-masked]

> You are aware, perhaps, that dialectic is a non-word... but, I have
> tried to answer to the best of my abilities. I am sorry if they are
> less than what you expect and I sure welcome your help!
Merriam-Webster would disagree - sorry

Main Entry: di·a·lec·tic
Pronunciation: "dI-&-'lek-tik
Function: noun
Etymology: Middle English dialetik, from Middle French dialetique, from
Latin dialectica, from Greek dialektikE, from feminine of dialektikos of
conversation, from dialektos
Date: 14th century
1 : LOGIC 1a(1)
2 a : discussion and reasoning by dialogue as a method of intellectual
investigation; specifically : the Socratic techniques of exposing false
beliefs and eliciting truth b : the Platonic investigation of the eternal
ideas
3 : the logic of fallacy
4 a : the Hegelian process of change in which a concept or its realization
passes over into and is preserved and fulfilled by its opposite; also : the
critical investigation of this process b (1) usually plural but singular or
plural in construction : development through the stages of thesis,
antithesis, and synthesis in accordance with the laws of dialectical
materialism (2) : the investigation of this process (3) : the theoretical
application of this process especially in the social sciences
5 usually plural but singular or plural in construction a : any systematic
reasoning, exposition, or argument that juxtaposes opposed or contradictory
ideas and usually seeks to resolve their conflict b : an intellectual
exchange of ideas
6 : the dialectical tension or opposition between two interacting forces or
elements

Date: Wed, 27 May 1998 23:08:12 -0300 (EST)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: Tony Bartoletti <[email-masked]>
cc: Peter Lipp <[email-masked]>, Carl Ellison <[email-masked]>, E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: Re: [E-CARM] Pseudonyms
Sender: [email-masked]

On Wed, 27 May 1998, Tony Bartoletti wrote:

>Ed,
>
>Sometimes your helpfulness is diminished by obtuse dialectic;)
>

You are aware, perhaps, that dialectic is a non-word... but, I have
tried to answer to the best of my abilities. I am sorry if they are
less than what you expect and I sure welcome your help!

>You never properly answered Peter Lipp's comparison to the driver's
>license or passport.  Although perhaps more trouble to forge, they
>are also essentially references, where one must trust (a) that the
>paper is not forged, i.e., the "apparent issuer" is indeed the issuer,
>and (b) the issuer is indeed trusted to have established a proper
>assignment of reference to referent.
>

So I answered, to the best of my abiliy, to Peter's question

>
>As the passport is a piece of paper without trust in the issuer.

with:

 I hope not! The US customs service surely must trust the issuer of
 Austrian passports if they are going to rely upon them. 

 You must always trust the issuing service -- otherwise you are
 saying that the cert is just a string of symbols without any sense.
 This is "common misconception #14", a new one on the series:

 Common misconception #14:
 
 A certificate is not magically infused with trust or effectiveness
 just because it is signed. A certificate is trusted because it is
 expected to be correct *and* effective, which trust depends on the
 issuer, the subject, the network, the certificate protocol and all
 other operational assumptions, beliefs and risks -- including the
 verifier's.

Which is in essential agreement with your own terms above: If you
don't trust the issuer (as the argument went) then you can't do
anything with it. But, it does NOT stop there: you must trust the
WHOLE chain of events -- including your own platform and your ability
to verify. 

>The point being, such paper is at heart "not to be relied upon"
>in the pure mathematical sense, and yet we do rely upon it, and
>it works for us "most" of the time.
>

I agree that mathematics is useful as a tool, not as a totem. And, I
also agree that, in that case, semantics (ie, in mathematics) shows
that you have no other reason but trust, to rely upon that paper. 

You can't "measure" it directly, thus you must "measure" it at a
distance -- ie, trust (see the given URL, pls).

>It would be most helpful to offer "OK, your scheme gets you _this_
>much, which is not very far.  Now to get further, one can securely
>assign referents to reference by doing, for instance, X", where "X"
>is devoid of references to an MCG-science-of-meaning and devoid as
>well of pontifications about Frege.
>

Perhaps, Tony. But, I cannot really say how he can solve that, nor
could I say to anyone how that could be done! That would require a
degree of evangelism which, clearly, would only be useful in a small
parish -- and with which I do not intellectually agree.

What I feel is ethical and fine is to say: "Look, what you are saying
does not get you very far and there is really no way out in that
direction. Better and clever people than myself have shown that for
100 years -- so, you can imagine how much more clever they were. Now,
based on my own scientific musings, I have found a way out. If you
want, please take a look at it and decide by yourself. This is a work
in progress and if you think you can contribute with your own $0.02
worth then please do, otherwise please wait while we finish it. 
Thanks." 

Maybe, that's why I am not  a traveling salesman...

>If the existing "trust in references" is flawed, as you plainly argue,
>why not give a reasonable example that demonstrates this flaw, and then
>show, as a point of comparison, the steps that would (in essence) be
>taken in the MCG methodology to obviate the flaw.
>

I think that you have four points here: 

1. The reasonable example that demonstrates "the flaw" is exactly to
be seen when a certificate is used for its face value as may be
"understood" by one person, and not as a reference that may have all
sorts of values to anyone else (even though it is signed). The second
flaw is to think that you are safe when you do that, and even
protected by a supposed issuer-warranty.

2. When a procedure is proved wrong, it is not necessary to show how
to do it right in order to "kill it twice". Procedures are not like
cats...;-) once dead, that is it -- even though they do have a
tendency to be zombies ;-) living their half-dead lives for awhile...

3. The procedures that obviate the flaw have been proved to exist by
myself -- and so published with full detail, which I agree takes a
few pages to explain. It was shown that they need not only intrinsic
information (names, keys, etc) transfer but also intrinsic trust
transfer. Further, they are being developed into a useful set of
protocols which will not be patented (strange as it may seem) but
available to anyone, under copyright protection and worldwide
non-partisan development/distribution by a neutral group (MCG) with
participants from 26 countries.

4. The procedures do break some new ground, specially at the
conceptual level of trust, which needs to be well understood in order
not to fall victim to one's ignorance (ie, mine included).

>After awhile, the seeming inability to offer a concrete "MCG-style"
>counter-example becomes a glaring feature of these discussions.
>

Counter-examples are always offered. For example, UK law that allows
names to be changed at will -- so that no name is less your own than
another. Or, what do you do with a CRL that did not arrive? Or, is
that really ...?

What you mean is perhaps not counter-examples, but a working example.

However, such working examples exist in the given URLs although they
may take a few pages of context. To exemplify an example ;-) see
http://www.mcg.org.br/trustdef.htm#A.4.11

Better yet, to follow-up on it I am preparing a series of short
communications, called "Intrinsic certification at a glance". The
first part was publshed last week and is available at
http://www.mcg.org.br/icert1.htm

I hope that the series will be useful -- again, as I can and within
my own limitations, which are not few perhaps.

Thanks,

Ed

______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

Date: Wed, 27 May 1998 17:04:21 -0700
To: Ed Gerck <[email-masked]>, Peter Lipp <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Cc: Carl Ellison <[email-masked]>, E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Sender: [email-masked]

Ed,

Sometimes your helpfulness is diminished by obtuse dialectic;)

You never properly answered Peter Lipp's comparison to the driver's
license or passport.  Although perhaps more trouble to forge, they
are also essentially references, where one must trust (a) that the
paper is not forged, i.e., the "apparent issuer" is indeed the issuer,
and (b) the issuer is indeed trusted to have established a proper
assignment of reference to referent.

The point being, such paper is at heart "not to be relied upon"
in the pure mathematical sense, and yet we do rely upon it, and
it works for us "most" of the time.

It would be most helpful to offer "OK, your scheme gets you _this_
much, which is not very far.  Now to get further, one can securely
assign referents to reference by doing, for instance, X", where "X"
is devoid of references to an MCG-science-of-meaning and devoid as
well of pontifications about Frege.

If the existing "trust in references" is flawed, as you plainly argue,
why not give a reasonable example that demonstrates this flaw, and then
show, as a point of comparison, the steps that would (in essence) be
taken in the MCG methodology to obviate the flaw.

After awhile, the seeming inability to offer a concrete "MCG-style"
counter-example becomes a glaring feature of these discussions.

___tony___

At 06:16 PM 5/27/98 -0300, Ed Gerck wrote:
>On Wed, 27 May 1998, Peter Lipp wrote:
>
>>>However, isn't there a problem with your privacy laws in having the
>>Austrian
>>>SSN revealed in a public document like a certificate?  I don't know
>>Austrian
>>>laws, but under German law I was told that the national ID number is
>>>protected from being used by non-official entities.
>>Definitely, and I was not intending to promote this. I was just intending to
>>counter
>>the - adding references makes things worse - argument.
>
>and, it just proved otherwise from the point of view of privacy. 
>
>This is due to a corollary to what I have called the CA-paradox, when
>it is viewed by a user as already briefly mentioned. It may be
>interesting to view it under preciser words:
>
> If enough subscriber's privacy-concerned references are provided in
> a public certificate so that a relying-party (eg, the user) can
> consider them "enough" and proceed to verify them independently
> (two known principles in auditing) then the subscriber's privacy
> and independency is jeopardized. However, if such data is denied,
> either in extent or in significance, then the relying-party's
> security and independence suffers.
>
>However, my argument that adding references over references makes
>things worse was just not only based on privacy and is much more
>general (for example, it also works for the relationship between a
>spymaster and spies). My main argument depends on the fact that any
>reference is overly-variable in sense (as Frege showed), which means
>that you cannot define who or what is *the* referent for *a*
>reference just by looking at the reference. If you add more
>references you may be just adding more indeterminacy: 
>  
> Since different observers may assign any number of different 
> referents to the same reference, increasing the number of references
> may increase the total number of possibly assigned referents.
>
>In other words, the problem may diverge with increasing reference
>terms -- not converge. 
>
>Thus, the problem of calculating the average value of a series of
>measurements of a property, which variance is expected to decrease
>with increased terms, is not equivalent to the case at hand (why
>not?).
>
>
>Where is then the link between *the* referent and *a* referent?  Is
>there one? The answer is affirmative and the link can be found, but
>it is NOT to be found in the certificate itself, as discussed in
>http://www.mcg.org.br/trustdef.htm#A.4.3
>
>which opens the discussions with:
>
> However, if we ask the question:  "what is a name in a digital
> certificate?" then we can see that the name is a reference (i.e.,
> Frege's Bedeutung) which can be wholly contained in the certificate
> even down to any desired minute data in any language or form ... and
> thus wholly transferred in the cert -- which corresponds to "a=b" and
> the cert is informational regarding such reference. However, the
> name's sense (i.e., Frege's Sinn or meaning) cannot be contained in
> the certificate at all and cannot thus be transferred.  If it could,
> then the cert would be self-referential to that referent, which is
> not informational and represents "a=a" -- "I am myself". Thus, sense
> cannot even be partially contained in a cert, otherwise that part
> would provide a self-reference to some part of the referent. 
>
>and then proceeds to the requirements to answer the above questions
>and to define the desired link from reference (yes, even one
>reference is enough) to referent.
>
>Cheers,
>
>Ed
> 
>______________________________________________________________________
>Dr.rer.nat. E. Gerck                     [email-masked]
>http://novaware.cps.softex.br
>    --- Meta-Certificate Group member, http://www.mcg.org.br ---
>
>
>

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Wed, 27 May 1998 23:27:26 +0100
To: Nilsson Hans <[email-masked]>, "'Phillip M Hallam-Baker'" <[email-masked]>, [email-masked]
From: "Frank O'Dwyer" <[email-masked]>
Subject: Re: Key Usage
Sender: [email-masked]

At 19:49 27/05/98 +0100, Nilsson Hans wrote:
>(at least not until the private key is kept on
>a smart card, where a new PIN presentation is required by the card OS for
>every private key encryption).

Not even then. For that the smart card would need to have 
a trusted path to its own display and keyboard. Even such
cards would still be too small to display much more than 
payment amounts. (And maybe payee, if you're lucky.) For 
anything more substantial you still wind up trusting the 
OS to present the right data to the card for signature,
and for displaying the right data to the user for 
confirmation.

Smart cards aren't even all that good at keeping secrets,
truth be told.  See Schneier's stuff on 'side-channels'
and Kocher's stuff on timing channels. There was also
some research done on prising secrets out of cards by
inducing faults.

[Apologies for being off-topic here, but I think it's
time we stopped treating smart cards as if they were
the last word in security even though not much
research has been done yet, and already serious 
problems are evident.]

Cheers,
Frank.

Date: Wed, 27 May 1998 23:47:56 +0200
To: <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Comments on draft-ietf-pkix-ipki-part4-03.txt
Sender: [email-masked]

I'm project leader of a joint Swedish project with the
purpose to form a certificate policy for a Swedish national 
"bas-ID" certificate.

The project is formed by the Swedish non-profit organization
SEIS (Secured Electronic Information in Society) which is 
formed by members from Government, Banking, Industry, Military,
Post and Health care sectors.

The policy can be obtain from SEIS WWW at:

http://www.seis.se/regler/normer/S10_v093.doc

This policy is now ready for official approval on June 16
by the SEIS board.

The policy almost follows the structure of draft-ietf-pkix-ipki-part4-03.txt 
We have, however, been forced to expand the structure with the 
following sections.

2.10 Contractual agreements.
In the policy we state requirements on the CA to establish a 
number of contractual agreements according to some minimum 
standards. This is contracts with the subscriber, employer of the 
subscriber with which the subscriber is affiliated in the 
certificate, Subcontractors (such as RA:s), etc. We could not find 
any suitable sections in the PKIX draft to put such requirements.

5.1.9 Physical Security Controls for Registration Authorities
A section like this was originally formed by ABA. We know that 
physical security for RA:s can be defined in sections 5.1 to 5.8 
but it is much easier to define some general exception rules for 
RA:s in a section of its own.

5.2.1.2 Trusted Roles for Registration Authorities
This section was formed by the same reason as 5.1.9 above.

5.3.9 Personal Security Controls for Registration Authorities
The same as for 5.1.9

Could someone comment on this. Have we misunderstood anything.
Should we have acted differently or should the PKIX draft be 
expanded.

Thank you in advance.

Stefan

----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

Date: Wed, 27 May 1998 18:16:54 -0300 (EST)
From: Ed Gerck <[email-masked]>
To: Peter Lipp <[email-masked]>
cc: Carl Ellison <[email-masked]>, E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: Re: [E-CARM] Pseudonyms
Sender: [email-masked]

On Wed, 27 May 1998, Peter Lipp wrote:

>>However, isn't there a problem with your privacy laws in having the
>Austrian
>>SSN revealed in a public document like a certificate?  I don't know
>Austrian
>>laws, but under German law I was told that the national ID number is
>>protected from being used by non-official entities.
>Definitely, and I was not intending to promote this. I was just intending to
>counter
>the - adding references makes things worse - argument.

and, it just proved otherwise from the point of view of privacy. 

This is due to a corollary to what I have called the CA-paradox, when
it is viewed by a user as already briefly mentioned. It may be
interesting to view it under preciser words:

 If enough subscriber's privacy-concerned references are provided in
 a public certificate so that a relying-party (eg, the user) can
 consider them "enough" and proceed to verify them independently
 (two known principles in auditing) then the subscriber's privacy
 and independency is jeopardized. However, if such data is denied,
 either in extent or in significance, then the relying-party's
 security and independence suffers.

However, my argument that adding references over references makes
things worse was just not only based on privacy and is much more
general (for example, it also works for the relationship between a
spymaster and spies). My main argument depends on the fact that any
reference is overly-variable in sense (as Frege showed), which means
that you cannot define who or what is *the* referent for *a*
reference just by looking at the reference. If you add more
references you may be just adding more indeterminacy: 
  
 Since different observers may assign any number of different 
 referents to the same reference, increasing the number of references
 may increase the total number of possibly assigned referents.

In other words, the problem may diverge with increasing reference
terms -- not converge. 

Thus, the problem of calculating the average value of a series of
measurements of a property, which variance is expected to decrease
with increased terms, is not equivalent to the case at hand (why
not?).

Where is then the link between *the* referent and *a* referent?  Is
there one? The answer is affirmative and the link can be found, but
it is NOT to be found in the certificate itself, as discussed in
http://www.mcg.org.br/trustdef.htm#A.4.3

which opens the discussions with:

 However, if we ask the question:  "what is a name in a digital
 certificate?" then we can see that the name is a reference (i.e.,
 Frege's Bedeutung) which can be wholly contained in the certificate
 even down to any desired minute data in any language or form ... and
 thus wholly transferred in the cert -- which corresponds to "a=b" and
 the cert is informational regarding such reference. However, the
 name's sense (i.e., Frege's Sinn or meaning) cannot be contained in
 the certificate at all and cannot thus be transferred.  If it could,
 then the cert would be self-referential to that referent, which is
 not informational and represents "a=a" -- "I am myself". Thus, sense
 cannot even be partially contained in a cert, otherwise that part
 would provide a self-reference to some part of the referent. 

and then proceeds to the requirements to answer the above questions
and to define the desired link from reference (yes, even one
reference is enough) to referent.

Cheers,

Ed
 
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

Date: Wed, 27 May 1998 22:49:20 +0200
To: <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Key Usage for for Authentication and digitalSignature
Sender: [email-masked]

The only problem I have with the PKIX draft is the sentence
Hans Nilsson wrote about:

 "For example, when an RSA key should be used only for signing, 
 the digitalSignature and nonRepudiation bits would be asserted."

This is a bad example which makes people think in wrong directions.

We can't say that "the digitalSignature and nonRepudiation bits 
would be asserted" if we don’t no the purpose of the "signing",
and the example says nothing about that.

I now many people that has drawn wrong conclusions thanks to this
peace of text.

Apart from this I think that the actual definition of the key
usage bits later in the text is very clear.

 "The digitalSignature bit is asserted when the subject public key
 is used to verifying digital signatures that have purposes other
 than non-repudiation"

Bearing this in mind, I think the example above should be changed
to an example which more clearly demonstrates the difference between
the digitalSignature and nonRepudiation bits and also implies that 
the normal case is to have a separate key for nonRepudiation.

Stefan

----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Nilsson Hans" <[email-masked]>, <[email-masked]>
Subject: RE: Key Usage
Date: Wed, 27 May 1998 16:16:19 -0400
Importance: Normal
Sender: [email-masked]

> I think this mess regarding key usage is very much due to the misleading
> writing in X.509. After all, according to my ISO security definitions,
> Digital Signature is a Security Mechanism that can be used to provide the
> three Security Services Authentication, Data Integrity and 
> Non-repudiation.
> This is not at all reflected in the X.509 key usage bits, where most key
> usages are mechanisms, except non-repudiation which is a service.

This is why I am suggesting that this duty should really lie on the 
specifications based on PKIX. That is the point at which the use
issue can be adequately addressed.

In other words Outlook, Communicator and Notes should all agree on the
interpretation of these bits wrt S/MIME. The best way of ensuring this
is for the S/MIME spec to explicitly state what key usages are and
are not acceptable for each purpose.

The alternative of having each S/MIME implementor interpret PKIX for
themselves opens up precisely the problem you suggest. Same for the
various other standards.

		Phill

Date: Wed, 27 May 1998 16:50:14 -0300 (EST)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: Peter Lipp <[email-masked]>
cc: E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: Misconceptions #14, #15, was Re: [E-CARM] Pseudonyms
Sender: [email-masked]

On Wed, 27 May 1998, Peter Lipp wrote:

> Ed Gerck wrote:
>
>>This means that CAs (for good and
>>valid reasons, basically pertaining to lack of adequate trust on the
>>subscriber's declarations) explicitly exclude any warranty, assurance
>>or liability for the *data* contained in supplied certs -- except
>>data generated by the CA itself (eg, the cert signature).
>
>For simplicity, I assume the propsed European Proposal was valid (and
>this was one of the reasons for me asking). It sais:

Peter:

In all fairness, I will try to summ up some issues already discussed
and you will see that the Guidelines you mention do not go very far. 

Before I show that, let me ask: do we need more law or less law? 
Clearly, we share the same global network ...but a global law does
not seem to be praticable and fair to all. 

Now, what would happen if the EC and everyone just recognizes what is
plain to see and finally decide to make it clear, in clear language,
in what I might call the "FAIR CPS":

FAIR CPS:

 Certificates are secure references signed by someone. If you rely 
 upon that someone to have at least the competence and good-will
 to sign it in a secure way, then you can use those references as
 if they were tamper-proof for all practical purposes. What you do
 with them is up to you. If that someone wants, you may have to pay
 for those references but, be warned, they are still references.

To fraudsters and hackers, the situation would not change with the
above declaration. But it has much improved to the public, since they
at least know what they have in their hands; they may indeed trust
the issuer to provide tamperproof references that they can use at
their own risk -- as it is today anyway. However, if it ends in blue
smoke, "OK -- I was not sure and I just risked $50.00 anyway". 

So, we see that "truth in Engineering" pays off.

And, as technology progresses, we keep working to really solve the
problem -- not just shove it ;-)

But, the proof of the pudding is on the eating -- so let me show you
what is being shoved nowadays... 

>
>>>Liability
>>>
>>>1. Member States shall ensure that by issuing a qualified certificate,
>>>a certification service provider is liable to any person who reasonably
>>>relies on the certificate for:
>>>
>>>(a) accuracy of all information in the qualified certificate as of the
>date
>>>it was issued, unless the certification service provider has stated
>>>otherwise in the certificate;

This does not take you very far... it just takes you to the next day!

It also exemplifies the about-face attitude of some legislation: 
they seem to provide a solution but when you get close to it such
solution is a mirage ...  that disapears.

If you were a technology based firm, specificaly dealing with
Internet/computer security, would you guarantee anything? With the
over-abundance of lawyers in the US alone, and the growing attitude
of "I got burned by being stupid so someone else needs to be
punished" it would be suicidal to guarantee much of anything. Even
organizations like the WheelGroup, who charge as much as $75,000 for
site security evaluations, don't guarantee anything ....  they just
make it harder to get in. To quote one of their employees, "The only
secure computer is one that's turned off, locked in a safe, and
buried 20 feet down in a secret location - and I'm not completely
confident of that one either".

So, CAs -- in order to be a viable business -- cannot guarantee what
they cannot verify for sure.. and even if they can verify if your
passport is indeed correct (in which assessment the US Customs
acknowledges that it also errs), they cannot say if you are really
the person named in that passport, for example, or if you had the
right to use the birth certificate that allowed that passport to be
issued and so on...

Which takes us to common misconception #12 (pls see archives): 

 CAs are supposed to be legally responsible for subscriber's data
 verification in certificates. However: (i) CAs MUST verify only to
 the extent of X.509, which only mandates public-key verification;
 (ii) CAs MAY verify only to the extent of their particular CPS and
 certificate class; and (iii) CAs CAN verify only to the extent that
 the subscriber provides them with all data that the CA may feel
 needed, according to the CA's independent and unemcumbered
 requirements, without any privacy limit arguments, IF such data
 was supplied without fraud and WITH a valid communication. 

I call attention to three perhaps subtle points above:

- "MAY": The verb "MAY" was used in the CPS case to signify that such
verification is defined by the CA in the CA's own terms, which MAY
not express what anyone else feels should be verified or expressed,
inlcuding you.

- "IF": The conditional "IF" is used in the verification of personal
data because a CA cannot be held responsible if a CA accepts an ID
that looks like an ID, quacks like an ID and walks like an ID (to use
a popular metaphor often quoted here). Even public officials are
fooled by physical false entrance vistas all around the world, daily
(this is public knowledge), so a CA cannot be required to do more -- 
they are also subject to the benefits of the law!.

- "WITH": Clearly, anything that the CA may verify depends on the
absence of viruses, hacker attacks and fraud. Even the US Pentagon
cannot declare its computers safe from hackers, so CAs cannot be
expected to be above that -- as everyone knows and is public
knowledge. 

Thus, your first point above is answered in the negative -- with
full justification -- technically, legally and litigationwise. 

>>> .....
>>>    2. Member States shall ensure that a certification service provider is
>>>not liable for errors in the information in the qualified certificate that
>has
>>>been provided by the person to whom the certificate is issued, if it can
>>>demonstrate that it has taken all reasonably practicable measures to
>>>verify that information.
>

;-) The law also agrees that it can't push the technology envelope!
This is a further about-face attitude -- which shows that paragraph
#1 was a nice Gendakenexperiment but nothing else when you try to
reach for the liabilities.

Think of it for a moment. CAs cannot be held responsible for what
they can't verify. And they can'y verify what you don't give them,
what someone may fraud them into believing and what networks may
infect them with.  In all three cases, YOU are in for the problem and
they are out of the liability. 

Anything else is for the moot courts. 

>Any CA working under these guidelines will have to provide some warranty.

In the US and in other countries, the conditions for the provision of
information processing services (ie, CAs) are similar to the ones
being discussed for the UCC (Uniform Commercial Code), which
specifies that "for data processing and design or consultation work,
the basic focus for gauging liability centers on the process, rather
than on a guaranty of correct result". 

Thus, sure. I entirely agree that, certainly, a CA is responsible for
upholding the practices disclosed in its CPS, which cover several
issues and includes correct use of cryptography.

For example, if the CPS undertakes a CA to have the correctness of
its use of cryptography audited, then the CA is responsible for this
act of auditing, and meeting the performance standards.

However, the "relying party" is unlikely to get any guaranty of
correctness of audit result from the auditing party. It will receive
a recommendation, or "assurance", in all probablity. 

This is the spirit of the law: information processing works with
references which cannot be properly measured with "certainty" --
unlike a kilogram of gold in a Bank, which must **exactly** weigh 1.0
Kg within the applicable standard for measuring gold for finnancial
purposes.

However, there is a further point here, also already discussed. This
is common misconception #4. Contract Liability to Users: Zero.

 Since the certificate's users (ie, historically known as the
 relying-parties) are not the ones that paid for the certificate to
 the CA (ie, the certificate was paid for by the subscriber), this
 means that the CA has no responsiblity or contractual obligation
 whatsoever to the certificate's users, hence zero liability. 

What does this mean? That user must also pay attention to "common
misconception #10": 

  CAs have subscribers and users. Users have no contract to
  CAs and are specifically excluded from any warranty or liability
  by commercial CAs very well-written an public CPSs -- even though
  users are called "relying-parties" in such CPSs. However, users
  must understand that they are a "relying-party"  of their own due
  dilligence.

Clearly, all users are excluded from any EC Guidelines because the
CAs can legally negate that and it would be suicidal to do otherwise. 
The few CA warranties apply to subscribers, not users.

However, who needs to rely upon a certificate? The user.

>
>>Thus, without trust on the issuer *and* (often forgotten) on the
>>subscriber a certificate is just a bag of bytes sent over the wire
>>and which has no meaning by itself -- which is "common misconception
>>#2", already cited:
>
>As the passport is a piece of paper without trust in the issuer.

I hope not! The US customs service surely must trust the issuer of
Austrian passports if they are going to rely upon them. 

You must always trust the issuing service -- otherwise you are saying
that the cert is just a string of symbols without any sense.
This is "common misconception #14", a new one on the series:

Common misconception #14:
 
 A certificate is not magically infused with trust or effectiveness
 just because it is signed. A certificate is trusted because it is
 expected to be correct *and* effective, which trust depends on the
 issuer, the subject, the network, the certificate protocol and all
 other operational assumptions, beliefs and risks -- including the
 verifier's.

> Nothing new here. 

Indeed, they are rather common misconceptions and can be frequently
found -- that's why I published the "Overview of Certification
Systems"  paper and that is why I am numbering this series, to
simplify future references to them. 

In that regard, I presume that governments are correct when they try
to legislate on certificates and digital signatures -- because the
public is indeed at risk (eg, the "biscotti paradigm"). However, they
miss the mark when they try to legislate based on *assumptions* and
not on fact. However often repeated, assumptions remain assumptions.

To quote a message from Ben Wright on another forum:

<quote>

I have a question about one aspect of the Paper.  Under Part 2
Evidence, the Paper avers that "currently only digital signature
technology meets the test of a secure electronic signature . . ." 
What is the real-world basis for that conclusion?  Have you
investigated any operational systems that in fact (not just in
theory) demonstrate all of the requirements of a digital system that
leads to an effective legal signature?  

...[snip]

The reason I ask this question is that I have not been able to
confirm that such a system exists.  If it does exist, I suspect that
it lives in a very limited and controlled environment, among highly
sophisticated parties.  I believe that anyone who diligently works
through this question will conclude that it is not easy to say that
"digital signature meets the test of a secure electronic signature." 
Experience shows that it is a real challenge -- maybe to the point of
impracticality -- to pay for and implement all the required features. 

</quote>

>
>> non-cryptographic meaning of each of its atomic parts -- for each of
>> the names that it may contain, such as common names, keys, hashes,
>> etc.
>
>Same thing as for passports. The only difference is that latter have been
>used
>for a while, and certificates are something people are not used to.
>

My statement has nothing to do with certs -- just with the data in
the certs. Surely, you trust the cert issuer and then you know that
the signature is secure (eg, the issuer keeps its private-keyt safe)
but you can't say a yod about the data in the cer that came from the
user because the *same* trusted issuer told you that it provides no
assurances, no liablities and no warranties on them. So, in the same
way that you trusted its key you should trust its lack of reliance on
the user's data in the cert, no?

>>2. each of the data sources for each data fields contained in the
>>cert -- including the CA *and* the subscriber.
>As the passport is based on a birth certificate which is based on
>a statement by some doctor that a child actually exists .... but you
>(or the officers at some border) still accept the passport .....
>

;-) as a reference is based on a reference, which is based on another
reference, and so on... then you must trust it?

This is common misconception #15 (a new one in the series):

 That the US INS accepts UK birth (naming) certificates in order to
 certify immigration status for its own policy of regulation, does not
 mean that the INS is acting to "confirm" the legitimacy of the name,
 or organise the UK namespace. So, the conclusion is that acceptance
 of a document by a recipient does not make the information in the
 document more veritable to others ...  though it is often interpreted
 so, especially when a third document is issued by the recipient and
 publicly known. Sure, there is a bar on the standard of the {UK,...}
 authorities who the INS respects sufficiently for its own activities.
 But INS confirmation (or rather "use") confers no status on the
 original document unless the INS policy wished to make such
 representation explicit -- which CAs explicitly deny.

>>The basic misconception here is to think that CAs warrant or
>>"endorse" the data that they copy in a cert -- they do not.

>Ed, what I am not sure (not having had the time to read all your
>contributions) is what you are aiming at. Claiming that CA's don't
>warrant anything - which might or might not be true today -seems to aim
>at making the concepts of CA's per se invalid, but I don't see what
>you are up to.
>

Contrary to some CA detractors ;-) I basically confirm that CAs are a
mechanism to provide for secure references. However, what is "secure"
and what is "references"? What are their meanings as the CA
understands them and as subscribers *and* users must either accept or
reject but never change?

The full report is in  http://www.mcg.org.br/cert.htm paper and a
summary is available in the E-CARM (and other, such as mcg-talk)
archives under "RE: Is there a business for CAs? Yes!".

To make it even shorter, it all hinges basically upon the difference
between what a user may expect versus what is actually legally
warranted in the full CA/subscriber/user relationship. 

Clearly, for any CA the majority of relationships is, albeit
indirectly, defined by CA/user. The number of CA/subscriber cases is
much smaller. This highlights the importance of this issue, since
users are also the ones that must primarily weigh potential losses.

Further, it is also clear that users may hold the subscribers to be
responsible. However, as a function also of the same issues -- if the
subscriber publicly denies any liability to anyone in the world, then
a user may also have only its own due dilligence to rely upon.  

The CA/user and CA/subscriber relationships are governed by that CA
CPS -- which is legally included in the cert's "four corners" by
documental reference. What do CPSs in general say about such
relationships? A CPS does not say that CA X has no warranty on its
services or that it does not take any liability on them. It only says
that CA X has no warranties and accepts no liability for services
that CA X does not recognize it provides.

Clear, clever and effective.

The fact that CA X does not provide what perhaps the majority may
think they provide (eg, you) is another point altogether. The
solution is, perhaps, much more to educate the majority than to
expect a company to do what is technically unfeasible in X.509 terms.

Thus, I have often expressed the opinion that CAs' CPSs are not at
all at odds with X.509 or legislation and that for any generic
CA one might expect a similar reasoning. 

Indeed, if the only thing that a CA does (as per X.509) is to
challenge the subscriber's private-key in order to bind the
corresponding public-key with the subscriber's DN and, if it signs
the certificate with a CPS that says that any other data are being
copied as received but have not been verified (and have thus no
warranty) then the CA has no responsibility for the contents of the
certificate -- save the positive acknowledgement that the public-key
did have a counterpart when it was linked to that DN (where the CPS
could further provide exceptions for frauds, virus, MITM attacks,
etc.

Here, my suggestion is thus perhaps made more plausible: Use the
"FAIR CPS" wording (given above, at the top of this msg) and do not
try to use about-face attitudes which will just create a sense of
false security in the public and which will actually only increase
the security of fraudsters and hackers.

>>References (ie, names) cannot convey meaning. For example, suppose I
>>would write that I am sending a Gift to you? Is that a present (as
>>written in the US) or a poison (as read in Austria)?
>This depends. If you include in an extension that you are using the english
>or german language, this becomes much better. If a certificate would contain
>a universially accepted unique identifier, this would make things easier.
>Sure,
>I know that lot's of Peter Lipp's exist, so the individual corresponding to
>this
>name (which is the meaning of the name) is not clearly defined by Peter Lipp
>alone. What else is new? Does this make the concept of certificates invalid?
>

A certificate is only valid as a secure transport for references --
which have no sense per se. The concept of certificates being
meaningful or trusted per se is what is invalid (see CM #14, above).

Let us think of it. What travels over the wire? Bytes. What do these
bytes mean? They are simply uninterpreted strings of symbols.
What can an observer (eg, you) say about the meaning of these
bytes? That depends on "what body of knowledge do you rely upon to
interpret them" -- which is called trust:

"Trust is that which an observer can rely upon to some known extent
in regard to a subject matter", see Webster for example. 

Thus, without trust on the issuer you cannot assign meaning to the
cert's signature and, thus, cannot even verify the cert's signature
(and, thereby, its authenticity). Without trust on the subject you
cannot assign meaning to the cert data either.

So, a cert is a secure reference. This is valid. Anything else is
interpretation by you, based on that which you trust -- which may be
valid or not and which warrants a quantitative treatment, not simply
"I trust".

>>So, the conclusion may be that while it is bad to try to use
>>references to convey meaning, it is worse to use even more references
>>to try "harder"....
>I dont see that. If the certificate adds another reference, like my austrian
>social security number, this might make the reference unique, but might
>not help the user of the certificate resolve his problems, agreed. It might,
>e.g. if the user is actually able to use that information, like an Austrian
>doctor
>or our social security services. What does this mean? Not every certificate
>is equally useable for all purposes. Nothing new, I suppose.
>

First, a large number of references does not increase security --
references have no meaning, no sense by themselves. They are only
good as bags of bytes. "What do they mean?" is the question -- which
answer is NOT to be found in the references themselves --as Frege
pointed out and proved in 1910, when what we call modern semantics
was born. Please see my comments on that, above and my already given
URL on the subject. So, indeed, there is nothing new on this
subject -- since 1910 ;-)

Further, this is a bit into common misconception #12, already
mentioned above -- thus it is indeed not new, it is rather common. It
hinges on the basic paradox that if a CA is allowed to plunge into
your records everywhere so as to be able to verify your information,
then your privacy suffers -- BUT, if the CA is denied such means (eg,
yopur Austrian SSN, full name and address) then they can't act as
independent verifiers and your security will suffer. 

Thus, with the X.509/CA system you have a "choice": either privacy or
security. You can't have both.., so, you can't demand privacy and
then sue for lack of security! 

There is also corollary to the above CA paradox. How can you (a CA
user) rely on B's cert (ie, B is a CA subscriber)  if you cannot
verify who B is? Thus, the corollary is:
 
if you (ie, you are a user that needs to verify B's CA cert, as the
CA CPS says users must do) have the pointers and are allowed to
plunge into B's records everywhere so as to be able to verify if the
information contained in B's cert is correct (as you, users, must
do), then B's privacy suffers -- BUT, if you are are denied such
means (eg, B's Date-of-Birth, full name and address) by B then you
can't verify B's data and your security will suffer. 

So, the CA user also has a "choice" with the X.509/CA system:  either
the user respects the other party's need for privacy or his security
will suffer. You can't have both.., so, you can't accept his privacy
and then sue for lack of your security! 

>I believe that there is no such thing as the general certificate that is a
>catch all.

Amen!

In that note of agreement I am happy to close this message!

Cheers,

Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

From: Nilsson Hans <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>, [email-masked]
Subject: Re: Key Usage
Date: Wed, 27 May 1998 19:49:45 +0100
Sender: [email-masked]

Phill,

We do not want to "stop the user from hurting himself" by separating
non-repudiation from everything else. We want to stop the user from hurting
a Relying Party by later denying his signature (as a non-native English
person, this is what I understand non-repudiation means).

What I guess we want to do, as in all countries where they are trying to
make digital signatures binding in court, is to take away any possible
loophole that gives the signer a chance to later say: "I did not sign that
document willfully". That is why we want to restrict the usage of the key as
much as possible. But I guess he always has a loophole available by saying:
"There must have been some malicous software in my PC that signed the hash,
while the key was open for usage. After all, Windows95 is not C2-level". It
may just be like fixing one small hole, when there is another large one
nearby which can not be fixed (at least not until the private key is kept on
a smart card, where a new PIN presentation is required by the card OS for
every private key encryption).

I think this mess regarding key usage is very much due to the misleading
writing in X.509. After all, according to my ISO security definitions,
Digital Signature is a Security Mechanism that can be used to provide the
three Security Services Authentication, Data Integrity and Non-repudiation.
This is not at all reflected in the X.509 key usage bits, where most key
usages are mechanisms, except non-repudiation which is a service.

I think there is a great need for common interpretation of what the key
usages "digital signature" and "non-repudiation" REALLY mean. So far, every
project or standardization body has its own.

Hans

> -----Ursprungligt meddelande-----
> Från:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Skickat:	 den 27 maj 1998 18:28
> Till:	David P. Kemp; [email-masked]
> Ämne:	RE: Key Usage for for Authentication and digitalSignature
> 
> I agree up to the point where David states:
> 
> > It is highly unlikely that any specific piece of software is both
> > dumb enough to sign data presented to it and smart enough to understand
> > and enforce the keyUsage extension.  It is also impossible to prevent
> > the same key from being certified twice, once for each keyUsage bit.
> > Therefore, I don't believe that the proposed restriction on keyUsage
> > bit combinations is warranted.
> 
> I think it very likely. I would put the probability at very close to
> 1 in fact. I just don't know of anything that can be done to prevent it. 
> 
> I think the wider problem lies in the signing infrastructure. Rather
> than attempt to tag the key as 'nonRepudiation', the _usage_ should
> be tagged in that manner. After all there are limits to the extent 
> to which non repudiation is established in a given protocol.
> 
> For example consider the case in which two parties want to communicate
> in such a manner that the FACT of a communication could not be 
> repudiated but the CONTENT could be. This is effectively what is 
> established in a perfect forward secrecy protocol in which the parties
> exchange signed DH keysets to establish a secure channel.
> 
> To what extent is such residual non-repudiation of data to be
> prohibited? Come to that what key usage bits would be appropriate
> for this particular case? I would see the application as being 
> principally a digitalSignature one but if someone was being overly
> picky it is perhaps arguable that there is an element of nonRepudiation.
> 
> 
> Given these constraints the current regime in which the user is told
> what they can do with a particular key seems the best approach. I
> don't think it is very productive to try to specify restrictions to
> stop the user from hurting themselves. After all we do not insist on
> separating encryption from signing. It seems odd therefore to start
> insisting on a separation between non-repudiation and authentication only.
> 
> 
> Rather than attempt to discuss the gory details of this issue in
> terms of abstract, hypothetical protocols how about putting a
> responsibility on protocols relying on the specification to
> state the required key usage bits for each operation?
> 
> How about a 'relying specification requirements' section that
> would list this and any other constraint which we would wish to 
> place on a relying spec such as S/MIME, IPSEC etc??
> 
> 		Phill

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: RE: Key Usage for for Authentication and digitalSignature
Date: Wed, 27 May 1998 13:27:59 -0400
Importance: Normal
Sender: [email-masked]

I agree up to the point where David states:

> It is highly unlikely that any specific piece of software is both
> dumb enough to sign data presented to it and smart enough to understand
> and enforce the keyUsage extension.  It is also impossible to prevent
> the same key from being certified twice, once for each keyUsage bit.
> Therefore, I don't believe that the proposed restriction on keyUsage
> bit combinations is warranted.

I think it very likely. I would put the probability at very close to
1 in fact. I just don't know of anything that can be done to prevent it. 

I think the wider problem lies in the signing infrastructure. Rather
than attempt to tag the key as 'nonRepudiation', the _usage_ should
be tagged in that manner. After all there are limits to the extent 
to which non repudiation is established in a given protocol.

For example consider the case in which two parties want to communicate
in such a manner that the FACT of a communication could not be 
repudiated but the CONTENT could be. This is effectively what is 
established in a perfect forward secrecy protocol in which the parties
exchange signed DH keysets to establish a secure channel.

To what extent is such residual non-repudiation of data to be
prohibited? Come to that what key usage bits would be appropriate
for this particular case? I would see the application as being 
principally a digitalSignature one but if someone was being overly
picky it is perhaps arguable that there is an element of nonRepudiation.

Given these constraints the current regime in which the user is told
what they can do with a particular key seems the best approach. I
don't think it is very productive to try to specify restrictions to
stop the user from hurting themselves. After all we do not insist on
separating encryption from signing. It seems odd therefore to start
insisting on a separation between non-repudiation and authentication only.

Rather than attempt to discuss the gory details of this issue in
terms of abstract, hypothetical protocols how about putting a
responsibility on protocols relying on the specification to
state the required key usage bits for each operation?

How about a 'relying specification requirements' section that
would list this and any other constraint which we would wish to 
place on a relying spec such as S/MIME, IPSEC etc??

		Phill

From: Ingmar Camphausen <[email-masked]>
Date: Wed, 27 May 98 18:33:08 +0200
To: [email-masked]
Subject: AuthorityInfoAccess extension revisited
Reply-To: [email-masked]
Organization: GMD - German National Research Center for Information Technology
Sender: [email-masked]

I had made the following remarks re draft-ietf-pkix-ipki-part1-06. As  
the typo has not been fixed in part1-07, and the other text remained  
unchanged as well, I guess they have been overlooked or the mail did not  
reach the list, so I'll have another try:

To sum it up, it seems to me as if in draft-ietf-pkix-ipki-part1-07, the  
entire section 4.2.2 is not consistent in itself with regard to the  
changes that were made within that section during the different drafts.

For me, this is obvious from the numbering, where there is a subsection  
4.2.2.1 but no further subsection 4.2.2.2 (hence making it unnecessary to  
insert a *sub*section 4.2.2.1, IMHO).

Furthermore, something else supports that impression that 4.2.2 is  
somewhat "out of sync": The first paragraph of 4.2.2 reads

   "[...] As the information may be available in multiple forms, each
   extension is a sequence of IA5String values, each of which represents
   a URI. [...]"

This may have been in line with the definition of `authorityInfo' in  
draft version 4 of part 1 which defined it as

   AuthorityInfoAccessSyntax  ::=  SEQUENCE  {
        authorityInfo     [0] SEQUENCE OF GeneralName OPTIONAL,
        certStatus        [1] SEQUENCE OF GeneralName OPTIONAL }

but this was replaced (in part 1 draft #5) by the more generic

   AuthorityInfoAccessSyntax  ::=
           SEQUENCE SIZE (1..MAX) OF AccessDescription

   AccessDescription  ::=  SEQUENCE {
           accessMethod          OBJECT IDENTIFIER,
           accessLocation        GeneralName  }

For that (recent) definition, the sentence "each extension is a sequence  
of IA5String values" quoted above from 4.2.2 seems inadequate to me, as  
it obviously refers to the *outdated* definition of  
AuthorityInfoAccessSyntax.

The end of section 4.2.2.1 (Authority Information Access) on page
37 describes how a pathname for certificate retrieval via URI-based
services might (should?) be constructed:

  "Other parts of the PKIX specifications [PKIXOCSP] [PKIXLDAP]
   establish requirements on certificate retrieval mechanisms. It is
   expected that applications using the URI form of the authorityInfo
   field for such a purpose will:

   1.  Prepend a suitable HTTP retrieval primitive to the URL (e.g.
   "GET").

   2.  Append a filename to the URL.

   3.  Use the result to retrieve a file containing the requested
   certificate.
   [...]"

(1) IMHO, this is somewhat too fixed on HTTP as transport service. As  
the URI form is not limited to HTTP URLs but might also include FTP, LDAP  
etc., I would like to suggest a more generic description like

  "... It is expected that applications using the URI form of the
   authorityInfo field for such a purpose will:

   1.  Prepend a suitable retrieval primitive to the URI (e.g.
   "GET" in the case of an HTTP URL).

   2.  Append a filename to the URI.

   3.  Use the result to retrieve a file containing the requested
   certificate.
   ..."

BTW: Shouldn't the words `authorityInfo field' from the second sentence
of the quoted section rather read `accessLocation field'? (This, too,  
seems to stem from the old definition of AuthorityInfoAccessSyntax, as  
mentioned above.)

(2) 4.2.2.1 continues:

  "[...]
   3.  Use the result to retrieve a file containing the requested
   certificate.

   4.  Use the authorityInfoAccess extension in that and subsequent
   certificates to complete a certificate path.

   The filename will be formed as the IA5string representation of
   SHA1(Issuer DN | certificate serial number) concatenated with ".cer."
   The IA5String representation will display the SHA1 result as a
   hexidecimal number using digits and the lowercase letters 'a' through
   'f.'  The SignerInfo syntax of PKCS 7 provides the necessary
   information as issuerAndSerialNumber.

   The specified file will contain a single DER encoded certficate."

[...hexadecimal...]
       =

Does that apply to *all* URI access methods, including FTP, or only to
HTTP as retrieval protocol? (Or was the complete section only related to
the situation where it is a *PKCS#7 message* one has to deal with?)

--
Ingmar Camphausen   [email-masked]   PGP key on server
GMD FOKUS  =  Research Institute for Open Communication Systems
++49.30.3463-7357  *  Kaiserin-Augusta-Allee 31, D-10589 Berlin

Date: Wed, 27 May 1998 11:35:19 -0400
To: [email-masked]
From: "David M. Balenson" <[email-masked]>
Subject: CFP: 1999 Network & Distributed System Security Symposium (NDSS '99)
Cc: [email-masked]
Sender: [email-masked]

--=====================_896297719==_
Content-Type: text/plain; charset="us-ascii"

--=====================_896297719==_
Content-Type: text/plain; charset="us-ascii"

	    C  A  L  L       F  O  R       P  A  P  E  R  S

			  The Internet Society
	1999 Network and Distributed System Security Symposium
			       (NDSS'99)

Where: Catamaran Resort, San Diego, California
When: February 3-5, 1999

GOAL: The symposium will foster information exchange among hardware and
  software developers of network and distributed system security
  services.  The intended audience includes those who are interested in
  the practical aspects of network and distributed system security,
  focusing on actual system design and implementation, rather than
  theory.  A major goal of the symposium is to encourage and enable the
  Internet community to apply, deploy, and advance the state of
  available security technology.  The proceedings of the symposium will
  be published by the Internet Society.

  Topics for the symposium include, but are not limited to, the
  following:

* Security in malleable systems: mobile code, mobile agents, active
  networks, dynamic policy updates, etc.
* Special problems: e.g. interplay between security goals and other
  goals such as efficiency, usability, reliability, interoperability,
  resource sharing, and cost.
* Integrating security services with system and application security
  facilities and with application protocols, including message handling,
  file transport, remote file access,  directories, time synchronization,
  data base management, routing, voice and video multicast, network
  management, boot services, and mobile computing.
* Fundamental services:  authentication, integrity, confidentiality,
  authorization, non-repudiation, and availability.
* Supporting mechanisms and APIs: key management and certification
  infrastructures, audit, and intrusion detection.
* Telecommunications security, especially for emerging technologies --
  very large systems, e.g., the Internet, high-speed systems, e.g., the
  gigabit testbeds, wireless systems, personal communication systems,
  and large-scale, heterogeneous distributed systems.

* Controls: firewalls, packet filters, application gateways
* Object security and security objects
* Network information resources and tools such as World Wide Web (WWW),
  Gopher, archie, and WAIS.
* Electronic commerce: payment services, fee-for-access, EDI, notary
  services; endorsement, licensing, bonding, and other forms of
  assurance; rights management and other forms of intellectual property
  protection
* Implementation and management of network security policy 
* Security for voice over IP
* Security for routing

GENERAL CHAIR:
  Stephen Welke, Trusted Computer Solutions

PROGRAM CHAIRS:
  Stephen Kent, BBN Technologies
  Gene Tsudik, USC/Information Sciences Institute

TUTORIAL CHAIR:
  Doug Maughan, National Security Agency

PROGRAM COMMITTEE:
  David Balenson, TIS Labs at Network Associates
  Steve Bellovin, AT&T Labs -- Research
  Matt Bishop, University of California at Davis
  Bob Blakley, IBM
  Doug Engert, Argonne National Laboratories
  Warwick Ford, VeriSign
  Li Gong, Sun Microsystems
  Rich Graveman, Bellcore
  Ari Juels, RSA Laboratories
  Tom Longstaff, CERT
  Doug Maughan, National Security Agency
  Dan Nessett, 3Com Corporation
  Michael Roe, Cambridge University
  Jeffrey Schiller, MIT
  Wolfgang Schneider, GMD Darmstadt
  Christoph Schuba, Purdue University
  Win Treese, Open Market
  Jonathan Trostle, Cisco

LOCAL ARRANGEMENTS CHAIR:
  Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
  John Kochmar, SEI

PUBLICITY CHAIR:
  David Balenson, TIS Labs at Network Associates

LOGISTICS CHAIR:
  Carla Rosenfeld, Internet Society

REGISTRATIONS CHAIR
  Beth Strait, Internet Society

SUBMISSIONS: The committee invites technical papers and panel proposals,
  for topics of technical and general interest.  Technical papers should
  be 10-20 pages in length.  Panel proposals should be two pages and
  should describe the topic, identify the panel chair, explain the
  format of the panel, and list three to four potential panelists.
  Technical papers will appear in the proceedings.  A description of
  each panel will appear in the proceedings, and may at the discretion
  of the panel chair, include written position statements from each
  panelist.

  Each submission must contain a separate title page with the type of
  submission (paper or panel), the title or topic, the names of the
  author(s), organizational affiliation(s), telephone and FAX numbers,
  postal addresses, Internet electronic mail addresses, and must list a
  single point of contact if more than one author.  The names of authors,
  affiliations, and other identifying information should appear only on
  the separate title page.

  Submissions must be received by 31 July 1998, and must be made via
  electronic mail in either PostScript or ASCII format.  If the
  committee is unable to print a PostScript submission, it will be
  returned and hardcopy requested.  Therefore, PostScript submissions
  must arrive well before 31 July.

  All submissions and program related correspondence (only) should be
  directed to the program chair:  
	Stephen Kent
	c/o BBN Technologies
	70 Fawcett Street
	Cambridge, Mass. 02138
	Email:[email-masked]
	Phone: +1 (617) 873-1996
	FAX: +1 (617) 873-4086

  Dates, final call for papers, advance program, and registration
  information will be available at the URL: http://www.isoc.org/ndss99.

  Each submission will be acknowledged by e-mail.  If acknowledgment is
  not received within seven days, please contact the program chair as
  indicated above.  Authors and panelists will be notified of acceptance
  by 18 September 1998.  Instructions for preparing camera-ready copy
  for the proceedings will be sent at that time.  The camera-ready copy
  must be received by 16 October 1998.

--=====================_896297719==_
Content-Type: text/plain; charset="us-ascii"

----------------------------------------------------------------------------
David M. Balenson, Publicity Chair, NDSS '99
TIS Labs at Network Associates, Inc.
3060 Washington Road, Glenwood, MD 21738  USA
[email-masked]; 301-854-5358; fax 301-854-5363
--=====================_896297719==_--

Date: Tue, 26 May 1998 13:01:09 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Key Usage for for Authentication and digitalSignature
Sender: [email-masked]

> From: Nilsson Hans <[email-masked]>
> 
> Because of this threat, we have in Sweden come to the conclusion that the
> nonRepudiation usage bit never may be combined with any other key usage. Is
> this correct (and PKIX-part1-07 wrong), or have we misunderstood something
> along the way?

There are two ways to protect against the described scenario:

  1) Clients never blindly sign a value sent by another party, or

  2) Clients always understand and enforce the keyUsage extension,
     CAs always mark the extension as critical, and the nonRepudiation
     bit is not set in combination with other bits.

For the particular case of TLS (SSL) client authentication, the client
does not sign a hash value sent by the server.  Instead, the
certificate verify message is a signature over all prior handshake
messages which have occurred in the the current handshake exchange -
this includes both random and predictable data generated by both the
server and the client.

For the general (non-TLS) case, a hypothetical authentication protocol
is BROKEN if it specifies that the server sends a value and the client
signs it!

It is highly unlikely that any specific piece of software is both
dumb enough to sign data presented to it and smart enough to understand
and enforce the keyUsage extension.  It is also impossible to prevent
the same key from being certified twice, once for each keyUsage bit.
Therefore, I don't believe that the proposed restriction on keyUsage
bit combinations is warranted.

NOTE:  I agree that it is highly desirable for CAs to use separate keys
for nonRepudiation and other purposes.  But that is a matter of policy,
not something which the PKIX profile can mandate.

From: "Peter Lipp" <[email-masked]>
To: <[email-masked]>, "Stefan Santesson" <[email-masked]>
Subject: Re: CRL issuing
Date: Wed, 27 May 1998 16:13:32 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00B0_01BD898A.648E4720
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>The CA is by this procedure linked to the CRL by certifying the
>public key with which the CRL can be checked.

Which implementations currently can handle this and which don't?

More precisely, which implementations currently can handle CRL's at all
and which of them can handle these special public key properly?

I guess not too many.....

Peter

------=_NextPart_000_00B0_01BD898A.648E4720
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00B0_01BD898A.648E4720--

From: "Peter Lipp" <[email-masked]>
To: "Carl Ellison" <[email-masked]>
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Date: Wed, 27 May 1998 16:11:04 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00A4_01BD898A.0CB71860
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>However, isn't there a problem with your privacy laws in having the
Austrian
>SSN revealed in a public document like a certificate?  I don't know
Austrian
>laws, but under German law I was told that the national ID number is
>protected from being used by non-official entities.
Definitely, and I was not intending to promote this. I was just intending to
counter
the - adding references makes things worse - argument.

Peter

------=_NextPart_000_00A4_01BD898A.0CB71860
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00A4_01BD898A.0CB71860--

From: "Peter Lipp" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: CRL issuing
Date: Wed, 27 May 1998 16:07:41 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_009C_01BD8989.938E3FE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>(Whether anything actually supports this functionality is another question.
I
> know of several implementations which specifically *don't* support it, and
> just use the first key they find).

Thats what I fear.

Peter

------=_NextPart_000_009C_01BD8989.938E3FE0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_009C_01BD8989.938E3FE0--

From: "Peter Lipp" <[email-masked]>
To: "Ed Gerck" <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Date: Wed, 27 May 1998 15:53:58 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0065_01BD8987.A95D82B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

> I would like to remind of the use of a Certificate policy here.
No doubt about that. But that is not my point.

>I don’t think any strict rules regarding use of attributes or extensions
can
>change that.

I agree. But: nonetheless, I would like to have a standard "behaviour" of
CA's
if there is one topic many such CA's must behave somehow. If there would be
many many Pseudonym-Certificates around, maybe application programmers
would like to make this obvious to their users, and then a standard
attribute
within a certificate would come in handy.

Peter

------=_NextPart_000_0065_01BD8987.A95D82B0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0065_01BD8987.A95D82B0--

Date: Wed, 27 May 1998 09:43:35 -0400
To: "Peter Lipp" <[email-masked]>
From: Carl Ellison <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 12:30 PM 5/27/98 +0200, Peter Lipp wrote:
>Sure,
>I know that lot's of Peter Lipp's exist, so the individual corresponding to
>this
>name (which is the meaning of the name) is not clearly defined by Peter Lipp
>alone. What else is new? Does this make the concept of certificates invalid?

This lack of name uniqueness makes (name,key) certificates dangerous and 
puts the wisdom of using (name,key) certificates into doubt.  The danger is 
that we are so accustomed to using names as valid identifiers of people in 
our daily lives (thanks to our living, in the 3D world, in small communities 
of friends, family, coworkers, ...), that we are tempted to believe that all 
names are valid identifiers.  In a national, continental or global 
namespace, those names are not valid identifiers and a careful security 
design would not allow people to believe they are.  The current (name,key) 
certificate design and more especially the verbiage surrounding (name,key) 
certificates (including the texts of laws) not only allows people to believe 
names are valid identifiers but also seems to suffer from that mistake itself.
The danger of this belief mismatch is that someone looking for the certified
key of an old friend (or co-worker or customer or merchant or ...) is led
to guess whether the name in the certificate belongs to the entity that
user things it might -- based on name match.  This process is a human guess
and there is no room in security procedures for human guesses...at least
not when we are trying to keep mistakes in the process down to a probability
of less than 2^{-90}.

>>So, the conclusion may be that while it is bad to try to use
>>references to convey meaning, it is worse to use even more references
>>to try "harder"....
>I dont see that. If the certificate adds another reference, like my austrian
>social security number, this might make the reference unique, but might
>not help the user of the certificate resolve his problems, agreed. It might,
>e.g. if the user is actually able to use that information, like an Austrian
>doctor
>or our social security services. What does this mean? Not every certificate
>is equally useable for all purposes. Nothing new, I suppose.
>
>I believe that there is no such thing as the general certificate that is a
>catch all.

Amen.

However, isn't there a problem with your privacy laws in having the Austrian 
SSN revealed in a public document like a certificate?  I don't know Austrian 
laws, but under German law I was told that the national ID number is 
protected from being used by non-official entities.

As you add more such fields to a general certificate (to make it useful to
other people who care about other things about the keyholder), that 
certificate becomes a dossier.  [This is the main reason SPKI chose to issue 
a large number of certificates to a keyholder, each holding only one fact.]

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison  [email-masked]   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+

Date: Wed, 27 May 1998 14:29:57 +0200
To: Ferdinando Ricchiuti <[email-masked]>, Nilsson Hans <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Key Usage for for Authentication and digitalSignature
Cc: [email-masked]
Sender: [email-masked]

At 10.53 1998-05-27 +0200, Ferdinando Ricchiuti wrote:
>Actually in the SSL-v3.0 client-autentication phase, the client
>generates a MAC in this way:
>	1-the received data (master key) are padded and hashed
>	2-the resulting stream is then padded again and rehashed
>	3-this finaly stream is encrypted with client's private key
>This mean that the MAC sent to the server, is not a digital signature 
>as defined in X.509 specification.
>Thus we think there are not security leack using both digitalSignature
>and nonRepudation bits.
>
>Regards.
>
>F.Ricchiuti  [email-masked]
>R.D'Altoe'   [email-masked]
>

This is not only a question of protocols.

There are more differences between non-repudiation and authentication to be 
considered.

The most important difference is the way the key holder uses the private key, 

- how the use of the key is combined with a warning that using this key
includes
  responsibilities and liabilities 
- how the information to be signed is presented and accepted by the key
holder.
- how the key is protected from being used without the key holders conscious
  participation.

Many authentication processes is automatic and frequent while non-repudiation
is conscious and more infrequent. This makes it hard to use the same key
for both purposes.

In order to make the key holder liable for a signature, exclusive use of
the key for non-repudiation is of great value in court. This includes
exclusive mechanisms (PINs and codes) to activate the key.

Separated private keys requires separated certificates. Bad or
good protocols is not the most important consideration here.
---

What I want to propose is NOT to forbid the non-repudiation to be
combined with any other use. I think that is a question for the certificate
policy.

What I would like, is to clearly define the use of the bits. The best would be
to change the name from "digital signature" to "Authentication", thus to
identify
a service instead of a mechanism. As it is now it's difficult to understand
the
difference between "non-repudiation" and "digital signatures" and I believe
that
the PKIX definition is very unclear here.

The most important task is to make it possible to clearly distinguish te
use of 
keys for digital signatures as part in an authentication process, from the
case 
when it's used in digital signatures for non repudiation purposes.

/Stefan

----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

Date: Wed, 27 May 1998 13:41:12 +0200
To: "Peter Lipp" <[email-masked]>, "Ed Gerck" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I would like to remind of the use of a Certificate policy here.

At 22.08 1998-05-26 +0200, Peter Lipp wrote:
>Now, if a CA issues standard X.509 claimed-identity certificates,
>representing
>the CA's authentication management act, as well as pseudonym certificates,
>this CA most likely will want to make the difference explicit, because it
>does not
>want to risk somebody declaring their certificates useless.
>
>With current user-side technology, the only way to make this easily visible
>by the
>user seems to be to change the DN by adding e.g. "Pseudonym:" to CN.
>
>While this might not be necessary with "Pseudonym: Fritz the Cat", it
>definitely would be
>in the case of "Pseudonym: Ed Gerck" - both certificates issued to myself.
>This will work,
>and the user will more likely realize the fact that this is a pseudonym,
>that in the case there
>is no such hint.

The certificate policy is a perfect place to declare rules and regulations
concerning naming and interpretation of naming attributes.

This is handled both in section 3 and 7 of the PKIX certificate policy 
framework.

Trust by a relying party in a certificate and its included naming attributes 
must include an acceptance of the stipulations in the identified certificate 
policy. In fact, the certificate policy IS the main difference between a 
"driving-license" type of certificate and a "local membership" type of 
certificate.

I don’t think any strict rules regarding use of attributes or extensions can
change that.

/Stefan

----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

From: "Peter Lipp" <[email-masked]>
To: "Ed Gerck" <[email-masked]>
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Date: Wed, 27 May 1998 12:30:56 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_001D_01BD896B.4C098440
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Ed,

>I think that your comment mixes two issues, and I would like to pick
>them appart.

I think your response is based on assumptions, that may or may not be
true.

>This means that CAs (for good and
>valid reasons, basically pertaining to lack of adequate trust on the
>subscriber's declarations) explicitly exclude any warranty, assurance
>or liability for the *data* contained in supplied certs -- except
>data generated by the CA itself (eg, the cert signature).

For simplicity, I assume the propsed European Proposal was valid (and
this was one of the reasons for me asking). It sais:

>>Liability
>>
>>1. Member States shall ensure that by issuing a qualified certificate,
>>a certification service provider is liable to any person who reasonably
>>relies on the certificate for:
>>
>>(a) accuracy of all information in the qualified certificate as of the
date
>>it was issued, unless the certification service provider has stated
>>otherwise in the certificate;
>> .....
>>    2. Member States shall ensure that a certification service provider is
>>not liable for errors in the information in the qualified certificate that
has
>>been provided by the person to whom the certificate is issued, if it can
>>demonstrate that it has taken all reasonably practicable measures to
>>verify that information.

Any CA working under these guidelines will have to provide some warranty.

>Thus, without trust on the issuer *and* (often forgotten) on the
>subscriber a certificate is just a bag of bytes sent over the wire
>and which has no meaning by itself -- which is "common misconception
>#2", already cited:

As the passport is a piece of paper without trust in the issuer. Nothing new
here.

> non-cryptographic meaning of each of its atomic parts -- for each of
> the names that it may contain, such as common names, keys, hashes,
> etc.

Same thing as for passports. The only difference is that latter have been
used
for a while, and certificates are something people are not used to.

>2. each of the data sources for each data fields contained in the
>cert -- including the CA *and* the subscriber.
As the passport is based on a birth certificate which is based on
a statement by some doctor that a child actually exists .... but you
(or the officers at some border) still accept the passport .....

>The basic misconception here is to think that CAs warrant or
>"endorse" the data that they copy in a cert -- they do not.
Ed, what I am not sure (not having had the time to read all your
contributions) is what you are aiming at. Claiming that CA's don't
warrant anything - which might or might not be true today -seems to aim
at making the concepts of CA's per se invalid, but I don't see what
you are up to.

>References (ie, names) cannot convey meaning. For example, suppose I
>would write that I am sending a Gift to you? Is that a present (as
>written in the US) or a poison (as read in Austria)?
This depends. If you include in an extension that you are using the english
or german language, this becomes much better. If a certificate would contain
a universially accepted unique identifier, this would make things easier.
Sure,
I know that lot's of Peter Lipp's exist, so the individual corresponding to
this
name (which is the meaning of the name) is not clearly defined by Peter Lipp
alone. What else is new? Does this make the concept of certificates invalid?

>So, the conclusion may be that while it is bad to try to use
>references to convey meaning, it is worse to use even more references
>to try "harder"....
I dont see that. If the certificate adds another reference, like my austrian
social security number, this might make the reference unique, but might
not help the user of the certificate resolve his problems, agreed. It might,
e.g. if the user is actually able to use that information, like an Austrian
doctor
or our social security services. What does this mean? Not every certificate
is equally useable for all purposes. Nothing new, I suppose.

I believe that there is no such thing as the general certificate that is a
catch all.

Peter

------=_NextPart_000_001D_01BD896B.4C098440
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_001D_01BD896B.4C098440--

Date: Wed, 27 May 1998 10:53:59 +0200
From: Ferdinando Ricchiuti <[email-masked]>
To: Nilsson Hans <[email-masked]>
Cc: [email-masked]
Subject: Re: Key Usage for for Authentication and digitalSignature
Sender: [email-masked]

Nilsson Hans wrote:
> 
> In pkix-part1-07, section 4.2.1.3 Key Usage it says:
> 
> "For example, when an RSA key should be used only for signing, the
> digitalSignature and nonRepudation bits would be asserted"
> and also "The digitalSignature bit is asserted when the subject public key
> is used to privde authentication". The same writing can be found in the new
> ISO draft 1572 (Public Key certificates for banking.
> 
> If understand this correctly, this introduces a possible security threat,
> with the following scenario: In a user's certificate, both bits are set.
> When the user is required to logon to a web server using SSL client
> authentication, the server actually sends a the hash value of a false
> message, instead of a random number as a challenge.  The user encrypts with
> the corresponding private key, and has thus unknowingly signed the false
> message.
> 
> Because of this threat, we have in Sweden come to the conclusion that the
> nonRepudiation usage bit never may be combined with any other key usage. Is
> this correct (and PKIX-part1-07 wrong), or have we misunderstood something
> along the way?
> 
> Hans Nilsson
> 
> AU-System Network
> Stockholm Sweden

Hans,

Actually in the SSL-v3.0 client-autentication phase, the client
generates a MAC in this way:
	1-the received data (master key) are padded and hashed
	2-the resulting stream is then padded again and rehashed
	3-this finaly stream is encrypted with client's private key
This mean that the MAC sent to the server, is not a digital signature 
as defined in X.509 specification.
Thus we think there are not security leack using both digitalSignature
and nonRepudation bits.

Regards.

F.Ricchiuti  [email-masked]
R.D'Altoe'   [email-masked]

From: Nilsson Hans <[email-masked]>
To: [email-masked]
Subject: SV: Key Usage for for Authentication and digitalSignature
Date: Wed, 27 May 1998 07:08:57 +0100
Sender: [email-masked]

I agree that the threat is a case of poor protocol design. But there ARE
badly designed protocols out there. And since the function is called
"non-repudiation", we do not want to give the signer any possibility to
later repudiate his signature by saying: "some software I was using must
have had a bad protocol. I did not sign that document".

Hans

> -----Ursprungligt meddelande-----
> Från:	Michael Warner [SMTP:[email-masked]]
> Skickat:	 den 27 maj 1998 00:03
> Till:	[email-masked]; [email-masked]; [email-masked]
> Ämne:	Re: Key Usage for for Authentication and digitalSignature
> 
> 
> While I agree that it may be desirable to separate the use of a 
> non-repudiation key from outher authentication keys, I think the 
> threat described below is a case of poor protocol design.
> 
> The authentication token being signed should be more than just a simple 
> random number, but should be (the hash of) a token which includes the
> identity of the peer to which you are authenticating and possibly other
> information, such as your own random challenge.   This token should be 
> constructed by the signer - not the verifier.
> 
> Cheers,
> 
> Michael Warner
> Telstra Research Laboratories
> 
> > From: Mike Smith <[email-masked]>
> > 
> > Excellent scenario for misuse of DS within SSL or other "signed token"
> authentication 
> > schemas.  Yet another reason to separate the functions from DS purposes.
> > 
> > Michael
> > 
> > >>> Nilsson Hans <[email-masked]> 05/23 4:57 AM >>>
> > In pkix-part1-07, section 4.2.1.3 Key Usage it says:
> > 
> > "For example, when an RSA key should be used only for signing, the
> > digitalSignature and nonRepudation bits would be asserted" 
> > and also "The digitalSignature bit is asserted when the subject public
> key
> > is used to privde authentication". The same writing can be found in the
> new
> > ISO draft 1572 (Public Key certificates for banking. 
> > 
> > If understand this correctly, this introduces a possible security
> threat,
> > with the following scenario: In a user's certificate, both bits are set.
> > When the user is required to logon to a web server using SSL client
> > authentication, the server actually sends a the hash value of a false
> > message, instead of a random number as a challenge.  The user encrypts
> with
> > the corresponding private key, and has thus unknowingly signed the false
> > message.
> > 
> > Because of this threat, we have in Sweden come to the conclusion that
> the
> > nonRepudiation usage bit never may be combined with any other key usage.
> Is
> > this correct (and PKIX-part1-07 wrong), or have we misunderstood
> something
> > along the way?
> > 
> > Hans Nilsson
> > 
> > AU-System Network
> > Stockholm Sweden
> > 
> > 
> > 
> >
> !
>      !
> > !
> > !
> > !
> > !
> >
> 
> > 

Date: Tue, 26 May 1998 11:05:41 -0400
To: [email-masked] (David P. Kemp)
From: Russ Housley <[email-masked]>
Subject: Re: Question about NS cert server
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Dave:

I agree that CAs conforming to the PKIX profile will only generate v3
certificates, because all certificates will include extensions.

Russ

At 02:10 PM 5/22/98 -0400, David P. Kemp wrote:
>> From: Russ Housley <[email-masked]>
>> 
>> In my opinion, a certificate that has no extensions MUST not be a version 3
>> certificate.
>
>
>Part 1 section 4.1.2.1 says "At a minimum, conforming implementations
>shall recognize version 3 certificates."
>
>Section 4.2.1.2 says "This extension MUST appear in all conforming CA
>certificates ..."
>
>Therefore, PKIX-conforming CAs MUST issue only v3 certificate paths and
>PKIX-conforming clients MUST be able to read them.
>
>The only reason PKIX says anything about version 1 is to recommend that
>non-conforming CAs make their certs usable by old non-conforming clients
>whenever possible.  What is the purpose or effect of a MUST requirement
>which applies *only* to non-conforming applications?
>
>Dave Kemp
> 

Date: Wed, 27 May 1998 01:16:25 +0200
To: "Peter Lipp" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: CRL issuing
Sender: [email-masked]

We have studied this phenomena in Swedish trials.

At 21.46 1998-05-26 +0200, Peter Lipp wrote:
>Up to now my image of the world of CRL's was such that the key to
>issue a CRL must be the same key the certificate was signed with.
>Nice and simple.
>
>Now, in discussions with colleagues, one made the proposal to use
>a different key to keep things flexible. Hmm. I began to search, and
>was not able to find any explicit statement anywhere that would dis-
>allow such a solution. Implicitely, there seem to be difficulties though,
>as the CRL itself does not provide meanst to include any certificates
>that link the CA and the CRL-issuer together; the CRL only includes the
>DN of its issuer - i.e. if the key would be different the DN could not, and
>if
>it was how can I know whose certificates where revoked when only a
>serial number was available.
>
>What I'd like to know was if there is something somewhere that I have
>overlooked that made the case clear.

We conclude that:

Using version 1 CRL:s The structure according to PKIX "Certificate management 
protocols" section 2.4 REQUIRES the CRL to be issued with the currently
active 
CA-key and not with the one that was active when issuing the revoked
certificate.

This requires the certificate user to keep track of the current active CA
key for that CA and use it for CRL checking.

Using version 2 CRL:s with a key identifier makes it possible to generalize
the scheme and totally separate the CRL-key from the issuing key. Then of
course the CA has to post a certificate over the public CRL-key in the
appropriate repository.

The CA is by this procedure linked to the CRL by certifying the
public key with which the CRL can be checked.

Last: To my understanding a specific CRL (or equivalent revocation checking
service) must be implicitly or explicitly identified by the certificate
itself. Using version 3 certificates the CRL can be identified in an
extension.
By following this rule there is only need for the certificate serial
number in the CRL. 

Stefan Santesson
Accurata.

>
>Peter
>
>
>
>

----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

Date: Wed, 27 May 1998 09:03:18 +1000
From: Michael Warner <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Key Usage for for Authentication and digitalSignature
Sender: [email-masked]

While I agree that it may be desirable to separate the use of a 
non-repudiation key from outher authentication keys, I think the 
threat described below is a case of poor protocol design.

The authentication token being signed should be more than just a simple 
random number, but should be (the hash of) a token which includes the
identity of the peer to which you are authenticating and possibly other
information, such as your own random challenge.   This token should be 
constructed by the signer - not the verifier.

Cheers,

Michael Warner
Telstra Research Laboratories

> From: Mike Smith <[email-masked]>
> 
> Excellent scenario for misuse of DS within SSL or other "signed token" authentication 
> schemas.  Yet another reason to separate the functions from DS purposes.
> 
> Michael
> 
> >>> Nilsson Hans <[email-masked]> 05/23 4:57 AM >>>
> In pkix-part1-07, section 4.2.1.3 Key Usage it says:
> 
> "For example, when an RSA key should be used only for signing, the
> digitalSignature and nonRepudation bits would be asserted" 
> and also "The digitalSignature bit is asserted when the subject public key
> is used to privde authentication". The same writing can be found in the new
> ISO draft 1572 (Public Key certificates for banking. 
> 
> If understand this correctly, this introduces a possible security threat,
> with the following scenario: In a user's certificate, both bits are set.
> When the user is required to logon to a web server using SSL client
> authentication, the server actually sends a the hash value of a false
> message, instead of a random number as a challenge.  The user encrypts with
> the corresponding private key, and has thus unknowingly signed the false
> message.
> 
> Because of this threat, we have in Sweden come to the conclusion that the
> nonRepudiation usage bit never may be combined with any other key usage. Is
> this correct (and PKIX-part1-07 wrong), or have we misunderstood something
> along the way?
> 
> Hans Nilsson
> 
> AU-System Network
> Stockholm Sweden
> 
> 
> 
>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            !
     !
> !
> !
> !
> !
>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: CRL issuing
Reply-To: [email-masked]
Date: Wed, 27 May 1998 10:18:01 (NZST)
Sender: [email-masked]

>Now, in discussions with colleagues, one made the proposal to use a different
>key to keep things flexible. Hmm. I began to search, and was not able to find
>any explicit statement anywhere that would dis- allow such a solution.
>Implicitely, there seem to be difficulties though, as the CRL itself does not
>provide meanst to include any certificates that link the CA and the CRL-issuer
>together; the CRL only includes the DN of its issuer - i.e. if the key would
>be different the DN could not, and if it was how can I know whose certificates
>where revoked when only a serial number was available.
>
>What I'd like to know was if there is something somewhere that I have
>overlooked that made the case clear.
 
The keyUsage flags.  You can specify that one key only be used for cert 
signing, and one only for CRL signing, so even if they have the same DN you 
could choose the correct key based on keyUsage.
 
(Whether anything actually supports this functionality is another question.  I 
 know of several implementations which specifically *don't* support it, and 
 just use the first key they find).
 
Peter.

Date: Tue, 26 May 1998 15:23:04 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: CRL issuing
Sender: [email-masked]

You may wish to search on "indirect" CRLs.

Michael

>>> "Peter Lipp" <[email-masked]> 05/26 1:46 PM >>>
Up to now my image of the world of CRL's was such that the key to
issue a CRL must be the same key the certificate was signed with.
Nice and simple.

Now, in discussions with colleagues, one made the proposal to use
a different key to keep things flexible. Hmm. I began to search, and
was not able to find any explicit statement anywhere that would dis-
allow such a solution. Implicitely, there seem to be difficulties though,
as the CRL itself does not provide meanst to include any certificates
that link the CA and the CRL-issuer together; the CRL only includes the
DN of its issuer - i.e. if the key would be different the DN could not, and
if
it was how can I know whose certificates where revoked when only a
serial number was available.

What I'd like to know was if there is something somewhere that I have
overlooked that made the case clear.

Peter

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

Date: Tue, 26 May 1998 17:56:20 -0300 (EST)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: Peter Lipp <[email-masked]>
cc: E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: Re: [E-CARM] Pseudonyms
Sender: [email-masked]

On Tue, 26 May 1998, Peter Lipp wrote:

> Ed Gerck wrote:
>> In legal reliance terms, one may trust the confirmation
>> procedures of the CA during certificate reliance, but one cannot rely
>> upon them for other than their value as a representation of the CA's
>> authentication management act expressed in the CA's own terms and
>> rules -- therefore, a X.509 certificate is neither necessarily
>> meaningful nor valid in a user's reference frame or for the user's
>> purposes.
>
>Agreed. Practically however, a X.509 certificate might be meaningful for the
>users purposes in most of the cases, while not 100% guaranteed.
>Statistically,
>most of the passports or drivers licenses used are still valid and fake ones
>or
>so do not make their concept invalid per se. Users "simply" have to be aware
>of their limitations.

Peter:

I think that your comment mixes two issues, and I would like to pick
them appart.

The first issue is about "correctness": is a cert correct? This is
the question behind arguments such as if passports or drivers
licenses are fake or not and *also* whether such fake ids might have
been used to obtain an incorrect (ie, with wrong data) cert. 

To that question, the CA answer is not "not 100% guaranteed" as you
say -- but "100% not guaranteed". This means that CAs (for good and
valid reasons, basically pertaining to lack of adequate trust on the
subscriber's declarations) explicitly exclude any warranty, assurance
or liability for the *data* contained in supplied certs -- except
data generated by the CA itself (eg, the cert signature).

Thus, without trust on the issuer *and* (often forgotten) on the
subscriber a certificate is just a bag of bytes sent over the wire
and which has no meaning by itself -- which is "common misconception
#2", already cited:

 Here, trust is not only essential for the cryptographic meaning
 (i.e., providing for valid origin authentication and data integrity
 authentication) of the certificate but also for the
 non-cryptographic meaning of each of its atomic parts -- for each of
 the names that it may contain, such as common names, keys, hashes,
 etc. 

Thus, to achieve "correctness" you must trust TWO entities, at least: 

1. the issuer for the cert's signature, and

2. each of the data sources for each data fields contained in the
cert -- including the CA *and* the subscriber.

The second issue is about "effectiveness": is the cert effective for
my intended meaning? This question cannot even be asked, except for
the issuing CA *itself* and by *itself*.  That issue is at the heart
of "common misconception #3", already quoted above. 

>
>Now, if a CA issues standard X.509 claimed-identity certificates,
>representing
>the CA's authentication management act, as well as pseudonym certificates,
>this CA most likely will want to make the difference explicit, because it
>does not
>want to risk somebody declaring their certificates useless.
>

Not useless -- afterall, they are tamperproof references. However,
what do they express? You may interpret them as you wish -- which may
be different from what the CA thinks, and the CA may think what it
wishes in its CPS. 

The basic misconception here is to think that CAs warrant or
"endorse" the data that they copy in a cert -- they do not.

As already mentioned here, this is common misconception #9, when
people think that "endorsement"  has to do with verification,
warranties, liabilities.  That is not the case. 

Common misconception #9:

 The word "endorsement" must be viewed with care because it may
 have both a "strong" and a "weak" form -- without the user knowing
 which form is actually used. The strong form means "verified using
 reasonable effort and as such guaranteed". The weak form has the
 meaning "copying as received". In the praxis, all actual protocols
 explicitly or implicitly use the weak form because of specific
 legislation shelters and warranty disclaimers .. This
 corresponds to "endorsement without recourse". For example, in
 English law one can endorse "without recourse" (or, as it used to be
 expressed, "sans recours"), which passes on the benefit of a bill of
 exchange without adding any guarantee. Endorsement in any form does
 not mean that the whole content of the certificate is endorsed,
 normally only the public-key is endorsed -- even though this is not
 usually stated in the certificate itself.

>With current user-side technology, the only way to make this easily visible
>by the
>user seems to be to change the DN by adding e.g. "Pseudonym:" to CN.
>
>While this might not be necessary with "Pseudonym: Fritz the Cat", it
>definitely would be
>in the case of "Pseudonym: Ed Gerck" - both certificates issued to myself.
>This will work,
>and the user will more likely realize the fact that this is a pseudonym,
>that in the case there
>is no such hint.

References (ie, names) cannot convey meaning. For example, suppose I
would write that I am sending a Gift to you? Is that a present (as
written in the US) or a poison (as read in Austria)? 

Gottlob Frege (in 1910) showed that references are just truth-values
-- which have no significance if seen without the corresponding truth
conditions. 

Now, suppose you would send a "cert tutorial" to an average user,
together with the cert, so that users could study that and then hope
to correctly distinguish between pseudonymous, anonymous, named,
implicit and whatever certs, taking also into account a crash course
on (for example) the UK legislation that says that I can legally use
the name John Major if I so wish and a crash course on syntatics
versus semantics -- then... would this increase or decrease
confusion? 

So, the conclusion may be that while it is bad to try to use
references to convey meaning, it is worse to use even more references
to try "harder"....

Here, Marx Brothers fans will possibly recall the scene in "A Day at
the Races": a tip for Sun-up. In this scene, Groucho, intending to
put his money on Sun-up, is induced instead to buy a coded tip from
Chico and is able to establish the identity of the horse only, at
some cost in terms of time and money, by successive purchases from
Chico of the code book, the master code book, the breeders' guide and
various other works of reference, by the end of which the race is
over, Sun-up having won.

Cheers,

Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

From: Cliff Wang <[email-masked]>
To: <[email-masked]>
Subject: X.509 and PKCS#7 and #10
Date: Tue, 26 May 1998 16:50:02 -0400
Sender: [email-masked]

I apologize if this question has been asked before
since I am new to this working group.

Many times I see products supporting X.509 v3 and
PKCS#7 and #10. X.509 v3 is IETF standards and PKCS
are RSA owned standards. Can somebody explain to me
what exactly they differ? If X.509 v3 is sufficient, why PKCS
stuff is still required ?

Thanks!

Cliff Wang
IBM
[email-masked]

Date: Tue, 26 May 1998 14:38:18 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Key Usage for for Authentication and digitalSignature
Sender: [email-masked]

Excellent scenario for misuse of DS within SSL or other "signed token" authentication schemas.  Yet another reason to separate the functions from DS purposes.

Michael

>>> Nilsson Hans <[email-masked]> 05/23 4:57 AM >>>
In pkix-part1-07, section 4.2.1.3 Key Usage it says:

"For example, when an RSA key should be used only for signing, the
digitalSignature and nonRepudation bits would be asserted" 
and also "The digitalSignature bit is asserted when the subject public key
is used to privde authentication". The same writing can be found in the new
ISO draft 1572 (Public Key certificates for banking. 

If understand this correctly, this introduces a possible security threat,
with the following scenario: In a user's certificate, both bits are set.
When the user is required to logon to a web server using SSL client
authentication, the server actually sends a the hash value of a false
message, instead of a random number as a challenge.  The user encrypts with
the corresponding private key, and has thus unknowingly signed the false
message.

Because of this threat, we have in Sweden come to the conclusion that the
nonRepudiation usage bit never may be combined with any other key usage. Is
this correct (and PKIX-part1-07 wrong), or have we misunderstood something
along the way?

Hans Nilsson

AU-System Network
Stockholm Sweden

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 

From: "Peter Lipp" <[email-masked]>
To: "Ed Gerck" <[email-masked]>
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Date: Tue, 26 May 1998 22:08:04 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0109_01BD88F2.C14DDA90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Ed,

>This is trivially fine and if the EC Guidelines require that then
>they are just allowing for a fact -- which is good, instead of
>pretending otherwise as in some other countries.
I have to admit, that these pseudonym certificates are to be issued
on request only, and are not the only certificates a CA can issue. It must
issue one if the user requires that. This was not clear in my message.

> In legal reliance terms, one may trust the confirmation
> procedures of the CA during certificate reliance, but one cannot rely
> upon them for other than their value as a representation of the CA's
> authentication management act expressed in the CA's own terms and
> rules -- therefore, a X.509 certificate is neither necessarily
> meaningful nor valid in a user's reference frame or for the user's
> purposes.
Agreed. Practically however, a X.509 certificate might be meaningful for the
users purposes in most of the cases, while not 100% guaranteed.
Statistically,
most of the passports or drivers licenses used are still valid and fake ones
or
so do not make their concept invalid per se. Users "simply" have to be aware
of their limitations.

Now, if a CA issues standard X.509 claimed-identity certificates,
representing
the CA's authentication management act, as well as pseudonym certificates,
this CA most likely will want to make the difference explicit, because it
does not
want to risk somebody declaring their certificates useless.

With current user-side technology, the only way to make this easily visible
by the
user seems to be to change the DN by adding e.g. "Pseudonym:" to CN.

While this might not be necessary with "Pseudonym: Fritz the Cat", it
definitely would be
in the case of "Pseudonym: Ed Gerck" - both certificates issued to myself.
This will work,
and the user will more likely realize the fact that this is a pseudonym,
that in the case there
is no such hint.

OTOH it is not a technically elegant solution. Personally, I'd prefer to
have an extension defined
that says: This is a pseudonym. I could invent my private extension, which
will buy me nothing
with todays clients. A standardized extension might help, but not now -
better later then never.

So this is a technically solveable problem, that might be solved within e.g.
PKIX, and might
be available to standard software timely for any european guidelines
becoming valid sometimes.
And meta-discussions about this, while being of value, won't help here.

Peter

------=_NextPart_000_0109_01BD88F2.C14DDA90
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0109_01BD88F2.C14DDA90--

From: "Peter Lipp" <[email-masked]>
To: "Carl Ellison" <[email-masked]>
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Date: Tue, 26 May 1998 21:52:53 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00FF_01BD88F0.A2A9FDA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Carl,

>How would you hide the other fields of a certificate?  Encipher them?
Leave them empty as much as possible.

>OTOH, if a certificate issuer means something besides random name
assignment
>by an ID cert, I would like to see that meaning expressed explicitly.  For
>example,
The aim of the digital signature guidelines are definitely to achieve
"meaning" in terms
of identifiabilty.  And it is essential to make a difference between a
pseudonym and a
claim-to-be-a-real-name in such an environment.

And no, issuing SPKI/SDSI certificates for pseudonyms does not seem to be an
option (yet) :-)

I have to add that these guidelines are a draft only, and we will have to
see what will be in
there finally. However, as many (most?) of us here believe that pseudonyms
are good, I bet
these might stay.

Peter

------=_NextPart_000_00FF_01BD88F0.A2A9FDA0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00FF_01BD88F0.A2A9FDA0--

From: "Peter Lipp" <[email-masked]>
To: <[email-masked]>
Subject: CRL issuing
Date: Tue, 26 May 1998 21:46:08 +0200
Sender: [email-masked]

Up to now my image of the world of CRL's was such that the key to
issue a CRL must be the same key the certificate was signed with.
Nice and simple.

Now, in discussions with colleagues, one made the proposal to use
a different key to keep things flexible. Hmm. I began to search, and
was not able to find any explicit statement anywhere that would dis-
allow such a solution. Implicitely, there seem to be difficulties though,
as the CRL itself does not provide meanst to include any certificates
that link the CA and the CRL-issuer together; the CRL only includes the
DN of its issuer - i.e. if the key would be different the DN could not, and
if
it was how can I know whose certificates where revoked when only a
serial number was available.

What I'd like to know was if there is something somewhere that I have
overlooked that made the case clear.

Peter

Date: Tue, 26 May 1998 14:04:01 -0400
From: Bob Masters <[email-masked]>
Organization: GTE Internetworking
To: Carlisle Adams <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-ipki3cmp-08.txt
Sender: [email-masked]

Carlisle,

Page 20 of CMP contains the statement "specification of external protection
using PKCS #7 will be provided in a separate document."  What is this separate
document?  I have looked at CMC, but it does not seem to be compatible with CMP.

Thanks for any help you can give me on this.

Bob Masters
GTE Internetworking

Carlisle Adams wrote:

> Hi all,
>
> For those that are curious, the PKIX-CMP draft has been updated to
> accommodate a change that was necessary for its companion draft CRMF.  The
> request message in CRMF was missing a way to carry an AlgId in one of the
> choices for proof-of-possession syntax (the syntax was borrowed from CMP,
> which didn't need to carry the AlgId because it explicitly used the one
> specified in PKIHeader, but since CRMF does not necessarily have a PKIHeader
> the extra AlgId needed to be included).
>
> The syntax change is on p.26, where publicKeyMAC is now a PKMACValue
> (instead of a BIT STRING), and PKMACValue (defined in CRMF) is a sequence of
> AlgId and BIT STRING.
>
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> [email-masked]
> --------------------------------------------
>
> > ----------
> > From:         [email-masked][SMTP:[email-masked]]
> > Sent:         Tuesday, May 26, 1998 10:16 AM
> > To:   IETF-Announce
> > Cc:   [email-masked]
> > Subject:      I-D ACTION:draft-ietf-pkix-ipki3cmp-08.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Public-Key Infrastructure (X.509) Working
> > Group
> > of the IETF.
> >
> >       Title           : Internet X.509 Public Key Infrastructure
> > Certificate
> >                           Management Protocols
> >       Author(s)       : C. Adams, S. Farrell
> >       Filename        : draft-ietf-pkix-ipki3cmp-08.txt
> >       Pages           : 67
> >       Date            : 22-May-98
> >
> > This document describes the Internet X.509 Public Key Infrastructure
> > (PKI) Certificate Management Protocols. Protocol messages are defined
> > for all relevant aspects of certificate creation and management.  Note
> > that 'certificate' in this document refers to an X.509v3 Certificate as
> > defined in [COR95, X509-AM].
> >

Alternate-recipient: Allowed
Disclose-recipients: Prohibited
Content-return: Allowed
Date: Tue, 26 May 1998 10:36:05 -0700
From: Mack Hicks <[email-masked]>
Subject: attribute certs
To: [email-masked] (Return requested)
Cc: [email-masked] (Return requested)
Content-identifier: 00E9A356AFD85158
Conversion: Allowed
Original-encoded-information-types: IA5-Text
X400-Content-type: P2-1988 ( 22 )
X400-MTS-identifier: [/c=US/admd=attmail/; 00E9A356AFD85158-attmail]
X400-Originator: [email-masked]
X400-Recipients: non-disclosure;
Sender: [email-masked]

Oliver,

Bank of America has implemented OCSP between Bank of America
and Zions Bank.  We have implemented this as part of the
NACHA CA Interoperability pilot in cooperation with Verisign
and CertCo. We have it working. The pilot begins on June 1.

Note that the CA does not sign the OCSP response - rather
the OCSP is the agent of certificate status to the merchants
in this pilot.

See http://internetcouncil.nacha.org/

-   -
Mack Hicks (415) 278-7230  -- Interactive Banking Division
425 1st St m/s3671, SF CA 94105 <[email-masked]>
*** Forwarding note from O3UDISXT--EXTHUB   05/26/98 01:50 ***
To: GMHICKS --ABACIS2  Mack Hicks

From: Oliver Korfmacher
Subject: attribute certs

External Addresses Follow:

From: "Oliver Korfmacher"<[email-masked]>
To: [email-masked]

(sorry if this is a faq)

Could anybody comment on attribute certificates? Are they used in
real-world apps?

And, long ago, somebody asked for implementations of OCSP -- I never
found any answers to this one? Or do I miss it?

We currently consider an OCSP extension to our x.500/ldap dsa -- any
comments welcome.

        Oliver

--
Oliver Korfmacher, Isocor  [email-masked]  Telephone +49.6021/3095-51
Fax  +49.6021/3095-99  Mobile +49.172/3907041  Msg [email-masked]

                                       Privat:   [email-masked]

From: Carlisle Adams <[email-masked]>
To: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-ipki3cmp-08.txt
Date: Tue, 26 May 1998 13:13:50 -0400
Sender: [email-masked]

Hi all,

For those that are curious, the PKIX-CMP draft has been updated to
accommodate a change that was necessary for its companion draft CRMF.  The
request message in CRMF was missing a way to carry an AlgId in one of the
choices for proof-of-possession syntax (the syntax was borrowed from CMP,
which didn't need to carry the AlgId because it explicitly used the one
specified in PKIHeader, but since CRMF does not necessarily have a PKIHeader
the extra AlgId needed to be included).

The syntax change is on p.26, where publicKeyMAC is now a PKMACValue
(instead of a BIT STRING), and PKMACValue (defined in CRMF) is a sequence of
AlgId and BIT STRING.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	Tuesday, May 26, 1998 10:16 AM
> To: 	IETF-Announce
> Cc: 	[email-masked]
> Subject: 	I-D ACTION:draft-ietf-pkix-ipki3cmp-08.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working
> Group 
> of the IETF.
> 
> 	Title		: Internet X.509 Public Key Infrastructure
> Certificate 
>                           Management Protocols
> 	Author(s)	: C. Adams, S. Farrell
> 	Filename	: draft-ietf-pkix-ipki3cmp-08.txt
> 	Pages		: 67
> 	Date		: 22-May-98
> 	
> This document describes the Internet X.509 Public Key Infrastructure
> (PKI) Certificate Management Protocols. Protocol messages are defined
> for all relevant aspects of certificate creation and management.  Note
> that 'certificate' in this document refers to an X.509v3 Certificate as
> defined in [COR95, X509-AM].
> 

Date: Tue, 26 May 1998 17:47:43 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Nilsson Hans <[email-masked]>
CC: [email-masked]
Subject: Re: Key Usage for for Authentication and digitalSignature
Sender: [email-masked]

Nilsson Hans wrote:

> In pkix-part1-07, section 4.2.1.3 Key Usage it says:
> 
> "For example, when an RSA key should be used only for signing, the
> digitalSignature and nonRepudation bits would be asserted"
> and also "The digitalSignature bit is asserted when the subject public key
> is used to privde authentication". The same writing can be found in the new
> ISO draft 1572 (Public Key certificates for banking.
 
> If understand this correctly, this introduces a possible security threat,
> with the following scenario: In a user's certificate, both bits are set.
> When the user is required to logon to a web server using SSL client
> authentication, the server actually sends a the hash value of a false
> message, instead of a random number as a challenge.  The user encrypts with
> the corresponding private key, and has thus unknowingly signed the false
> message.
 
> Because of this threat, we have in Sweden come to the conclusion that the
> nonRepudiation usage bit never may be combined with any other key usage. Is
> this correct (and PKIX-part1-07 wrong), or have we misunderstood something
> along the way?

I fully support your position. Pkix-part1-07 should be corrected.

Denis

N.B. A long time ago, when participating to the ISO work I advocated for
the addition the NR bit.
 
> Hans Nilsson
> 
> AU-System Network
> Stockholm Sweden

-- 
      Denis Pinkas     Bull S.A.          mailto:[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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki3cmp-08.txt
Date: Tue, 26 May 1998 10:16:04 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          Management Protocols
	Author(s)	: C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-ipki3cmp-08.txt
	Pages		: 67
	Date		: 22-May-98
	
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocols. Protocol messages are defined
for all relevant aspects of certificate creation and management.  Note
that 'certificate' in this document refers to an X.509v3 Certificate as
defined in [COR95, X509-AM].

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki3cmp-08.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki3cmp-08.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki3cmp-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Certificate reparenting, version numbers in extensions
Reply-To: [email-masked]
Date: Wed, 27 May 1998 01:48:11 (NZST)
Sender: [email-masked]

In preparation for the next release of the X.509 style guide (I think I've 
given the vendors I've been able to contact about the bug list enough time 
now :-), I have a few questions/issues I'd like to get feedback on.
        
The first one is the problems you encounter with constraint enforcement.  For 
most types of chaining, it's fairly easy to resolve the validity of a cert by 
examining the parent-child relationship and making sure everything is in 
order (parent is a CA, hasn't expired, names chain correctly, etc etc).  
However in some cases it's possible for CA's to plant booby-traps in the 
chaining by specifying a constraint which affects some arbitrary certificate 
an arbitrary distance down the chain.  In general all this does is make 
validation annoyingly difficult, but it can cause reparenting and rerooting to 
fail completely.  For example what happens when both the current subtree and 
the new parent subtree contain conflicting constraints?  One of the reasons 
for having a name-independant key identifier (authority/subjectKeyIdentifier) 
is to allow reparenting, however if almost any kind of constraint is present 
in the path (off the top of my head any of basic constraints, name 
constraints, and policy constraints (which just about covers all the bases 
anyway)) they'll interfere with reparenting).
 
How seriously has this been examined in practice?  It easy enough to specify a 
key identifier to allow a cert to be identified independant of any labelling 
it might have, but since path validation is still bound by the labelling it 
may not do a lot of good in practice.
 
The second problem is that of putting version numbers into extensions.  This 
can interfere with the processing of critical extensions, because it's 
uncertain whether a critical extension which you recognise with a version 
number which you don't recognise counts as a "recognised" (in the sense of 
"don't reject the certificate") extension.  You certainly recognise the 
extension (based on the OID), but you don't recognise it based on the version 
number (this ties in with my earlier complaints about exactly what is meant 
by "recognise an extension").  As I see it having version numbers in an 
extension means the whole thing falls into a logical loophole, because you can 
either accept the cert (you recognise the OID) or reject it (you don't 
recognise the data in the extension).
 
I discussed this problem with someone who has a version number in an extension 
recently, they were of the opinion that knowing what the OID was counted as 
recognising the extension, but I considered it to mean that you were capable 
of processing it in a manner compliant with the semantic intent of the 
extension.  What do others think?
 
Some minor nits from the latest draft, there's a spurious 
CertificatePolicesSyntax present in policyConstraints, and I assume the given 
PolicyConstraints should actually be PolicyConstraintsSyntax.  In addition the 
altName URI is overloaded to double up on the functionality of 
authorityInfoAccess.  I assume this was an attempt to sidestep possible 
patents on the latter?  I think the overloading only appeared in the last 
draft, will this be undone now that the patent situation is cleared up 
(assuming that's what motivated it)?
 
Peter.

Date: Tue, 26 May 1998 12:12:34 +0200
From: Oliver Korfmacher <[email-masked]>
Reply-To: [email-masked]
Organization: ISOCOR GmbH
To: Charles Moore <[email-masked]>
Subject: Re: attribute certs
Sender: [email-masked]

> 
> We currently consider an OCSP extension to our x.500/ldap dsa -- any
> comments welcome.
> 
> > Thats interesting approach, but I dont see how you will manage the
> business side of on-line status from a DSA?
> ( I would want my status signed by the CA that issued the cert?)
hmm. 1) german signature law requires a top level or root ca which
holds  certs of all second level ca, 2) what about cross certification
here? and 3) if there are lets say 5 ca, checking the one who validates
is okay? Of course, this is somehow limited..

In OCSP, all answers are signed by the CA.
We would probably strongly suggest that the request is signed by the
requestor as well. Due to commercial reasons, the CA operator might want
this info for billing purposes..

	Oliver
-- 
Oliver Korfmacher, Isocor  [email-masked]  Telephone +49.6021/3095-51
Fax  +49.6021/3095-99  Mobile +49.172/3907041  Msg [email-masked]

                                       Privat:   [email-masked]

From: [email-masked]
Date: Tue, 26 May 1998 11:33:23 +0200
Subject: RE: Key Usage for for Authentication and digitalSignature
TO: [email-masked], [email-masked]
Sender: [email-masked]

--openmail-part-01132d04-00000001
Content-Type: multipart/alternative; boundary=openmail-part-01132d04-00000002

--openmail-part-01132d04-00000002
Content-Type: text/plain; charset=ISO-8859-1; name="BDY.RTF"
Content-Disposition: inline; filename="BDY.RTF"
Content-Transfer-Encoding: quoted-printable

[email-masked] wrote:
>
>In pkix-part1-07, section 4.2.1.3 Key Usage it says:
>
>"For example, when an RSA key should be used only for signing, the
>digitalSignature and nonRepudation bits would be asserted" =20
>and also "The digitalSignature bit is asserted when the subject public
key
>is used to privde authentication". The same writing can be found in the=

new
>ISO draft 1572 (Public Key certificates for banking. =20
>
> [...]
>

Hi Hans,

I believe this must be a typo, right?
Later in the same section it says:

      The digitalSignature bit is asserted when the subject public key
      is used to verifying digital signatures that have purposes other
                                                                 ^^^^^
      than non-repudiation, certificate signature, and CRL signature.
      For example, The digitalSignature bit is asserted when the subject=

      public key is used to provide authentication.

      The nonRepudiation bit is asserted when the subject public key is
      used to verifying digital signatures used to provide a non-
      repudiation service which protects against the signing entity
      falsely denying some action, excluding certificate or CRL signing.=

IMHO this would indicate that the digitalSignature and non-repudiation
bits may never be used at the same time.

OTOH Section 7.3.1 also states that: =20

  "The use of a single key for both signature and encryption purposes =20
  is not recommended, but is not forbidden."

Since PKIX-1 is not a policy document, it cannot forbid bad combinations=

of key usage bits I believe. However, I'd applaud the adobtion of a =20
statement similar to the one above, that recommend against the =20
combination of the digitalSignature and non-repudiation bits.

Regards,
/Lars Johansson
Sweden Post

--openmail-part-01132d04-00000002
Content-Type: application/rtf; name="BDY.RTF"
Content-Disposition: attachment; filename="BDY.RTF"
Content-Transfer-Encoding: base64

--openmail-part-01132d04-00000002--

--openmail-part-01132d04-00000001
Content-Type: application/x-openmail-1734; name="WINMAIL.DAT"
Content-Disposition: attachment; filename="WINMAIL.DAT"
Content-Transfer-Encoding: base64

--openmail-part-01132d04-00000001--

Date: Tue, 26 May 1998 09:23:39 +0200
From: Oliver Korfmacher <[email-masked]>
To: [email-masked]
Subject: attribute certs
Sender: [email-masked]

(sorry if this is a faq)

Could anybody comment on attribute certificates? Are they used in
real-world apps?

And, long ago, somebody asked for implementations of OCSP -- I never
found any answers to this one? Or do I miss it?

We currently consider an OCSP extension to our x.500/ldap dsa -- any
comments welcome. 

	Oliver

-- 
Oliver Korfmacher, Isocor  [email-masked]  Telephone +49.6021/3095-51
Fax  +49.6021/3095-99  Mobile +49.172/3907041  Msg [email-masked]

                                       Privat:   [email-masked]

Date: Mon, 25 May 1998 23:36:05 -0300 (EST)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: Peter Lipp <[email-masked]>
cc: E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: Re: [E-CARM] Pseudonyms
Sender: [email-masked]

On Mon, 25 May 1998, Peter Lipp wrote:

>The European Commission's Guidelines will most probably require
>CA's to issue semi-anonymous certificates containing a pseudonym
>instead of the subjects real name. This is fine.

Peter:

This is trivially fine and if the EC Guidelines require that then
they are just allowing for a fact -- which is good, instead of
pretending otherwise as in some other countries.

For example, in the UK anyone can use any name without any
formalities for changing names and no name is less legal than any
other. Since the UK is in the EC, I imagine that Mark Twain could
still get his cert in Europe at least by requiring it from a UK CA
... 

Further, DNs in certs express the CA's name assignment (ie, NA to
CA), according to the CA's own rules and understanding as expressed
by each CA's CPS. 

> 
> Now, if a CA want's to issue a pseudonym-certificate, it will
> somehow like to or have to mark this as being a pseudonym. One way
> to do this would be to change the DN. Ideally there should be a
> standard way to do that in any case. Has there been any discussion
> about that - or any opinions on that? 

So, answering your question, pseudonyms can be trivially used in DNs
if and only if the CA accepts them -- the CA *is* the final authority
as the issued certificates are concerned. 

This is unfortunately not always clearly understood and was numbered
here as "common misconception #3", because the data in a certificate
is NEITHER objectively NOR intersubjectively warranted by the CA, but
just subjectively warranted according to the CA's own viewpoint, as
was summarized:

 In legal reliance terms, one may trust the confirmation
 procedures of the CA during certificate reliance, but one cannot rely
 upon them for other than their value as a representation of the CA's
 authentication management act expressed in the CA's own terms and
 rules -- therefore, a X.509 certificate is neither necessarily
 meaningful nor valid in a user's reference frame or for the user's
 purposes. 

as listed in e-carm's archives.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

Date: Mon, 25 May 1998 21:30:09 -0400
To: "Peter Lipp" <[email-masked]>
From: Carl Ellison <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Cc: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

At 11:39 PM 5/25/98 +0200, Peter Lipp wrote:
>The European Commission's Guidelines will most probably require
>CA's to issue semi-anonymous certificates containing a pseudonym
>instead of the subjects real name. This is fine.
>
>Now, if a CA want's  to issue a pseudonym-certificate, it will somehow
>like to or have to mark this as being a pseudonym. One way to do this
>would be to change the DN. Ideally there should be a standard way to do that
>in any case. Has there been any discussion about that - or any opinions on
>that?
>
>I believe that anything outside the DN would not be visible to the user of
>such a
>cert, while OTOH I'd prefer a special extension technically.

Hi Peter.

How would you hide the other fields of a certificate?  Encipher them?

I'm not sure labeling a pseudonym makes any sense.  It certainly doesn't in 
SDSI.  There is no reason to differentiate between a common name, a pet name 
and a randomly chosen pseudonum in SDSI.  Since I tend to map all X.509 
names into SDSI names in order to make sense of them, the 
indistinguishability of these different kinds of names is carried along with 
that.

OTOH, if a certificate issuer means something besides random name assignment 
by an ID cert, I would like to see that meaning expressed explicitly.  For 
example,

"The information in this certificate should have enabled someone to track 
down the keyholder, as of <issue-date>."

or

"The issuer of this certificate co-signs anything signed by the subject 
keyholder up to a limit of $XXXX."

or

"The issuer of this certificate insures any user of this certificate against 
fraud and abuse by the keyholder, up to a limit of $YYYYYYYYY"

oe

"The issuer of this certificate promises to track down the subject keyholder 
for a fee of $ZZZ, until <expiry-date>, for the purpose of serving legal 
papers on him/her."

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison  [email-masked]   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+

From: "Peter Lipp" <[email-masked]>
To: "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Subject: Pseudonyms
Date: Mon, 25 May 1998 23:39:33 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00B1_01BD8836.5F408F80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The European Commission's Guidelines will most probably require
CA's to issue semi-anonymous certificates containing a pseudonym
instead of the subjects real name. This is fine.

Now, if a CA want's  to issue a pseudonym-certificate, it will somehow
like to or have to mark this as being a pseudonym. One way to do this
would be to change the DN. Ideally there should be a standard way to do that
in any case. Has there been any discussion about that - or any opinions on
that?

I believe that anything outside the DN would not be visible to the user of
such a
cert, while OTOH I'd prefer a special extension technically.

Ideas, opinions?

Peter

------=_NextPart_000_00B1_01BD8836.5F408F80
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00B1_01BD8836.5F408F80--

From: Charles Moore <[email-masked]>
To: "PKIX (E-mail)" <[email-masked]>
Subject: Previous message
Date: Mon, 25 May 1998 13:20:17 +1000
Sender: [email-masked]

Sorry, wrong list.

Charles Moore 
Signet Systems Pty Ltd 
Phone: +61 7 3256 7465. 

From: Charles Moore <[email-masked]>
To: "'PKIX (E-mail)'" <[email-masked]>
Subject: Recall: ORA v3 Comments on new material
Date: Mon, 25 May 1998 13:19:52 +1000
Expiry-Date: Wed, 27 May 1998 13:19:13 +1000
Sender: [email-masked]

Charles Moore would like to recall the message, "ORA v3 Comments on new
material".

From: Charles Moore <[email-masked]>
To: "PKIX (E-mail)" <[email-masked]>
Subject: ORA v3 Comments on new material
Date: Mon, 25 May 1998 13:13:49 +1000
Sender: [email-masked]

Comment: Delete new material.
Rational: ORA or RA functions do NOT issue CRLs' this si ONLY the
function of the OCA or CA function.
A ORA/RA can process a revocation request to the OCA/CA.

Certificate Revocations
The Registration Function shall on the authenticated request of a
certificate holder send a revocation notice direct to the Certificate
Revocation List of the CA, or else to the appropriate receiver at the
CA.
A request shall be authenticated by
being signed by the secret key corresponding to the public key in the
certificate
the inclusion of secret information agreed at the time of registration
being physically signed by the person that signed the application for
the certificate

Charles Moore 
Signet Systems Pty Ltd 
Phone: +61 7 3256 7465. 

From: Nilsson Hans <[email-masked]>
To: [email-masked]
Subject: Key Usage for for Authentication and digitalSignature
Date: Sat, 23 May 1998 11:57:15 +0100
Sender: [email-masked]

In pkix-part1-07, section 4.2.1.3 Key Usage it says:

"For example, when an RSA key should be used only for signing, the
digitalSignature and nonRepudation bits would be asserted" 
and also "The digitalSignature bit is asserted when the subject public key
is used to privde authentication". The same writing can be found in the new
ISO draft 1572 (Public Key certificates for banking. 

If understand this correctly, this introduces a possible security threat,
with the following scenario: In a user's certificate, both bits are set.
When the user is required to logon to a web server using SSL client
authentication, the server actually sends a the hash value of a false
message, instead of a random number as a challenge.  The user encrypts with
the corresponding private key, and has thus unknowingly signed the false
message.

Because of this threat, we have in Sweden come to the conclusion that the
nonRepudiation usage bit never may be combined with any other key usage. Is
this correct (and PKIX-part1-07 wrong), or have we misunderstood something
along the way?

Hans Nilsson

AU-System Network
Stockholm Sweden

Date: Fri, 22 May 1998 14:10:06 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked]
Subject: Re: Question about NS cert server
Sender: [email-masked]

> From: Russ Housley <[email-masked]>
> 
> In my opinion, a certificate that has no extensions MUST not be a version 3
> certificate.

Part 1 section 4.1.2.1 says "At a minimum, conforming implementations
shall recognize version 3 certificates."

Section 4.2.1.2 says "This extension MUST appear in all conforming CA
certificates ..."

Therefore, PKIX-conforming CAs MUST issue only v3 certificate paths and
PKIX-conforming clients MUST be able to read them.

The only reason PKIX says anything about version 1 is to recommend that
non-conforming CAs make their certs usable by old non-conforming clients
whenever possible.  What is the purpose or effect of a MUST requirement
which applies *only* to non-conforming applications?

Dave Kemp

Date: Fri, 22 May 1998 11:40:33 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Question about NS cert server
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

In my opinion, a certificate that has no extensions MUST not be a version 3
certificate.

Russ

At 03:18 PM 5/22/98 +0000, Peter Gutmann wrote:
>>In our CA implementation we decided to employ KISS methodology and stamp all
>>certificates V3.
> 
>Hmm, I think that might be W.R.O.N.G. rather than K.I.S.S. :-).  X.509v3 is
>silent on this (#include <stdgrumble.h>), but PKIX implies that if you
mark the
>cert v3 it should actually *be* v3 (it says "use version 1" rather than "MUST
>use version 1" or "SHALL use version 1", so I'm not sure whether this is
just a
>recommendation or a "must" rule).  Logic would dictate that it should be a
>"must", because anything which recodes the cert into the canonical form will
>invalidate the signature on it.
> 
>(I've cc'd this to the PKIX list for comment).
> 
>Peter.
> 
> 

Date: Fri, 22 May 1998 10:55:52 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: CHOICE OF OCSP certID syntax
Sender: [email-masked]

At 11:06 AM 5/21/98 -0400, Rich Salz wrote:
>>I still believe that a DN is a better retrieval index than a
>>key hash.

I agree.

Russ

Date: Fri, 22 May 1998 15:54:58 +0200
From: Ferdinando Ricchiuti <[email-masked]>
To: IETF <[email-masked]>
Subject: Time Stamp Protocols
Sender: [email-masked]

This is a multi-part message in MIME format.

--------------ABD31DF237C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello.
I'm developing an implementetion of IETF-PKIX-IPKI5SP (Time Stamp
Protocols) using SSLeay-0.9.0 crypto-api.
I've attached the IPKIX5ts Internet Draft because the IETF hasn't
published the new version yet.

Thanks.

-- 
+-------------------------------------------------------------------+
| Ferdinando Ricchiuti                     Computer Science Student |
+--------------------------------+----------------------------------+
| Politecnico di Torino          | phone:  +39-(0)11-5647090        |
| Dip. Automatica e Informatica  | fax:                             |
| corso Duca degli Abruzzi, 24   | e-mail: [email-masked] | 
| 10129 Torino                   |                                  |
| ITALY                          | http://www.polito.it/~fricchi/   | 
+--------------------------------+----------------------------------+

--------------ABD31DF237C
Content-Type: text/plain; charset=iso-8859-1; name="timestamp.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline; filename="timestamp.txt"

PKIX Working Group                        C. Adams(Entrust Technologies)
Internet Draft                                             P. Cain (BBN)
expires in six months                                   D. Pinkas (Bull)
                                     R. Zuccherato(Entrust Technologies)
                                                           July 29, 1997

                     Internet Public Key Infrastructure
 
                       Part V:  Time Stamp Protocols 

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

Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

This document describes the format of the data returned by a Time 
Stamp Authority and the protocols to be used when communicating with it.  
The time stamping service can be used as a Trusted Third Party (TTP) as 
one component in building reliable non-repudiation services (see 
[ISONR]).  We also give an example of how to place a signature at a 
particular point in time, from which the appropriate CRLs may be 
checked.

1.  Introduction

In order to associate a message with a particular point in time, a
Time Stamp Authority (TSA) may need to be used.  This Trusted Third 
Party provides a proof-of-existence for this particular message at an 
instant in time.  A TSA may also be used when a trusted time reference 
is required and when the local clock available cannot be trusted by all 
parties.  The TSAs role is to time stamp a message to establish 
evidence indicating the time before which the message was generated.  
This can then be used, for example, to verify that a digital signature 
was applied before the key was put on a CRL, to indicate the time of 
submission when a deadline is critical, or to indicate the time of 
transaction for entries in a log.  An exhaustive list of possible uses 
of a TSA is beyond the scope of this document. 

Document Expiration:  Jan. 29, 1998                               Page 1

2. Requirements of the TSA

The TSA is required to:
     1. include a monotonically incrementing value of the time of day 
        into its time stamp token.
     2. produce a time stamp token upon receiving a valid request from
        the requester.
     3. include within each time stamp token an identifier to 
        uniquely determine the trust and validation policy used for this
        signature.
     4. support time stamping of a hash representation of the message 
        from the requester.

3.  TSA Transactions

As the first message of this mechanism, the requesting entity requests a 
time stamping service by sending a request (which is or includes a 
TimeStampReq, as defined below) to the Time Stamping Authority.  As the 
second message, the Time Stamping Authority responds by sending a 
response (which is or includes a TimeStampToken, as defined below) to 
the requesting entity. 

Upon receiving the token, the requesting entity verifies its validity
by verifying the signature in the TimeStampToken and by verifying that
what was time stamped corresponds to what was requested to be time 
stamped.  The requester should verify that the TimeStampToken contains
the correct time, the correct TSA name, the correct data imprint and 
the correct hash algorithm OID.  Since the TSAs certificate may have 
been revoked, the appropriate ARL should be checked to verify that the 
certificate is still valid.  The token can now be used to establish a 
trusted time reference.

4. Request and Token Formats

A time stamping request is as follows.

TimeStampReq ::= SEQUENCE  {
     requester                [0] GeneralName OPTIONAL,
     reqPolicy                [1] PolicyInformation OPTIONAL,
     tsa                          GeneralName,
     messageImprint               MessageImprint  
       --a hash of the data to be time stamped              
}

The reqPolicy field, if included, indicates the policy under which the 
TimeStampToken should be provided.  PolicyInformation is defined in 
Section 4.2.1.5 of PKIX Part 1 [PKIX1].

The tsa field identifies the name of the TSA.  GeneralName is defined
in Section 4.2.1.7 of PKIX Part 1 [PKIX1].

MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }

The hash algorithm indicated in the hashAlgorithm field must be a strong

Document Expiration:  Jan. 29, 1998                               Page 2

hash algorithm.  That means that it must be one-way and collision 
resistant.  It is up to the Time Stamp Authority to decide whether or 
not the given hash algorithm is sufficient (based on the current state 
of knowledge in cryptanalysis and the current state of the art in 
computational resources, for example).  

The hashedMessage field should contain the hash of the message to be 
time stamped.  The hash is represented as an OCTET STRING.

A time stamp token is as follows.  The signature is computed over
tstInfo (encoded using the ASN.1 distinguished encoding rules (DER)).

TimeStampToken ::= SEQUENCE  {
     tstInfo                      TSTInfo,
     signature                    BIT STRING,
       --over the ASN.1 DER encoding of tstInfo   
}

TSTInfo ::= SEQUENCE  {
     policy                       PolicyInformation,
     status                       PKIStatusInfo,
     requester               [0]  GeneralName OPTIONAL,
       --must be present if the requester field is present in 
       --TimeStampReq
     tsa                          GeneralName,
     signatureAlgorithm           AlgorithmIdentifier,
     certId                       CertId,
       --must refer to the TSAs public verification certificate
     certs                        SEQUENCE OF Certificate OPTIONAL,
     genTime                      GeneralizedTime,
     messageImprint               MessageImprint
       --this field must have the same value as the similar field
       --in TimeStampReq                             
}

PKIStatusInfo is defined in Section 3.2.3 of PKIX Part 3 [PKIX3].  The
status field is present to indicate whether or not the time stamping 
request was fulfilled and, if not, the reason it was rejected. A valid 
time stamp token will always have value 0 (granted) in the PKIStatus 
field of PKIStatusInfo.

CertId is defined in Section 3.2.4 of PKIX Part 3 [PKIX3].

5. Time Stamp Protocol Using E-mail

This section specifies a means for conveying ASN.1-encoded messages 
for the protocol exchanges described in Section 4 via Internet mail. 

A simple MIME object is specified as follows.

   Content-Type: application/x-pkix5
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded PKIX-5 message, base64-encoded>>

This MIME object can be sent and received using common MIME processing 

Document Expiration:  Jan. 29, 1998                               Page 3

engines and provides a simple Internet mail transport for PKIX-5 
messages.

7. Security Considerations

When designing a TSA service, the following considerations have been 
identified that have an impact upon the validity or trust in the time 
stamp token.

     1. The TSA private key is compromised and the corresponding 
        certificate is revoked.  In this case, any token signed by the 
        TSA using that private key cannot be trusted.  For this reason, 
        it is imperative that the TSAs private key be guarded with 
        proper security and controls in order to minimize the 
        possibility of compromise.  In case the private key does become
        compromised, an audit trail of all tokens generated by the TSA
        may provide a means to discriminate between genuine and false 
        tokens.

     2. The TSA signing key must be of a sufficient length to allow for 
        a sufficiently long lifetime.  Even if this is done, the key 
        will have a finite lifetime.  Thus, any token signed by the TSA 
        should be time stamped again at a later date to renew the trust 
        that exists in the TSAs signature. 

8. References

[ISONR] ISO/IEC 10181-5:  Security Frameworks in Open Systems.  
Non-Repudiation Framework.

[PKIX1] R. Housley, W. Ford, W. Polk, D. Solo, Internet Public Key
Infrastructure, Part I:  X.509 Certificate and CRL Profile, draft-
ietf-pkix-ipki-part1-0X.txt, 1997 (work in progress).

[PKIX3] C. Adams, S. Farrell, Internet Public Key Infrastructure, Part
III:  Certificate Management Protocols, draft-ietf-pkix-ipki3cmp-
0X.txt, 1997 (work in progress).

9. Authors Addresses

Carlisle Adams                        Pat Cain
Entrust Technologies                  BBN
750 Heron Road, Suite 800             70 Fawcett Street
Ottawa, Ontario                       Cambridge, MA 02138
K1V 1A7                               U.S.A.
CANADA                                [email-masked]
[email-masked]

Denis Pinkas                          Robert Zuccherato
Bull S.A.                             Entrust Technologies
Rue Jean Jaures                       750 Heron Road, Suite 800
B.P. 68                               Ottawa, Ontario
78340 Les Clayes sous Bois            K1V 1A7
FRANCE                                CANADA
[email-masked]                 [email-masked]

Document Expiration: Jan. 29, 1998                                Page 4

APPENDIX A - Storage of Data and Token

A time stamp token is meaningless without its associated data.  Thus, a 
method is required to allow users to store the data and token together 
securely.  They may be stored as a PKCS #7 SignedData object as 
described in [PKCS7].  That is, the contentType is signedData and 
contentInfo is Data, which contains the message associated with the time 
stamp token.  The SignedData object is signed by the person storing the 
data and token.  

For this purpose, we define a PKCS #9 [PKCS9] time stamp token attribute 
type.  This attribute type specifies the time stamp token, which must be 
included as an authenticated attribute of the SignedData object.  The 
time stamp token attribute type has ASN.1 type TimeStampToken (as 
defined in Section 4 of this document).  A time stamp token attribute 
can have a single attribute value.

The object identifier timeStampToken identifies the time stamp token 
attribute type.

timeStampToken ::= { pkcs-9 n <<To be supplied>> }

[PKCS7] RSA Laboratories, The Public-Key Cryptography Standards
(PKCS), RSA Data Security Inc., Redwood City, California, November
1993 Release.

[PKCS9] RSA Laboratories, The Public-Key Cryptography Standards
(PKCS), RSA Data Security Inc., Redwood City, California, November
1993 Release.

APPENDIX B - Placing a Signature At a Particular Point in Time

We present an example of a possible use of this general time stamping
service. It places a signature at a particular point in time, from 
which the appropriate CRLs must be checked.  This application is 
intended to be used in conjunction with evidence generated using a 
digital signature mechanism. 

Signatures can only be verified according to a non-repudiation policy. 
This policy may be implicit or explicit (i.e., indicated in the 
evidence provided by the signer). The non-repudiation policy can 
specify, among other things, the time period allowed by a signer to 
declare the compromise of a signature key used for the generation of 
digital signatures. Thus a signature may not be guaranteed to be valid 
until the termination of this time period.  

To verify a signature that incorporates an untrusted time, the following 
basic technique may be used: 

A) Time stamping information needs to be obtained by the signer or 
a verifier.

     1) The signature is presented to the Time Stamping Authority (TSA).  
        The TSA then returns a TimeStampToken (TST) upon that signature.

Document Expiration: Jan. 29, 1998                                Page 5

     2) The invoker of the service must then verify that the 
        TimeStampToken is correct.

B) The validity of the evidence must be verified :

     1) The date/time indicated by the signer in the signature shall be 
        compared with the date/time in the TST. If they are not close 
        enough (e.g., less than a few hours) the evidence is considered 
        to be invalid.  

2) The certificate included in the signed message should be 
        verified to be valid at the time of the signature. It must 
        first be verified and then the appropriate CRL must be 
        checked.

The signature has now been placed at a particular point in time.  The
appropriate CRLs may be examined to determine the validity of the 
signature at that time.

Document Expiration: Jan. 29, 1998                                Page 6

--------------ABD31DF237C--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Question about NS cert server
Cc: [email-masked]
Reply-To: [email-masked]
Date: Fri, 22 May 1998 15:18:31 (NZST)
Sender: [email-masked]

>In our CA implementation we decided to employ KISS methodology and stamp all
>certificates V3.
 
Hmm, I think that might be W.R.O.N.G. rather than K.I.S.S. :-).  X.509v3 is
silent on this (#include <stdgrumble.h>), but PKIX implies that if you mark the
cert v3 it should actually *be* v3 (it says "use version 1" rather than "MUST
use version 1" or "SHALL use version 1", so I'm not sure whether this is just a
recommendation or a "must" rule).  Logic would dictate that it should be a
"must", because anything which recodes the cert into the canonical form will
invalidate the signature on it.
 
(I've cc'd this to the PKIX list for comment).
 
Peter.

Date: Thu, 21 May 1998 12:31:35 -0700
To: [email-masked] (David P. Kemp), [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: CHOICE OF OCSP certID syntax
Sender: [email-masked]

Dave,

At 10:15 AM 5/21/98 -0400, David P. Kemp wrote:
>As discussed here previously, the cert hash by itself
>may be insufficient to serve as a retrieval index.

I recall Steve discussing a hash of the CA's key:

>While the hash of a CA's key would likely be unique, it also is a terrible
>search key in many instances. One has to be careful about the context in
>which a pointer to a CA cert is being used. In a cert, having a CA "key ID"
>that is based on the hash of the CA is fine, because we already have the CA
>name, and maybe even a locator.  In other protocol context we should have a
>similar level of naming for search purposes, and rely on something like a
>key hash just for disambiguation among multiple possible keys associated
>with the same CA.

but this doesn't speak to a hash of the subject certificate.

Do I take your response to be against the CHOICE generally?  There is
benefit to the installed base of systems that are successfully using the
{Issuer DN, subject serial number} model of certificate identification.

Mike

Date: Thu, 21 May 1998 10:33:35 -0700
To: Michael Myers <[email-masked]>, [email-masked]
From: Deepak Nadig <[email-masked]>
Subject: Re: CHOICE OF OCSP certID syntax
Sender: [email-masked]

Mike,

At 02:13 PM 5/20/98 -0700, Michael Myers wrote:
>All,
>
>We need to close on OCSP certID.  The current level of debate is
>insufficient to measure the consensus of the group.  What I've heard and
>observed so far is that the best path forward would be:
>
>CertID ::= CHOICE {
>   nameKeyAndSerial [0] NameKeyAndSerial,      -- MUST
>   nameAndSerial    [1] IssuerAndSerialNumber, -- SHOULD
>   certHash         [2] OCTET STRING }         -- SHOULD; MUST use SHA-1
>

It seems to me that since a certificate can be identified either by
{IssuerName, SerialNumber} or {IssuerAltName, SerialNumber}, CertID is
better defined as

CertID ::= SEQUENCE {
    issuerNameorAltName	IssuerNameOrAltName,
    serialNumber		CertificateSerialNumber
}

IssuerNameOrAltName ::= CHOICE {
    issuerName	IssuerName,
    issuerAltName	IssuerAltName
}

Also, I understand the CertID to be used to check the revocation status of
a certificate. If the certificate is in hand, it is simpler to use the name
and serial number. I would not recommend using a hash to represent the
certificate.

>
>+ SET uses certificate hashes in several places throughout its architecture.
>

In SET, the hashes are used mainly by the sender to notify the receiver of
the certificates possessed by it. This is more efficiently done by using
hashes, since they can be stored along with the certificates. Using any
data elements in the certificate would require decoding of every certificate.

This brings up a point with OCSP. Section 2.2 says that the response must
be signed by a key corresponding either to 

1. the CA key that issued the certificate, or
2. a key trusted by the OCSP client

How is this guaranteed when either (or both) keys are compromised ? Isn't
it necessary then for the OCSP client to notify the OCSP server of the keys
it trusts ?

Also, is the mechanism of updating the OCSP client with a new trusted key,
when the old one is compromised, within the scope of OCSP ?

Deepak

----------------------------------------------------------------------------
Deepak Nadig							email: [email-masked]
Technology Group						Phone: 408-919-5618
Internet Commerce Division, VeriFone			Fax:   408-919-8807

From: [email-masked] (Gina DePlanche)
Subject: X.509 source for sale
To: [email-masked]
Date: Thu, 21 May 1998 12:14:36 -0400 (EDT)
Sender: [email-masked]

	Hi!

	I hope it's OK to send mail to the group in this way. I'll keep
it short.

	My company is looking to implement X.509 certificates in our
router product. We are weighing the option of purchasing software versus
implementing it in-house.

	If anyone on the list works for a company which sells X.509
source code, or know of a company, I'd appreciate hearing from you.

	Thank you for your time,
	Gina

-- 
Gina M. DePlanche               |       OpenROUTE Networks, Inc.
[email-masked]               |       A subsidiary of Proteon, Inc.
(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
Fax: (508) 836-5347             |       01581-1799  MailStop #23

Date: Thu, 21 May 1998 11:06:31 -0400 (EDT)
From: Rich Salz <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: CHOICE OF OCSP certID syntax
Sender: [email-masked]

>I still believe that a DN is a better retrieval index than a
>key hash.

Me too.
	/r$

Date: Thu, 21 May 1998 10:15:51 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: CHOICE OF OCSP certID syntax
Sender: [email-masked]

> From: Michael Myers <[email-masked]>
> 
> We need to close on OCSP certID.  The current level of debate is
> insufficient to measure the consensus of the group.  What I've heard and
> observed so far is that the best path forward would be:
> 
> CertID ::= CHOICE {
>    nameKeyAndSerial [0] NameKeyAndSerial,      -- MUST
>    nameAndSerial    [1] IssuerAndSerialNumber, -- SHOULD
>    certHash         [2] OCTET STRING }         -- SHOULD; MUST use SHA-1
> 
> IssuerAndSerialNumber ::= SEQUENCE {
>     issuer        Name,
>     serialNumber  SerialNumber }
> 
> SerialNumber ::= INTEGER
> 
> NameKeyAndSerial  ::= SEQUENCE {
>    issuerNameAndKey     IssuerNameAndKey,
>    serialNumber         CertificateSerialNumber }
> 
> IssuerNameAndKey ::= SEQUENCE {
>    issuer			Name,
>    issuerAltName	[0]	EXPLICIT IssuerAltName OPTIONAL,
>    keyIdentifier		KeyIdentifier }

Mike,

I agree with Brian that certHash should be dropped.

The S/MIME discussions have identified certHash as a signed attribute
to provide cryptographic binding between the signed content and the
specific cert used for signing.  However, CMS also includes a mandatory
unprotected issuerAndSerialNumber field which selects the signer's cert
in the first place, before the optional hash attribute is used to
confirm it.  As discussed here previously, the cert hash by itself may
be insufficient to serve as a retrieval index.

With regard to nameKeyAndSerial, I don't see how:

  { issuer Name, [issuerAltName], keyIdentifier, serialNumber }

offers any advantage at all over:

  { issuer Name, [issuerAltName], serialNumber }

In other words, keyIdentifier doesn't provide any selection advantage
when added to issuerAndSerialNumber, and it doesn't provide any
cryptographic advantage either.  So nameKeyAndSerial should be dropped
too.

Since OPTIONAL always makes the developer's job harder, and since
procedures for handling issuer altNames in path processing do not
currently exist, I would prefer to leave out issuerAltName too.  But
I don't want to hold up OCSP until the path processing debate works
itself out, so I'd reluctantly accept an OPTIONAL issuerAltName.

I am very sympathetic to Slava Galperin's proposal that:

  { Hash(IssuerPublicKey), serialNumber }

is sufficient to uniquely identify a cert, neatly sidesteps the altName
debate, and saves space.  I'd also note that it has a very SPKI-like
flavor, which may be regarded as an advantage or a disadvantage :-).
However, I still believe that a DN is a better retrieval index than a
key hash.  I'll defer to the directory experts on how difficult it
would be to implement matches based on the hash of the issuer's public
key.  Conceptually it is simple.  If it is also simple in practice, I
would support this proposal.

Here are three alternatives:

-- Bad

  CertID ::= SEQUENCE {
     issuer            Name,
     issuerAltName [0] EXPLICIT IssuerAltName OPTIONAL,
     serialNumber      CertificateSerialNumber,
     issuerKeyHash     IssuerKeyHash }

-- Better

  CertID ::= SEQUENCE {
     serialNumber    CertificateSerialNumber,
     issuerKeyHash   IssuerKeyHash }

-- Best

  CertID ::= SEQUENCE {
     issuer          Name,
     serialNumber    CertificateSerialNumber,
     issuerKeyHash   IssuerKeyHash }

  IssuerKeyHash ::= SEQUENCE {
     algorithmId     AlgorithmIdentifier,
     hashValue       OCTET STRING }  -- hash of issuer's subjectPublicKeyInfo
                                     -- with applicable parameters present

Date: Wed, 20 May 1998 16:00:20 -0700
To: Brian Korver <[email-masked]>, [email-masked] (Michael Myers)
From: Michael Myers <[email-masked]>
Subject: Re: CHOICE OF OCSP certID syntax
Cc: [email-masked]
Sender: [email-masked]

Brian,

Thanks for the insight into the SET requirements.

Mike

At 02:52 PM 5/20/98 -0700, Brian Korver wrote:
>Mike,
>
>A couple of comments....
>
>Michael Myers writes:
>> 
>> All,
>> 
>> We need to close on OCSP certID.  The current level of debate is
>> insufficient to measure the consensus of the group.  What I've heard and
>> observed so far is that the best path forward would be:
>> 
>> CertID ::= CHOICE {
>>    nameKeyAndSerial [0] NameKeyAndSerial,      -- MUST
>>    nameAndSerial    [1] IssuerAndSerialNumber, -- SHOULD
>>    certHash         [2] OCTET STRING }         -- SHOULD; MUST use SHA-1
>
>Sorry if I haven't been paying close enough attention, but what is the
>argument for not including an algorithm OID for certHash?  It seems
>short-sighted to me to leave it out.
>
>That said, I'm in favor of dropping certHash.
>
>
>> 
>> If you have an opinion on this, if only YES or NO, please put it to the
>> list, although read on a bit before you make up your mind.
>> 
>> The question is not if there *should* be a single, unified method to
>> identify a certificate but rather *will* there be?  I'm coming to doubt it:
>> 
>> + In the good old days, Issuer DN and certificate serial number were
>> sufficient (and still are when operating strictly within a closed PKI).
>> 
>> + SET uses certificate hashes in several places throughout its
architecture.
>
>Sort of.  SET does not use hashes of certificates, but rather hashes
>of the inner content of certificates.  This is a bad idea because it
>requires that the certificate be (at least partially) decoded before
>it can be hashed.  
>
>Having implemented SET, I haven't found the certificate hash construct to
>be any improvement on Issuer+Serial and I would prefer the simplicity of
>fewer choices.  
>
>
>
>> 
>> + The {issuer name, hash of public key, certificate serial number} of the
>> current OCSP draft is on the table.
>> 
>> + Many applications today already display a hash to enable users to
>> directly match a certificate's "fingerprint" to a store of certificates.
>> This speaks to the utility of a manual, cut-and-paste query capability.
>> 
>> + Recent discussions in the S/MIME group have identified a certificate hash
>> as a candidate mechanism for their SigningCertificate attribute (which
>> binds a specific certificate to a signed message).
>> 
>> If somebody believes that all of these contexts will change to a single,
>> unified certificate identification scheme I'd love to hear of it and why
>> you think so.  I'm willing to be convinced.  But, looking at this
>> diversity, it only makes sense to me to put in a CHOICE and let profiling
>> activity govern futher evolution.
>
>Forget about SET -- it uses Issuer+Serial in all the normal places, and
>its certificate hash is unique, I believe, to SET.
>
>
>> 
>> This will allow us to advance OCSP without risking a disconnect between
>> PKIX and other groups or other non-IETF contexts, while at the same time
>> maintaining the current level of consensus on certificate identification.
>> It also benefits potential early adopters of this technology who want to
>> keep their options open while PKI solutions evolve and converge.  Last,
>> there are a few brave souls out there who produced and are operating
>> prototype versions of OCSP-02.  The proposed CHOICE enables them to reuse
>> much of their existing architecture should they wish to advance their
>> existing pilots forward (modulo a bit of ASN.1 wrapping).
>> 
>> The rest of the syntax would look like:
>> 
>> IssuerAndSerialNumber ::= SEQUENCE {
>>     issuer        Name,
>>     serialNumber  SerialNumber }
>> 
>> SerialNumber ::= INTEGER
>> 
>> NameKeyAndSerial  ::= SEQUENCE {
>>    issuerNameAndKey     IssuerNameAndKey,
>>    serialNumber         CertificateSerialNumber }
>> 
>> IssuerNameAndKey ::= SEQUENCE {
>>    issuer			Name,
>>    issuerAltName	[0]	EXPLICIT IssuerAltName OPTIONAL,
>>    keyIdentifier		KeyIdentifier }
>> 
>> Mike
>> 
>> 
>
>
>brian
>[email-masked]
>
>

From: Brian Korver <[email-masked]>
Subject: Re: CHOICE OF OCSP certID syntax
To: [email-masked] (Michael Myers)
Date: Wed, 20 May 1998 14:52:53 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

Mike,

A couple of comments....

Michael Myers writes:
> 
> All,
> 
> We need to close on OCSP certID.  The current level of debate is
> insufficient to measure the consensus of the group.  What I've heard and
> observed so far is that the best path forward would be:
> 
> CertID ::= CHOICE {
>    nameKeyAndSerial [0] NameKeyAndSerial,      -- MUST
>    nameAndSerial    [1] IssuerAndSerialNumber, -- SHOULD
>    certHash         [2] OCTET STRING }         -- SHOULD; MUST use SHA-1

Sorry if I haven't been paying close enough attention, but what is the
argument for not including an algorithm OID for certHash?  It seems
short-sighted to me to leave it out.

That said, I'm in favor of dropping certHash.

> 
> If you have an opinion on this, if only YES or NO, please put it to the
> list, although read on a bit before you make up your mind.
> 
> The question is not if there *should* be a single, unified method to
> identify a certificate but rather *will* there be?  I'm coming to doubt it:
> 
> + In the good old days, Issuer DN and certificate serial number were
> sufficient (and still are when operating strictly within a closed PKI).
> 
> + SET uses certificate hashes in several places throughout its architecture.

Sort of.  SET does not use hashes of certificates, but rather hashes
of the inner content of certificates.  This is a bad idea because it
requires that the certificate be (at least partially) decoded before
it can be hashed.  

Having implemented SET, I haven't found the certificate hash construct to
be any improvement on Issuer+Serial and I would prefer the simplicity of
fewer choices.  

> 
> + The {issuer name, hash of public key, certificate serial number} of the
> current OCSP draft is on the table.
> 
> + Many applications today already display a hash to enable users to
> directly match a certificate's "fingerprint" to a store of certificates.
> This speaks to the utility of a manual, cut-and-paste query capability.
> 
> + Recent discussions in the S/MIME group have identified a certificate hash
> as a candidate mechanism for their SigningCertificate attribute (which
> binds a specific certificate to a signed message).
> 
> If somebody believes that all of these contexts will change to a single,
> unified certificate identification scheme I'd love to hear of it and why
> you think so.  I'm willing to be convinced.  But, looking at this
> diversity, it only makes sense to me to put in a CHOICE and let profiling
> activity govern futher evolution.

Forget about SET -- it uses Issuer+Serial in all the normal places, and
its certificate hash is unique, I believe, to SET.

> 
> This will allow us to advance OCSP without risking a disconnect between
> PKIX and other groups or other non-IETF contexts, while at the same time
> maintaining the current level of consensus on certificate identification.
> It also benefits potential early adopters of this technology who want to
> keep their options open while PKI solutions evolve and converge.  Last,
> there are a few brave souls out there who produced and are operating
> prototype versions of OCSP-02.  The proposed CHOICE enables them to reuse
> much of their existing architecture should they wish to advance their
> existing pilots forward (modulo a bit of ASN.1 wrapping).
> 
> The rest of the syntax would look like:
> 
> IssuerAndSerialNumber ::= SEQUENCE {
>     issuer        Name,
>     serialNumber  SerialNumber }
> 
> SerialNumber ::= INTEGER
> 
> NameKeyAndSerial  ::= SEQUENCE {
>    issuerNameAndKey     IssuerNameAndKey,
>    serialNumber         CertificateSerialNumber }
> 
> IssuerNameAndKey ::= SEQUENCE {
>    issuer			Name,
>    issuerAltName	[0]	EXPLICIT IssuerAltName OPTIONAL,
>    keyIdentifier		KeyIdentifier }
> 
> Mike
> 
> 

brian
[email-masked]

Date: Wed, 20 May 1998 14:13:20 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: CHOICE OF OCSP certID syntax
Sender: [email-masked]

All,

We need to close on OCSP certID.  The current level of debate is
insufficient to measure the consensus of the group.  What I've heard and
observed so far is that the best path forward would be:

CertID ::= CHOICE {
   nameKeyAndSerial [0] NameKeyAndSerial,      -- MUST
   nameAndSerial    [1] IssuerAndSerialNumber, -- SHOULD
   certHash         [2] OCTET STRING }         -- SHOULD; MUST use SHA-1

If you have an opinion on this, if only YES or NO, please put it to the
list, although read on a bit before you make up your mind.

The question is not if there *should* be a single, unified method to
identify a certificate but rather *will* there be?  I'm coming to doubt it:

+ In the good old days, Issuer DN and certificate serial number were
sufficient (and still are when operating strictly within a closed PKI).

+ SET uses certificate hashes in several places throughout its architecture.

+ The {issuer name, hash of public key, certificate serial number} of the
current OCSP draft is on the table.

+ Many applications today already display a hash to enable users to
directly match a certificate's "fingerprint" to a store of certificates.
This speaks to the utility of a manual, cut-and-paste query capability.

+ Recent discussions in the S/MIME group have identified a certificate hash
as a candidate mechanism for their SigningCertificate attribute (which
binds a specific certificate to a signed message).

If somebody believes that all of these contexts will change to a single,
unified certificate identification scheme I'd love to hear of it and why
you think so.  I'm willing to be convinced.  But, looking at this
diversity, it only makes sense to me to put in a CHOICE and let profiling
activity govern futher evolution.

This will allow us to advance OCSP without risking a disconnect between
PKIX and other groups or other non-IETF contexts, while at the same time
maintaining the current level of consensus on certificate identification.
It also benefits potential early adopters of this technology who want to
keep their options open while PKI solutions evolve and converge.  Last,
there are a few brave souls out there who produced and are operating
prototype versions of OCSP-02.  The proposed CHOICE enables them to reuse
much of their existing architecture should they wish to advance their
existing pilots forward (modulo a bit of ASN.1 wrapping).

The rest of the syntax would look like:

IssuerAndSerialNumber ::= SEQUENCE {
    issuer        Name,
    serialNumber  SerialNumber }

SerialNumber ::= INTEGER

NameKeyAndSerial  ::= SEQUENCE {
   issuerNameAndKey     IssuerNameAndKey,
   serialNumber         CertificateSerialNumber }

IssuerNameAndKey ::= SEQUENCE {
   issuer			Name,
   issuerAltName	[0]	EXPLICIT IssuerAltName OPTIONAL,
   keyIdentifier		KeyIdentifier }

Mike

Date: Wed, 20 May 1998 14:20:25 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[email-masked]>
Reply-To: Anne Anderson - Sun Microsystems <[email-masked]>
Subject: Use of URIs in PKIX 1
To: [email-masked]
Sender: [email-masked]

Excuse me if this was hashed to death on an old thread...

I don't understand the PKIX 1 semantics for alternative names that contain
URI's.

4.2.1.7  Subject Alternative Name

   Where the subjectAltName extension contains a uniformResourceIdentif-
   ier, the URI is a pointer to a sequence of certificates issued by
   this CA (and optionally other CAs) to this subject.

Presumably, we are looking at a certificate that has some "issuer" or
"issuerAltName", may have an empty "subject", and has a "subjectAltName"
something like "http://host/x/y/z".

Does "this CA" mean "issuer/issuerAltName"?
 
Why do we want "a pointer to a sequence of certificates" issued by
"issuer/issuerAltName" to "subject/subjectAltName" when we are looking
at just such a certificate?  Is it for getting certificates for other
key usages, more current certificates, a certification path, or what?

And if "subject" is empty, is the "subject/subjectAltName" being certified as
associated with this public key actually "http://host/x/y/z"?

   The URI must be an absolute, not relative, pathname and must specify
   the host. This specification recognizes the following values for the
   URI scheme:  ftp, http, ldap, and mailto.  The mailto scheme indi-
   cates that mail sent to the specified address will generate an elec-
   tronic mail response (to the sender) containing the subject's certi-
   ficates.  No message is required.  If the URI scheme is ftp, then the
   information is available through anonymous ftp.  If the URI scheme is
   http or ldap, then the information may be retrieved using that proto-
   col.
   
So, if my "subjectAltName" is "mailto:[email-masked]", then this is
an alias for obtaining another copy of my certificate(s), but not an
address at which you can send me personally e-mail?

4.2.1.8 Issuer Alternative Name

   Where the issuerAltName extension contains a URI, the following
   semantics shall be assumed: the URI is a pointer to an ASN.1 sequence
   of certificates issued to this CA (and optionally other CAs).  The
   expected values for the URI are those defined in 4.2.1.7. Processing
   rules for other values are not defined by this specification.

"this CA" means the CA represented by "issuerAltName"?  Presumably, the
only certificates for "other CAs" stored there would be certificates in
a certification path leading down to "issuerAltName", right?

Anne Anderson                 Email: [email-masked]
Sun Microsystems Laboratories   Tel: (978) 442-0928
2 Elizabeth Drive, UCHL03-205   Fax: (978) 250-5067
Chelmsford, MA 01824 USA

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: Role names in certificates
Date: Tue, 19 May 1998 12:51:57 -0700
Sender: [email-masked]

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 19, 1998 10:23 AM
> To: [email-masked]
> Subject: Re: Role names in certificates
> 
> Although the use of human-readable role names (i.e. "Sales Director of
> Delta Company") may be somewhat useful when a human is making 
> the access
> decision, coded-field attributes (role 27 = "Sales Director") impose a
> rigor on the definition of a set of roles and what each role is
> intended to authorize.  Coded-field attributes require more up-front
> planning than free-form strings; I regard that as an 
> advantage of using
> attributes instead of names.

One of the considerations for the first cut of the role names was to
have specific strings that mapped into subjectAltName.  Thinking from
the point of view of an S/MIME vendor, the display of the subjectAltName
is correct (that is, S/MIME user agents simply display the exact string,
and the user figures out what to do with it).

A suggestion that has come up in private mail is to use the extended key
usage attribute to define a set of roles (I believe that this is
consistent with the "coded-field attributes" that you mentioned).
Unfortunately, in the event that a user agent does not understand a
particular coded field, the human operator cannot be given context, as
you indirectly point out.

Could this be work for both humans and non-humans by using a hybrid --
specifying human-readable information in the subjectAltName, and then
providing extendedKeyUsage OIDs to match?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Tue, 19 May 1998 13:23:02 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Role names in certificates
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
>
> At 05:18 PM 5/15/98 -0700, Denis Pinkas wrote:
> >I wonder why should we attach such an attribute in this way. I
> >believe/believed that AC (Attribute Certificates) should be used for
> >that. 
> 
> AC's could be used for this, but I think it would be good to have the
> option for clients and servers that do not understand ACs to understand
> semantics in these names.

The question is really the use of Attributes to enable Role Based
Access Control (RBAC), as opposed to using special forms of subject
Name (or altName) for RBAC, and as opposed to using Name in conjunction
with Access Control Lists (ACLs) for Identity Based Access Control
(IBAC).

Discussing Attribute Certificates is a red herring at this point.
Attributes may be contained only in a directory, or may be included in the
user's Certificate, or may be included in Attribute Certificates; the
choice of where to carry the attribute is "just" a management issue.

Although the use of human-readable role names (i.e. "Sales Director of
Delta Company") may be somewhat useful when a human is making the access
decision, coded-field attributes (role 27 = "Sales Director") impose a
rigor on the definition of a set of roles and what each role is
intended to authorize.  Coded-field attributes require more up-front
planning than free-form strings; I regard that as an advantage of using
attributes instead of names.

Dave Kemp

From: [email-masked]
To: Stephen Kent <[email-masked]>
cc: [email-masked]
Date: Tue, 19 May 1998 07:30:10 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Stephen Kent <[email-masked]> writes (in response to Bob Jueneman):

>>Another point of view, which I know that VeriSign supports, and
>>in particular Michael Baum, their VP for Practices and also the
>>chairman of the ABA group that wrote the Digital Signature Guidelines,
>>is that the definition of what is verified and what is not verified in a
>>certificate
>>can and should be defined in the CA's Certification Practice Statement.
>>And certainly VeriSign's current practices allow the user to add
information
>>(such as SSN, DOB, etc.) that may be of questionable utility, but cannot
>>reasonably be verified by the CA.
>
>I respect Mike, and he's a good friend, but this approach is not amenable
>to easy automatic processing of certs.  It is a lawyers approach, and the
>approach that a public CA, which is authoritative for nothing, would be
>expected to adopt.

No - it can be processed automatically, provided there's a distinction made
in the certificate between non-verified identification information and
verified names, suitable for being used for chaining purposes.  I think
this is Bob's position - he's advocating treating all altName stuff as
non-chaining, and requiring the presence of a DN to be used to build the
trust chain.  Under this model, the altNames are only used in the subject
field of the last certificate in a trust chain (which can be a CA, if
that's where your chain leads), and are considered notarized by the final
CA but not verified (unless that CA's CPS says they have been verified).

It's a different model from the one I think you are proposing, but it's no
less amenable to automated processing.

Now, if nobody wants to put "hints" or other non-chaining identification
data in a cert, and only wants strongly verified names, there's no need for
Bob's approach (assuming we can sort out the semantics of verified
altNames), but I've certainly heard people expressing a desire to put
things like personal e-mail addresses (things that wouldn't necessarily be
verifiable by a CA) in their certs.  The PKIX-1 document's description of
the URI name-type sounds as though it would be impossible for a CA for
verify properly, and is more intended as a hint to the verifying party as
to where to go to find more certificates.  I don't see how we can support
both sets of semantics with a single altName extension.

John

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Patent 5745574 on PKI
Reply-To: [email-masked]
Date: Tue, 19 May 1998 16:06:27 (NZST)
Sender: [email-masked]

>Fyi  ... fairly new patent on PKI.  See attachement and URL:
>
>      http://www.patents.ibm.com/details?patent_number=5745574
>
>Security infrastructure for electronic transactions (Assignee -- Entegrity 
>Solutions Corporation)
 
>From the claims it looks like they're trying to patent the PEM infrastructure 
model, several years too late (filing date December 1995, "inventor" is Sead 
Muftic).  The patent gives the latest PEM RFC's and "RGP 2.6.2" as a 
reference, but nothing much else.  I know the USPTO will allow you to patent 
anything regardless of novelty or prior art, but given that the claims match 
the RFC's given in the references which predate the patent by some years, you 
have to wonder how they got away with this one.
 
Peter.

From: "Paul Lambert" <[email-masked]>
To: [email-masked]
Date: Mon, 18 May 1998 17:20:47 -0700
Subject: Patent 5745574 on PKI
Sender: [email-masked]

Fyi  ... fairly new patent on PKI.  See attachement and URL:

      http://www.patents.ibm.com/details?patent_number=5745574

Another interesting older one covers hierarchical key management :

       http://www.patents.ibm.com/details?patent_number=4888801

Paul
------
Security infrastructure for electronic transactions (Assignee -- Entegrity
Solutions Corporation)

May 15, 1998

U.S. Patents via NewsEdge Corporation : Abstract:
A plurality of certification authorities connected by
an open network are interrelated through an
authentication and certification system for providing
and managing public key certificates. The
certification system with its multiple certification
and its policies constitute a public key infrastructure
facilitating secure and authentic transactions over
an unsecure network. Security services for
applications and users in the network are facilitated
by a set of common certification functions
accessible by well-defined application programming
interface which allows applications to be developed
independently of the type of underlying hardware
platforms used, communication networks and
protocols and security technologies.

Date: Mon, 18 May 1998 11:11:17 -0400
To: "Bob Jueneman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Bob,

	<snip>

>
>One point of view, which Steve apparently reflects, is that a CA should be
>absolutely responsible/liable for every single element contained in the
>certificate. In that case, of course, a CA would be compelled to do its
>due diligence to verify the contents, and would strongly resist including
>anything it couldn't reasonably verify, for fear of unwanted and
>unwarranted liability.
>
>Another point of view, which I know that VeriSign supports, and
>in particular Michael Baum, their VP for Practices and also the
>chairman of the ABA group that wrote the Digital Signature Guidelines,
>is that the definition of what is verified and what is not verified in a
>certificate
>can and should be defined in the CA's Certification Practice Statement.
>And certainly VeriSign's current practices allow the user to add information
>(such as SSN, DOB, etc.) that may be of questionable utility, but cannot
>reasonably be verified by the CA.

I respect Mike, and he's a good friend, but this approach is not amenable
to easy automatic processing of certs.  It is a lawyers approach, and the
approach that a public CA, which is authoritative for nothing, would be
expected to adopt.

>My own point of view is in the middle.  If I feel the need to include my
>height,
>weight, hair color, skin color, JPEG photo, fingerprint classification,
>etc., because
>I believe that will be beneficial to me in my own use of my certificate, that
>should be my business, at least within reason.
>
>>From a legal standpoint, I am making a representation to the CA, and hence to
>relying parties, in the expectation that someone may rely on the
>information. And
>therefore, if I misrepresent that information I might be liable for any
>damages
>encurred by someone who relied on it. So I, the subscriber/subject of the
>certificate, am on the hook.

Again, a lawyers perspective, and specvifically one based on a
"liability-empowered" CA model, as opposed to a CA model based on who
really is authoritative for name spaces.

>On the other hand, the CA shouldn't have to choose between honoring their
>customer's wishes (generally a poor business practice!) and becoming
>unnecessarily liable in their own right for apparently endorsing some
>"fact" which the subscriber represented to them if it turns out not to be
>true.
>
>At least part of the motivation for alternate subject names, therefore,
>was the
>recognition of the utility of "informational" names and/or other
>attributes, which
>the CA might or might not choose to independently validate.
>
>In retrospect, the semantics of these name forms was not thought through
>carefully
>enough, and now we have this argument.

There are differing views on the use of AltNames.

>My preference would be to clearly indicate what attributes were validated
>by the CA
>and which were not, though the use of a Nonverified Subscriber Information
>flag,
>and as a vendor of a CA toolkit which can both create certificates itself
>and pass them
>on to external CAs to be signed, that is exactly what we are going to
>provide for
>certain attributes.  The major (and minor) CAs can then decide whether or
>not to
>accept and sign such attributes, and we will let the market decide what
>people want.

You've made this suggestion many time, and it has been been persusive.
Given the problems we already have with folks interpreting the "critical"
bit, adding another flag of this sort to a cert would only add further
confusion to processing.

>The only other distinction that I see between a DN and an alt name is the
>greatly
>increased complexity that ensues if it is allowable to retrieve and chain
>certificates
>based on either or both name forms.
>
>Steve works for a company that is a CA, but doesn't provide a directory
>(to my
>knowledge). Novell, on the other hand, has on the order of 80 million
>customer
>nodes (users), a vast percentage of whom make daily use of NDS, our X.500-like
>directory.  Granted that the top-down, monoply carrier imposed, everyone-is-
>connected-to-the-great-X.500-directory-in-the-sky model has never
>materialized and
>probably never will, it is still quite incorrect to assume that no one is
>using certificates
>in combination with directories, as he seems to imply.

Steve works for a company that offers directory services to millions of
individuals and businesses; they happen to be globally accessible phone
directories.  How many of your clients have their Novell directories are
connected together, Bob?  I hate to ask this, but I recall that Novell also
promulgated an addressing system (for IPX) that was notorious for not
scaling to accommodate the connection of all of the client "islands."

Steve

Date: Mon, 18 May 1998 11:00:25 -0400
To: "Bob Jueneman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

Bob,

>The only reason why I can think that you would want to break up
>a DNS name into it's constituent parts would be to try to apply name
>subordination techniques to it.  But name subordination is another
>hold-over from the PEM days, whose utility has yet to be proven.

There are several motivations for the decomposition cietd in 2247, most
obviously direct mapping to a hierarchic database structure.  As for name
subordination being an oudated notion, I suggest that the NameConstraints
extension is present precisely to support this notion in a more flexible
fashion that did RFC 1422.

>Given the lack of any obvious mapping of DNS names to an
>organization's legal name, together with the problem that complex
>organizations (like holding companies) are made up of independent
>subsidiary corporations that have no obvious name relationship
>(like EDS to GM), I believe that name subordination is nearly useless,
>both for "traditional" DNs and for DNS names as well. And completely
>useless for most e-mail names, given the tendency of people to acquire
>their e-mail addresses from an ISP that has no correspondence with their
>organization at all.

Whoever assigns an e-mail address is the owner of the part of the RFC822
name space from which it was assigned, and thus is appropriate and
authoritative.  An e-mail name, if it appears in a certificate, is what is
being vouched for, not some other form of identification of a person in a
broader context.

Steve

From: [email-masked]
To: Paul Koning <[email-masked]>
cc: [email-masked]
Date: Mon, 18 May 1998 11:06:01 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Paul Koning <[email-masked]> writes:

>John> 4 Allow any combination of DNs and altNames (although probably
>John> excluding the case of a null DN in combination with no
>John> altNames), and use them for chaining.
>
>John> Plus case 0: Require DNs and don't permit altNames for anything
>John> other than end-user subject names.
>
>Nice summary.
>
>My preference is 4.
>
>Reason: the only fundamental technical requirement I can see is that
>you have to be able to construct and verify a cert chain.  A cert
>chain is nothing more than a collection of certs Ci with issuer Ii and
>subject Si such that Ii == Si+1 (or Si-1 depending on which way you
>want to read).
>
>I see nothing in this that requires S or I to be a DN.  Nor does it
>require each cert to carry only one S and one I apiece.  To check a
>cert that carries a number of issuer (alt)names, I need another cert
>that contains at least one of those names among its subject names.
So you are picking a set of semantics that regards all altNames as
equivalent to one another, and equivalent to the DN (if present), in the
sense that any of them alone serves to name the entity, regardless of
whether the other names are asserted or verified.  So a cert with "n"
issuers and "m" subjects is merely an optimization of n.m individual 1->1
certificates that happen to contain the same key and which are signed with
the same key.

There has also been a suggestion that the sets of names have to match
exactly (rather than there just having to be an intersection).  Back in
min-April, Paul Hoffman posted a note describing a straw poll he took at
the LA IETF:

>And, let me bring up a topic again that no one responded to before:
>when validating chains on AltNames, is it the AND of all the items
>in the GeneralNames sequence, or is it the OR of them? If my
>IssuerAltName is a SEQUENCE of three rfc822Names, and you're
>comparing against a cert that has just one of those names, does
>the comparison pass or fail? In asking people in the hallways in
>LA, I got about a 50/50 split of what people thought it was.
>This alone should scare us away from using AltNames and expecting
>people writing validating code to get it right.
It's not at all clear either that none of the other obvious possibilities
(e.g. Subject(A) must be a subset of issuer(B) for A to chain to B) might
also be appropriate.

Can someone come up with an example of the sorts of uses to which a
certificate with multiple names might be put (other than an end-user cert
with multiple subject names)?  Are these examples consistent with the sorts
of things that we want to use end-user alternate subject names for?

Presumably under the intersection interpretation, the altNames would not
have to be marked critical (unless there is no DN), as a verifying party
that didn't understand how to compare altNames would "fail secure" if it
just ignored them.

Also, presumably the DN (if present) would be lumped together with any DNs
in the altName field prior to performing the intersection comparison, so
that a cert containing {subject=Fred, subjectAltName(DN)=jim} would chain
to a cert containing {issuer=Jim}.

What happens if some of the subject names fail a nameConstraints check?
For example, if a certificate has both a DN and a DNS name identifying its
subject, but the DNS name is outside the permittedSubtrees in the DNS space
(or there isn't an explicit permittedSubtree constraint for the DNS space,
but there is for the DN space, which (I think) implies a null
permittedSubtrees for all other namespaces).  Can the certificate be
verified?

Cert 0: Issuer {DN:"/C=US/O=Public CA Company (PCC)",
        Subject {DN:"/C=US/O=Iris/CN=CA"}
        permittedSubtrees {DN:"/C=US/O=Iris",
                           DNS:"Iris.com"}

Cert A: Issuer {DN:"/C=US/O=Iris/CN=CA",
                DNS:"ca.Iris.com"}
        Subject {DN:"/C=US/O=Iris/OU=Org1/CN=CA"}
        permittedSubtrees {DN:"/C=US/O=Iris/OU=Org1"}

Cert B: Issuer {DN:"/C=US/O=Iris/OU=Org1/CN=CA",
                DNS:"Org1-CA.Iris.com"}
        Subject {DN:"/C=US/O=Iris/OU=Org1/CN=Host1"}

Cert C: Issuer {DN:"/C=US/O=Iris/OU=Org1/CN=CA",
                DNS:"Org1-CA.Iris.com"}
        Subject {DNS:"host1.Org1.Iris.com"}

Cert D: Issuer {DN:"/C=US/O=Iris/OU=Org1/CN=CA",
                DNS:"Org1-CA.Iris.com"}
        Subject {DN:"/C=US/O=Iris/OU=Org1/CN=Host1",
                 DNS:"host1.Org1.Iris.com"}

Cert E: Issuer {DN:"/C=US/O=Iris/OU=Org1/CN=CA"}
        Subject {DN:"/C=US/O=Iris/OU=Org1/CN=John Wray",
                 RFC822: "[email-masked]",
                 RFC822: "[email-masked]}

Cert A is cut by the Iris CA, delegating responsibility for the OU=Org1
subtree to a secondary CA "/C=US/O=Iris/OU=Org1/CN=CA".  Cert B is
obviously verifiable by this cert.  Cert C isn't (since the subject name of
Cert C isn't compatible with Cert A's permittedSubtrees constraint).  How
about cert D, which is sort-of B and C combined into one certificate?  Is
the certificate as a whole verifiable, but the DNS subject name not?  Or is
the entire certificate thrown out?  If the former, the path processing
algorithm has now to calculate the set of "verified names" for each
certificate, rather than simply assuming that all subject names in a
verified certificate are equally valid.

Under either interpretation, it doesn't seem possible to use the
subjectAltName field to supply an RFC822 e-mail address for end-entities,
something that's often given as an example of something we'd like to be
able to do with certificates in the Internet world.  For an end-entity cert
to contain an e-mail address, RFC822 addresses would have to be explicitly
permitted in every certificate in the entire chain that contains any
nameConstraints.  So in the example above, either Cert E would fail to
verify entirely, or the RFC822 addresses in it wouldn't be included in the
"verified names" calculated for the certificate.

John

From: "Miklos, Sue A." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Role names in certificates
Date: Mon, 18 May 1998 09:05:17 -0400
Sender: [email-masked]

A few years back, we had tried to get concensus on role name
conventions, with no success.  We ended up creating (yet another)
subject directory attribute extension that contained approximately 18
"roles" and had a brief description of each role.  That way, each
organization could call their particular function anything they wanted
to, yet it mapped back to a bit set in this extension.  The empirical
evidence shows that most are mapping to about 2 or 3 of this bits,
leading me to believe we created too much granularity. However, if the
concept takes off, maybe the usage will, as well.

Sandi

>----------
>From: 	Blake Ramsdell[SMTP:[email-masked]]
>Sent: 	Friday, May 15, 1998 11:47 AM
>To: 	[email-masked]'
>Cc: 	[email-masked]'
>Subject: 	RE: Role names in certificates
>
>> -----Original Message-----
>> From: Denis Pinkas [mailto:[email-masked]]
>> Sent: Friday, May 15, 1998 5:18 PM
>> To: Blake Ramsdell
>> Cc: [email-masked]'
>> Subject: Re: Role names in certificates
>> 
>> Normally in a subjectAltName we should only describe the syntax of the
>> name, NOT the SEMANTIC of the name.
>
>This is part of what's being explored.  As you point out, attribute
>certificates may be The Right Way to express name semantics, so my
>proposal to associate semantics with subjectAltName may be a Bad Idea.
>That's part of what I'd like to figure out.  Do you have any suggestions
>as to how you might represent the semantics that I have proposed using
>an AC?  Is there a definitive source that says that altNames cannot
>express semantics?  I'm not trying to be a wise guy -- I don't have a
>good, definitive reference that shines the elusive light of X.509 truth
>on the answer.  Well, there's Peter's guide, and PKIX Part 1...
>
>In discussions on the S/MIME list, the consensus seemed to be that ACs
>had a bit of work that needed to be done before they were ready for
>prime time.  I am far from an expert on their popularity and use, so I'm
>not prepared to argue for or against them.  I just generally have a bad
>feeling about their use right now, that could very well be unfounded.
>
>> In addition, I took a look at the document again and I realized that I
>> was focussing on the word "role" too much.
>> 
>> "Role" has already some meaning for me (e.g. the case of the Sales
>> Director of the Delta Company). For the cases you consider, if this
>> document is going forward, I would rather prefer that we 
>> attempt to use
>> a different naming to avoid the confusion. Any other proposal 
>> (different
>> from simply "role") ?
>
>I agree -- there has been some confusion regarding the "sales director"
>role vs. the "domain signing authority" role.  Any suggestions welcome,
>and I will certainly scratch my head some more.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>

From: Nilsson Hans <[email-masked]>
To: [email-masked]
Subject: CRL vs OCSP
Date: Mon, 18 May 1998 13:09:39 +0100
Sender: [email-masked]

There has been some discussion recently here in Sweden regarding CRLs vs
OCSP for checking possibly revoked certificates. 

I have the impression that OCSP is most suitable for mail clients, who want
to verify a certificate, and who can not subscribe to all CRLs in the world,
whereas CRLs are more suitable for on-line servers, for example for an
"Internet Bank" or "IKEA Online", who already have decided only to trust
certain CAs, and then subscribe to their CRLs.

Is there any common view within PKIX on this? Are CRLs dead or not?

Hans Nilsson
AU-System Network
Stockholm SWEDEN

Date: Fri, 15 May 1998 14:57:54 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

If we are "voting"  Denis and Steve sound like they are on the right track, my vote is "yes"

>>> Denis Pinkas <[email-masked]> 05/15/98 04:51PM >>>
Steve,

Thank you for holding the position. :-)

I would like just to bring you my support and say that I endorse 
your arguments. Extracting some of your sentences, I fully support:

" I cannot endorse mandating DN use of issuers"

" The PKIX Part 1 spec was explicit about NOT requiring use of 
  issuer or subject DNs. I'd like to maintain that feature".

" .. for over a year, (..) DNs were optional for issuers and subjects,
     IF AltNames were used."

" I vote for i!"

Denis

> John,
> 
> >Nobody's suggesting that users should make up DNs.  The suggestion is that
> >they (or rather the CA they register with) should follow an IETF standards
> >track RFC (RFC 2247) that defines a simple syntactic mapping from DNS name
> >"a.b.c.d" to DN "/DC=d/DC=c/DC=b/DC=a" (or "DC=a,DC=b,DC=c,DC=d" to use the
> >LDAP printable syntax).  RFC 2247 defines the two name forms as equivalent
> >- different ways of representing the same underlying abstract name, just as
> >the two strings "a.b.c.d" and "A.B.C.D" are merely different ways or
> >representing the same underlying DNS name.
> 
> Fair enough, the mapping is simple. It's also redundant and inefficient
> relative to the AltName representation.  Maybe what we really need here is
> an articulation of a consistent set of reasons that motivate use of the
> DNS-as-DN representation.  I'm sure you have good motivations, but they are
> not being stated in a consolidated fashion.  Merely because we can
> represent these IDs that way does not mean that we should, and it certainly
> does not suggest that we ought to discriminate by requiring such
> representation in certs to the exlcusion of the AltName forms.
> 
> Steve

-- 
      Denis Pinkas     Bull S.A.          mailto:[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, 15 May 1998 15:02:18 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

> From: Stephen Kent <[email-masked]>
> 
> If you don't agree on the difference between object classes defined by
> X.500 in the context of their definition of DNs, and the ITEF generating a
> standard that also defines how to represent DNS names in DNs, I don't we
> can have a useful conversation in this regard.

Steve,

I believe that this thread began with a request that the PKIX Part 1
make an explicit statement regarding the use of RFC 2247 names.  Following
the request comes a debate; following the debate will come a decision.

If a consensus-based positive decision is made, I would hope that an
IETF PKIX standards-track document specifying how to represent DNS
names in a DN would hold approximately equal weight, at least within
the Internet community, as X.500 object classes.

Regards,
Dave Kemp

Date: Fri, 15 May 1998 14:01:38 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

>>>>> "John" == John Wray <[email-masked]> writes:

 John> It seems that some important formatting info got stripped off
 John> my previous message, namely the numbering of the various cases
 John> of altname inclusion.  Hopefully it was obvious, but here's how
 John> the list should have looked:

 John> 1 Require the presence of a DN in every certificate to be used
 John> for chain processing, but allow altName fields to be present
 John> for other (non-chaining) purposes (e.g. additional
 John> identification information, directory or other certificate
 John> location hints, etc).

 John> 2 Allow a single name, expressed as either a DN or an altName,
 John> in each certificate, and use it for chaining.

 John> 3 Allow either a DN or one or more altNames, but not both, in
 John> each certificate, and use them for chaining.

 John> 4 Allow any combination of DNs and altNames (although probably
 John> excluding the case of a null DN in combination with no
 John> altNames), and use them for chaining.

 John> Plus case 0: Require DNs and don't permit altNames for anything
 John> other than end-user subject names.

Nice summary.

My preference is 4.  

Reason: the only fundamental technical requirement I can see is that
you have to be able to construct and verify a cert chain.  A cert
chain is nothing more than a collection of certs Ci with issuer Ii and 
subject Si such that Ii == Si+1 (or Si-1 depending on which way you
want to read).  

I see nothing in this that requires S or I to be a DN.  Nor does it
require each cert to carry only one S and one I apiece.  To check a
cert that carries a number of issuer (alt)names, I need another cert
that contains at least one of those names among its subject names.

Did I miss anything here?

About the only drawback I can see in having this much flexibility is
that it requires set operations (intersect {Ii} with {Si+1} and look
for non-empty) rather than simple comparisons.  Doesn't sound like a
major hassle, but if that's considered too much trouble, the logical
conclusion is to adopt alternative 2 instead.

None of the above would block a particular CA from being more
restrictive in what certs they will issue, and such restrictions
wouldn't cause any trouble.

One reason (other than principle) why I want this flexibility is that
it simplifies life for certs managed within an organization.  It seems 
to me that a lot of discussion is driven by certs as cross-org tools
in electronic payment applications and stuff like that.  That's fine,
but there are also the sort of apps I mentioned earlier -- certs used
to authorize IPsec SAs, within a single organization.  By definition
that's an IP-oriented organization, for which DNS names and IP
addresses are obvious sorts of names to use.  Therefore I want to be
able to have them create and use certs in the form most natural to
them, which as far as I can tell are altnames.  Bottom line: altnames
should be allowed in chain construction, hence alternatives 0 and 1
are not sufficient.

	paul

Date: Fri, 15 May 1998 08:52:48 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Role names in certificates
Sender: [email-masked]

At 05:18 PM 5/15/98 -0700, Denis Pinkas wrote:
>I wonder why should we attach such an attribute in this way. I
>believe/believed that AC (Attribute Certificates) should be used for
>that. 

AC's could be used for this, but I think it would be good to have the
option for clients and servers that do not understand ACs to understand
semantics in these names.

>Normally in a subjectAltName we should only describe the syntax of the
>name, NOT the SEMANTIC of the name.

That's why this is a separate draft and not part of Part 1. Someone can
implement Part 1 and not the role draft still be able to handle all
addresses that come from an agent that is following the role draft. It is
an extension that does not affect the semantics of Part 1.

>"Role" has already some meaning for me (e.g. the case of the Sales
>Director of the Delta Company). For the cases you consider, if this
>document is going forward, I would rather prefer that we attempt to use
>a different naming to avoid the confusion. Any other proposal (different
>from simply "role") ?

I would want to see what other word you suggested before commenting on
this. I think "role" works just fine for what the draft is describing. The
programs that sign and/or encrypt are taking the role of "this group's
signer and/or encrypter". It is like a secretary or assistant function, and
those are roles in my mind. We should stay away from terms that have too
many meanings, like "agent".

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: Role names in certificates
Date: Fri, 15 May 1998 08:47:14 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Friday, May 15, 1998 5:18 PM
> To: Blake Ramsdell
> Cc: [email-masked]'
> Subject: Re: Role names in certificates
> 
> Normally in a subjectAltName we should only describe the syntax of the
> name, NOT the SEMANTIC of the name.

This is part of what's being explored.  As you point out, attribute
certificates may be The Right Way to express name semantics, so my
proposal to associate semantics with subjectAltName may be a Bad Idea.
That's part of what I'd like to figure out.  Do you have any suggestions
as to how you might represent the semantics that I have proposed using
an AC?  Is there a definitive source that says that altNames cannot
express semantics?  I'm not trying to be a wise guy -- I don't have a
good, definitive reference that shines the elusive light of X.509 truth
on the answer.  Well, there's Peter's guide, and PKIX Part 1...

In discussions on the S/MIME list, the consensus seemed to be that ACs
had a bit of work that needed to be done before they were ready for
prime time.  I am far from an expert on their popularity and use, so I'm
not prepared to argue for or against them.  I just generally have a bad
feeling about their use right now, that could very well be unfounded.

> In addition, I took a look at the document again and I realized that I
> was focussing on the word "role" too much.
> 
> "Role" has already some meaning for me (e.g. the case of the Sales
> Director of the Delta Company). For the cases you consider, if this
> document is going forward, I would rather prefer that we 
> attempt to use
> a different naming to avoid the confusion. Any other proposal 
> (different
> from simply "role") ?

I agree -- there has been some confusion regarding the "sales director"
role vs. the "domain signing authority" role.  Any suggestions welcome,
and I will certainly scratch my head some more.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Fri, 15 May 1998 17:18:19 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Blake Ramsdell <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Role names in certificates
Sender: [email-masked]

Blake,

I took me some time to replay to this message.  :-)

I wonder why should we attach such an attribute in this way. I
believe/believed that AC (Attribute Certificates) should be used for
that. 

Normally in a subjectAltName we should only describe the syntax of the
name, NOT the SEMANTIC of the name.

In addition, I took a look at the document again and I realized that I
was focussing on the word "role" too much.

"Role" has already some meaning for me (e.g. the case of the Sales
Director of the Delta Company). For the cases you consider, if this
document is going forward, I would rather prefer that we attempt to use
a different naming to avoid the confusion. Any other proposal (different
from simply "role") ?

Denis

> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Tuesday, May 05, 1998 2:50 PM
> > To: Blake Ramsdell
> > Cc: [email-masked]'
> > Subject: Re: Role names in certificates
> >
> >
> > > I have written a draft that I have submitted as an
> > individual (not under
> > > IETF-PKIX).  It describes a concept of using "role" names in
> > > certificates for several purposes that are not covered with
> > conventional
> > > PKIX certificates.
> >
> > I am not sure that this thread is relevant to the PKIX WG. It might be
> > more relevant to the S/MIME WG.
> 
> It may end up this way -- the original intent was to profile roles for
> other name types besides rfc822Name (specifically, dNSName).  If we end
> up just doing rfc822Name, it might end up in S/MIME, but roles in
> rfc822Name may be applicable to other profiles that use email addresses
> for end-entities.  We'll see how it hammers out, and where we end up.
> 
> > A requirement would be the need to sign a message as the
> > Sales Director
> > of the Delta Company, who may happen to be John Walker. However John
> > Walker may not have a private key of its own.
> 
> I think that this may be another use of role that has different
> semantics -- in my case the role was "This certificate belongs to an
> entity that is signing messages on behalf of individuals at this
> organization", vs. your valid example of "This certificate belongs to
> the Sales Director of the Delta Company".  This may be an additional
> role that we can consider.
> 
> > For the other following cases related to encryption, I wonder
> > why a role
> > is needed.
> 
> They may not be.  In the event that the sending agent is an MTA and it
> wants to encrypt messages to another particular MTA, I didn't know if a
> special semantic should be communicated so that there was no confusion
> during configuration that the certificate was suitable for MTA-to-MTA
> encryption.  It may not be.
> 
> The plaintext recovery role seems useful so that the sending agent can
> provide user feedback to the effect of "You are encrypting for a
> certificate that is being used for message recovery.  Is that cool?"
> 
> > 1) a signature server (from a company) is able to sign documents on
> > behalf of an employee with its own key and indicate the appropriate
> role
> > used by the employee. The employee may authenticate to that signature
> > server by whatever means. In that case the signer is the company which
> > indicates the role of the employee.
> 
> I think that the server vouching for the role of the employee is a
> separate problem.  The first point that I was hoping to get to was an
> automated agent signing all messages leaving the organization, and then
> associating semantics with that.
> 
> As a separate problem, the company gateway placing a signature on the
> message based on his assessment that this individual is indeed the
> "CFO", "CEO", or whatever, may be interesting.
> 
> > 2) a temporary certificate issued by a server of a company includes a
> > role and a temporary public key. The employee is given back the
> > temporary private key so that it can sign documens directly using that
> > private key.
> 
> In the particular usage that I have in mind (signing at the MTA), this
> would be self-defeating -- you still have to distribute keys, educate
> users, and enforce policy at the individual level.
> 
> Thanks for the comments...
> 
> Blake

-- 
      Denis Pinkas     Bull S.A.          mailto:[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, 15 May 1998 10:24:37 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[email-masked]>
Reply-To: Anne Anderson - Sun Microsystems <[email-masked]>
Subject: Re: Alternate name semantics and usage
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

>>Maybe what we really need here is an articulation of a
>>consistent set of reasons that motivate use of the
>>DNS-as-DN representation.

IF
   PKIX continues to allow blank "subject" and "issuer"
   where "subjectAltName" and "issuerAltName" are
   present
AND IF
   PKIX continues to allow certificate chaining
   through "issuerAltName" and "subjectAltName"
THEN
   There is probably no need for RFC2247 format
   DNs in "subject" and "issuer", except that it
   may be a useful "common syntax" for verifiers
   that do not understand an alternate name syntax.
END

IF
   PKIX changes PKIX 1 to require "subject" and "issuer"
AND IF
   All certificate chaining is done through "subject"
   and "issuer"
THEN
   PKIX 1 must explicitly support RFC2247 as a "common
   syntax" for conversion of names from namespaces other
   than X.500, such as DNS names.
END

Anne Anderson                 Email: [email-masked]
Sun Microsystems Laboratories   Tel: (978) 442-0928
2 Elizabeth Drive, UCHL03-205   Fax: (978) 250-5067
Chelmsford, MA 01824 USA

From: [email-masked]
To: [email-masked]
Date: Fri, 15 May 1998 10:18:07 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

It seems that some important formatting info got stripped off my previous
message, namely the numbering of the various cases of altname inclusion.
Hopefully it was obvious, but here's how the list should have looked:

1  Require the presence of a DN in every certificate to be used for chain
   processing, but allow altName fields to be present for other
   (non-chaining) purposes (e.g. additional identification information,
   directory or other certificate location hints, etc).

2  Allow a single name, expressed as either a DN or an altName, in each
   certificate, and use it for chaining.

3  Allow either a DN or one or more altNames, but not both, in each
   certificate, and use them for chaining.

4  Allow any combination of DNs and altNames (although probably excluding
   the case of a null DN in combination with no altNames), and use them for
   chaining.

Plus case 0: Require DNs and don't permit altNames for anything other than
end-user subject names.

John

From: [email-masked]
To: Stephen Kent <[email-masked]>
cc: [email-masked]
Date: Fri, 15 May 1998 09:55:45 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>>Nobody's suggesting that users should make up DNs.  The suggestion is
that
>>they (or rather the CA they register with) should follow an IETF
standards
>>track RFC (RFC 2247) that defines a simple syntactic mapping from DNS
name
>>"a.b.c.d" to DN "/DC=d/DC=c/DC=b/DC=a" (or "DC=a,DC=b,DC=c,DC=d" to use
the
>>LDAP printable syntax).  RFC 2247 defines the two name forms as
equivalent
>>- different ways of representing the same underlying abstract name, just
as
>>the two strings "a.b.c.d" and "A.B.C.D" are merely different ways or
>>representing the same underlying DNS name.
>
>Fair enough, the mapping is simple. It's also redundant and inefficient
>relative to the AltName representation.  Maybe what we really need here is
>an articulation of a consistent set of reasons that motivate use of the
>DNS-as-DN representation.  I'm sure you have good motivations, but they
are
>not being stated in a consolidated fashion.  Merely because we can
>represent these IDs that way does not mean that we should, and it
certainly
>does not suggest that we ought to discriminate by requiring such
>representation in certs to the exlcusion of the AltName forms.

RFC 2247 names aren't something I'm particularly tied to.  I'm simply
arguing that dismissing them out of hand as a hack, or as inferior in some
way to other DNs is just wrong, and shouldn't be used to bolster an
argument that DNs are inadequate.

Names in certificates are used in PKIX for two main purposes:

   To name end entities
   To link certificates together in a trust-chain

They are also used to locate certificates, but I'm not going to address
that here.

Usage 1 is accompanied by a fairly fuzzy set of requirements, in that
end-entities will probably want some say in how they name themselves, and
what identifying information they consider to be their name, or want to
accompany their name.

Usage 2 is critical to the interoperation of PKIX-compliant systems.  Given
two certificates A and B, a PKIX system has to be able to determine whether
A can be used to verify B, which among other things, requires it to
determine:

   Does subject(A) match issuer(B)?
   Do the name-constraints in effect for issuer(A) allow it to certify
   subject(A)
   Do the name-constraints in effect for issuer(A), augmented by those
   applied by certificate A, allow issuer(B) to certify subject(B)

Algorithms for answering these three questions are well-specified for the
case when A contains only DNs, and no altName fields, and where B contains
only a DN for its issuerName.  No ambiguity is introduced into chain
processing by allowing end-entity certs to use altNames in any form they
desire.

If we want to add altName fields (other than for subject(B)), there are
several degrees to which we can do this:

   Require the presence of a DN in every certificate to be used for chain
   processing, but allow altName fields to be present for other
   (non-chaining) purposes (e.g. additional identification information,
   directory or other certificate location hints, etc).
   Allow a single name, expressed as either a DN or an altName, in each
   certificate, and use it for chaining.
   Allow either a DN or one or more altNames, but not both, in each
   certificate, and use them for chaining.
   Allow any combination of DNs and altNames (although probably excluding
   the case of a null DN in combination with no altNames), and use them for
   chaining.

I'll refer to to the situation where altNames may appear only in the
subjectAltName field of end-entity certs as case 0.  I believe PKIX-1 is
currently adequate for this case only.

Algorithms for case (1) are straightforward (they're the same a case 0, and
PKIX-1 can be read to cover this case when the altName critical flag isn't
set, although I feel this is a misuse of the critical flag).

We might be able to reach agreement on algorithms to answer the three
questions above for case (2), for some subset of the defined altName types;
we don't have that agreement today (or at least, if we do, it's not written
down in PKIX-1, or in any of the proposed additions to PKIX-1 that I've
seen floated on the list).  In particular, what happens when trust chains
cross between namespaces?  What does a "*" match in a Name Constraint for a
dNSName (can it include periods, or can it only match characters within a
domain component)?  rfc822 name constraints are documented as applying both
to names represented as rfc822Name altNames, and to names represented using
PKCS#9 e-mail attributes as a DN - a natural extension of this would be to
apply dNSName constraints to RFC 2247 names, and to apply DN name
constraints that affect the /DC=* subtree to dNSName altNames, although
that's not stated.

Given the degree of disagreement on what a CA's signature means wrt
multiple altNames, and whether each individual name is an alternative, or
whether the entity is named by the the entire set, I don't believe we can
reach rapid closure on cases 3 or 4.

So we need to decide a strategy for PKIX-1: either live with DNs alone or
choose case 1, fix the ambiguities for case 2 above and only support that
case, or try to address the problems in cases 3 and 4.  I don't believe we
will get a quick resolution on cases 3 and 4.  As we need to get the PKIX
specs (PKIX-1 in particular) out ASAP, I am strongly in favor of postponing
cases 3 and 4 for a future revision of the document, and picking either DNs
alone (case 0) or case 1 or 2.

If we start off with DNs alone, that can be generalised to either case 1 or
case 2.  On the face of it, cases 1 and 2 would appear to be mutually
incompatible, so picking either would restrict our future opportunities at
generalisation.  We could try to support a combination of 1 and 2 (i.e. if
a certificate has a DN, then that is used for chaining and the cert can
have multiple altNames which are ignored, but if there's no DN, then the
cert must have a single altName which is used for chaining), but that's an
incredible kludge, and has all sorts of problems generalizing in the
future.  We could also attempt to use the critical flag to indicate whether
an altName contains a "distinguished" altName, or simply additional
identifying information, but that's misusing the definition of the critical
flag, by requiring implementations that understand the extension to apply
different semantics depending on the state of the flag.  Its interesting
that this is what the current draft of PKIX-1 apparently indicates
(although it doesn't restrict certs to using a single altName in the case
where there's no DN, nor does it restrict the use of the critical flag in
the case where there is a DN).

So, do we need to support altNames anywhere other than as subjects of
end-entity certificates?  If so, then we need to pick between cases 1 and
2, and there are strong voices arguing for each viewpoint.  Unless we can
resolve these differences quickly, we should go with the position given at
the IETF, which was that PKIX certs shall use DNs in all cases other than
in the subject field of end-entity certs (and in addition we'd need to
restrict certs from providing critical altNames along with those DNs),
which implies that chain processing is performed using DNs exclusively.

The whole discussion over RFC 2247 names was to emphasize that a
requirement to issue certificates to CAs named with DNS names isn't a
requirement to use the altName fields.

John

Date: Fri, 15 May 1998 15:51:23 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Stephen Kent <[email-masked]>
CC: [email-masked], Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Steve,

Thank you for holding the position. :-)

I would like just to bring you my support and say that I endorse 
your arguments. Extracting some of your sentences, I fully support:

" I cannot endorse mandating DN use of issuers"

" The PKIX Part 1 spec was explicit about NOT requiring use of 
  issuer or subject DNs. I'd like to maintain that feature".

" .. for over a year, (..) DNs were optional for issuers and subjects,
     IF AltNames were used."

" I vote for i!"

Denis

> John,
> 
> >Nobody's suggesting that users should make up DNs.  The suggestion is that
> >they (or rather the CA they register with) should follow an IETF standards
> >track RFC (RFC 2247) that defines a simple syntactic mapping from DNS name
> >"a.b.c.d" to DN "/DC=d/DC=c/DC=b/DC=a" (or "DC=a,DC=b,DC=c,DC=d" to use the
> >LDAP printable syntax).  RFC 2247 defines the two name forms as equivalent
> >- different ways of representing the same underlying abstract name, just as
> >the two strings "a.b.c.d" and "A.B.C.D" are merely different ways or
> >representing the same underlying DNS name.
> 
> Fair enough, the mapping is simple. It's also redundant and inefficient
> relative to the AltName representation.  Maybe what we really need here is
> an articulation of a consistent set of reasons that motivate use of the
> DNS-as-DN representation.  I'm sure you have good motivations, but they are
> not being stated in a consolidated fashion.  Merely because we can
> represent these IDs that way does not mean that we should, and it certainly
> does not suggest that we ought to discriminate by requiring such
> representation in certs to the exlcusion of the AltName forms.
> 
> Steve

-- 
      Denis Pinkas     Bull S.A.          mailto:[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

From: Sharon Boeyen <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: RE: Alternate name semantics and usage
Date: Fri, 15 May 1998 09:20:25 -0400
Sender: [email-masked]

Wow, this list has sure been busy!! Too many issues to comment on all of
them, but:

Earlier someone said they've never seen a certificate with rfc822 address in
subject alt name extension. When appropriate, we do put these in subject alt
name, but we also include a DN in the certificate. 

I don't like the idea of dumping everything into the DN, the subject alt
name field was designed for this purpose specifically and dumping
application specific names into a DN defeats the purpose of them. Despite
the bad rap DNs seem to be getting in this thread, they are actually being
used quite successfully in many places and with many different styles. 

The IETF PKIX WG should NOT try to mandate any particular naming structure
for DNs, that is up to entities being named and flexibility is needed in
order to meet the business needs of various organizations. For example, some
CAs issue certificates which contain DNs that are ONLY meaningful within
their own particular business environment. These DNs are perfectly valid and
can be resolved in the traditional way by directory systems, but to a
certificate using system which is not part of their particular business
application, these names would be totally useless and the certificates are
virtually anonymous. Business requirements will and should dictate the form
and content of DNs, not the PKIX WG.

On the issue of DNS /DN mapping, I don't consider the RFC that maps DNS
names into DNs the same as the discussion of throwing alt names into DNs
though. In the former case, a clear mapping of element by element into RDN
by RDN is provided. The DN structure is maintained and name resolution can
proceed. Matching rules are defined for the attributes just as for the X.500
ones. I think this is a perfectly valid model and some organizations may
choose to use this while others may choose the more "DN traditional"
approach and still others will use the anonymous style. As long as the
structure is the same and knowledge references maintained, this would be
seamless from a directory processing standpoint and from a certificate
processing standpoint.  In the X.500 group, we did define a set of generally
useful attributes but these were never intended to be the only ones and the
same applies to the naming and DIT structure parts of X.500. However, for
environments where you want to have directory interoperability it is
necessary that the attributes used for naming be supported and understood by
the systems processing them, so it is recommended to use well known
attributes only for naming. I do think it is especially problematic, from a
directory standpoint, to include application-specific naming information
(e.g. rfc822 addresses) in DNs. This results in unnecessary bounds on the
DIT structure an organization can set up and becomes very complicated when
more than one application is involved.

As for use of alt names in path validation, my personal preference would be
to keep things simple and rely on DNs. If that isn't possible, then we need
to be cautious about ensuring that we have properly dealt with all the
issues such as: paths which have certificates with different name forms;
priority of name form where the extension contains more than one; problems
where the certificate processing system supports one of the multiple name
forms present in the certificate, but it isn't the one of interest for the
particular validation activity;  how to specify which value is important to
path validation etc. If more specification is needed here, I'd like to see
it coordinated with the X.509 group and ensure that the PKIX work and base
509 continue to be aligned. In X.509, our current work items do allow for
enhancements in the extensions area if required.  

Sharon

Date: Thu, 14 May 1998 19:31:48 -0400
To: [email-masked], Stephen Kent <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

John,

>Nobody's suggesting that users should make up DNs.  The suggestion is that
>they (or rather the CA they register with) should follow an IETF standards
>track RFC (RFC 2247) that defines a simple syntactic mapping from DNS name
>"a.b.c.d" to DN "/DC=d/DC=c/DC=b/DC=a" (or "DC=a,DC=b,DC=c,DC=d" to use the
>LDAP printable syntax).  RFC 2247 defines the two name forms as equivalent
>- different ways of representing the same underlying abstract name, just as
>the two strings "a.b.c.d" and "A.B.C.D" are merely different ways or
>representing the same underlying DNS name.

Fair enough, the mapping is simple. It's also redundant and inefficient
relative to the AltName representation.  Maybe what we really need here is
an articulation of a consistent set of reasons that motivate use of the
DNS-as-DN representation.  I'm sure you have good motivations, but they are
not being stated in a consolidated fashion.  Merely because we can
represent these IDs that way does not mean that we should, and it certainly
does not suggest that we ought to discriminate by requiring such
representation in certs to the exlcusion of the AltName forms.

Steve

Date: Thu, 14 May 1998 19:06:44 -0400
To: Bob Jueneman <[email-masked]>, [email-masked], [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

Bob,

>John, I really don't care much, but I personally believe that the
>RFC 2247 style mapping is egregious -- more unwieldy than the
>X.400 naming. IETF "standard" or not, it's ugly, and dumb, IMHO.
>
>What is wrong with simply defining a DNS attribute that can contain the
>entire DNS name string, regardless of how many components it
>may contain?

I assume that the desire for use of the 2247-style naming is to enable use
of existing X.500 facilities to structure the name space and distribute it
in a fashion parallel to the DNS.  If one puts the whole name in as a
single attribute then one looses the tree structuring that is essential to
distributing the database (if one makes use of the existing X.500
facilities)

>Of course a decent GUI could easily transform the LDAP
>printable syntax into back into a reasonable presentation format,
>e.g., a.b.c.d. That's why I'm not particularly concerned.

Yes, for user presentation one can do that, but that doesn't take advantage
of the backend database structure mechanisms.

>The only reason why I can think that you would want to break up
>a DNS name into it's constituent parts would be to try to apply name
>subordination techniques to it.  But name subordination is another
>hold-over from the PEM days, whose utility has yet to be proven.

The NameConstraints extension is designed to allow a CA to impose name
subordination to make cross-certification safe.  It is an improvement over
the PEM model because it is selectively applicable.  However, contrary to
your assertion, most folks I know appreciate the need for this sort of
constraint whenever two organizations cross-certify.  Perhaps the basis for
disagreement is that your model for CA operations focuses on public CAs,
who can certify anything for a fee, whereas mine focuses on organizations
acting as CAs when they actually are authoritative for the name spaces
being certified.  This latter model parallels most existing infrastructures
for issuance of credentials  of various forms.  The former model seems
designed to generate revenue for third parties who, by the way, mostly
disclaim liability for their certification activities :-).

>Given the lack of any obvious mapping of DNS names to an
>organization's legal name, together with the problem that complex
>organizations (like holding companies) are made up of independent
>subsidiary corporations that have no obvious name relationship
>(like EDS to GM), I believe that name subordination is nearly useless,
>both for "traditional" DNs and for DNS names as well. And completely
>useless for most e-mail names, given the tendency of people to acquire
>their e-mail addresses from an ISP that has no correspondence with their
>organization at all.

It is much easier to argue that DNs are "nearly useless" for common
Internet applications, since there is no authority for their assignment.
We already have a handful of federal court cases dealing with resolution of
DNS name "ownership" when dispuites have arisen. DNs, today, don't get you
anywhere on the Internet, don't  really identify web servers, and don't
reliably identify users for e-mail.  DNS names, RFC 822 names, and IP
addresses do fulfill these critical requiremenmts and we know how to
administer the spaces, so let's make use of them.  You sound like you still
believe in the one, universal ID and certificate that will authenticate a
user to everyone.  That's not reality.  Reality is that we all have many
forms of ID, issued by a wide range of organizations, for use in different
roles.  There is no reason we cannot translate these ID forms into
certificates.  I have no objection to using arbitrary DNs to identify folks
in closed PKIs, e.g., as client certificate subject names.  But these don't
have to be stored in a directory, nor do they pretend to represent an
identity in any butna purely local, arbitrary sense.

Steve

Date: Thu, 14 May 1998 16:54:02 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

>>>>>> "Bob" =3D=3D Bob Jueneman <[email-masked]> writes:
>
> Bob> I agree with your scenario, and with Steve's formulation of IP
> Bob> addresses (if static), DNS names, or RFC822 names as the useful
> Bob> cert IDs.
>
> Bob> What I still cannot fathom is why he insists that those name
> Bob> forms, although perfectly valid altnames, are somehow verbotten
> Bob> for use as a legitimate RDN or DN.
>
>There's an interesting puzzle here.
>
>If IP addresses, DNS names, etc., are perfectly legitimate RDNs or
>DNs, it sounds like there is no need to have the concept of an
>AltName.   But AltName does exist; presumably it's there for a reason?
>
>Also, if RDNs let you encode the same sort of things (like DNS names)
>that you can put in AltNames, except that the syntax used is rather
>bizarre, this suggests that there is no reason for the two to have
>different semantics.  Yet people are saying that it somehow doesn't
>make sense to chain up certs via AltNames.  (Why not?  If I have an
>altname issuer in one cert, can't I have another cert that certifies
>the binding of that altname to a key?)
>
>	paul

paul,

Steve (and perhaps others) might well disagree, but I believe that=20
there are two fundamental reasons.

The first is both historic and emotional, and reflects an enormous =
cultural
gap between the highly institutionalized ISO/ITU processes and the=20
free-wheeling, lets get it done and see if it works philosophy of the =
IETF.
(Note however, that the IETF is increasingly becoming involved in=20
design-by-committee, and is becoming indistinguishable, in effect, from
the "official" standards organizations they/we often protest against.)

DNs have a lot of baggage, primarily because of the X.400 association
and a rather cumbersome printed name form (business-card representaiton)
that lots of people objected to. And unfortunately, by steadfastly =
refusing to
address the interoperability issues caused by not standardizing the schema
for DNs within a certificate, the old baggage is left undisturbed, and =
hence=20
is still disliked.  But the problem is not with the DNs, but the lack of =
an
acceptable schema. No one likes X.520/X.521, but no one since the NADF
has tried to fix the problem.

The other issue, which also arose back in the PEM days, is the=20
distinction between what might be reasonably considered=20
necessary, and/or "official" (two different concepts to be sure), vs.=20
what might be merely useful or convenient.

One point of view, which Steve apparently reflects, is that a CA should =
be=20
absolutely responsible/liable for every single element contained in the
certificate. In that case, of course, a CA would be compelled to do its=20
due diligence to verify the contents, and would strongly resist =
including=20
anything it couldn't reasonably verify, for fear of unwanted and=20
unwarranted liability.

Another point of view, which I know that VeriSign supports, and=20
in particular Michael Baum, their VP for Practices and also the=20
chairman of the ABA group that wrote the Digital Signature Guidelines,
is that the definition of what is verified and what is not verified in a =
certificate
can and should be defined in the CA's Certification Practice Statement.
And certainly VeriSign's current practices allow the user to add informatio=
n=20
(such as SSN, DOB, etc.) that may be of questionable utility, but =
cannot=20
reasonably be verified by the CA.

My own point of view is in the middle.  If I feel the need to include my =
height,=20
weight, hair color, skin color, JPEG photo, fingerprint classification, =
etc., because=20
I believe that will be beneficial to me in my own use of my certificate, =
that=20
should be my business, at least within reason.

>From a legal standpoint, I am making a representation to the CA, and hence =
to
relying parties, in the expectation that someone may rely on the informatio=
n. And
therefore, if I misrepresent that information I might be liable for any =
damages
encurred by someone who relied on it. So I, the subscriber/subject of =
the=20
certificate, am on the hook.

On the other hand, the CA shouldn't have to choose between honoring their
customer's wishes (generally a poor business practice!) and becoming=20
unnecessarily liable in their own right for apparently endorsing some=20
"fact" which the subscriber represented to them if it turns out not to be =
true.

At least part of the motivation for alternate subject names, therefore, =
was the=20
recognition of the utility of "informational" names and/or other attributes=
, which
the CA might or might not choose to independently validate.

In retrospect, the semantics of these name forms was not thought through =
carefully
enough, and now we have this argument.

My preference would be to clearly indicate what attributes were validated =
by the CA
and which were not, though the use of a Nonverified Subscriber Information =
flag,
and as a vendor of a CA toolkit which can both create certificates itself =
and pass them=20
on to external CAs to be signed, that is exactly what we are going to =
provide for
certain attributes.  The major (and minor) CAs can then decide whether or =
not to=20
accept and sign such attributes, and we will let the market decide what =
people want.

The only other distinction that I see between a DN and an alt name is the =
greatly=20
increased complexity that ensues if it is allowable to retrieve and chain =
certificates=20
based on either or both name forms. =20

Steve works for a company that is a CA, but doesn't provide a directory =
(to my=20
knowledge). Novell, on the other hand, has on the order of 80 million =
customer=20
nodes (users), a vast percentage of whom make daily use of NDS, our =
X.500-like
directory.  Granted that the top-down, monoply carrier imposed, everyone-is=
-=20
connected-to-the-great-X.500-directory-in-the-sky model has never =
materialized and=20
probably never will, it is still quite incorrect to assume that no one is =
using certificates=20
in combination with directories, as he seems to imply.

Hope this helps.

Bob

Date: Thu, 14 May 1998 18:09:44 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

>>>>> "Bob" == Bob Jueneman <[email-masked]> writes:

 Bob> I agree with your scenario, and with Steve's formulation of IP
 Bob> addresses (if static), DNS names, or RFC822 names as the useful
 Bob> cert IDs.

 Bob> What I still cannot fathom is why he insists that those name
 Bob> forms, although perfectly valid altnames, are somehow verbotten
 Bob> for use as a legitimate RDN or DN.

There's an interesting puzzle here.

If IP addresses, DNS names, etc., are perfectly legitimate RDNs or
DNs, it sounds like there is no need to have the concept of an
AltName.   But AltName does exist; presumably it's there for a reason?

Also, if RDNs let you encode the same sort of things (like DNS names)
that you can put in AltNames, except that the syntax used is rather
bizarre, this suggests that there is no reason for the two to have
different semantics.  Yet people are saying that it somehow doesn't
make sense to chain up certs via AltNames.  (Why not?  If I have an
altname issuer in one cert, can't I have another cert that certifies
the binding of that altname to a key?)

	paul

Date: Thu, 14 May 1998 16:02:37 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

I agree with your scenario, and with Steve's formulation of=20
IP addresses (if static), DNS names, or RFC822 names as
the useful cert IDs.

What I still cannot fathom is why he insists that those name
forms, although perfectly valid altnames, are somehow verbotten
for use as a legitimate RDN or DN.

Bob

>>> Paul Koning <[email-masked]> 05/14 1:02 PM >>>
Thanks!

>>>>> "Stephen" =3D=3D Stephen Kent <[email-masked]> writes:

 Stephen> Paul,
 >> Scenario: I build a box that implements IPsec, with IKE, with
 >> certificate based authentication.  Let's assume these are PKIX
 >> certificates as opposed to some other kind.
 >>=20
 >> The box is an IP box, so the customer (i.e., the network support
 >> personnel there) understand very well how DNS names, IP addresses,
 >> and such things are administered.
 >> ...
 >> Now here's the issue: the customer has to set up access
 >> authorization to this box (i.e., the right to establish IPsec
 >> SAs).  This means creating certs for each of the end users that
 >> will be speaking IPsec to this box.  What do we tell them?  What
 >> sort of names should be used?  Who administers them?  What tools
 >> are used to do so?  What are the directories that are used (not
 >> just conceptually -- what products)?

 Stephen> The most likely choices for user certs IDs are IP addresses
 Stephen> (if they are statically assigned), DNS names (if there is a
 Stephen> one-to-one user-to-host mapping and it's static), or rfc822
 Stephen> names (for pure user identification).  All of these are ID
 Stephen> forms you administrators are familiar with, as you specified
 Stephen> the scenario, so issuance of certs based on any of these
 Stephen> name forms should be "natural."  Each of these name forms
 Stephen> can be represented in certs as AltNames, or using standard
 Stephen> or ad hoc DN-embedding conventions.  For IPsec, we are
 Stephen> defining the preferred represnetations for these Internet
 Stephen> name forms, and the current draft on this topic calls for
 Stephen> use of the AltName formats, not DNs.

I thought that AltNames made sense here, which is why I'm
puzzled/disturbed at apparent efforts to restrict the use of
AltNames.  If they are inappropriate for certain uses (which may be
the case, though that isn't yet clear to me) then the obvious answer
is to document those cases and recommend in the spec (or, maybe,
require) to avoid AltNames for those specific situations.

 Stephen> Also, for IPsec, t is not clear that one needs to go to a
 Stephen> directory to fetch certs for users or firewalls.  One can
 Stephen> exchange the certs as part of the IKE negotiation, in real
 Stephen> time.  Since you note that the users have to be autorized
 Stephen> for access, not just random public users, then the
 Stephen> distribution of certs (including CA certs) can be managed as
 Stephen> part of the enrollment process, which would also involve
 Stephen> creating ACL entries (SPD entries, to use IPsec
 Stephen> terminology).

Yes, IKE has that mechanism, but by analogy with things like RADIUS it=20
may also be attractive to put the applicable certs in a central place
where the IPsec box can find them.

	paul

Date: Thu, 14 May 1998 15:55:49 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Despite my comments on RFC 2247 in particular, I do agree with you
on this issue.

bob

>>> <[email-masked]> 05/14 11:00 AM >>>
>>I agree, and in particular it's wrong to claim that an RFC 2247 name is
>>somehow less "real" or more of a hack than an X.521 OrganizationalPerson
>>name.
>
>Well, OrganizationalPerson is defined as a class in X.500, and DNs are
>defined in X.500, but RFC 2247 is not X.500 and so I do think it has a
>lesser standing, if only on that basis.

OrganizationalPerson is defined within the X.500 series in a document
titled "Selected Object Classes", not "The Most Important Object Classes",
or "The Only Object Classes That May be Used".  The introduction to this
document say that it contains definitions that may be useful across a =
range
of applications of the directory.  The sorts of applications the writers =
of
the document had in mind related to retrieving information (such a
telephone numbers) primarily about people, not to retrieving X.509
certificates for Internet hosts.  It shouldn't be any suprise that things
deemed to be "useful" in the first context aren't particularly helpful in
the second, nor should it be any suprise that names that do turn out to be
useful in the second context weren't specified in a document addressed to
the first.  That X.521 didn't define an object class for "InternetDNSname"
doesn't give RFC 2247 names any lesser standing than the name forms that
_are_ defined there.

John

Date: Thu, 14 May 1998 15:54:29 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

John, I really don't care much, but I personally believe that the
RFC 2247 style mapping is egregious -- more unwieldy than the=20
X.400 naming. IETF "standard" or not, it's ugly, and dumb, IMHO.

What is wrong with simply defining a DNS attribute that can contain the
entire DNS name string, regardless of how many components it=20
may contain?

Of course a decent GUI could easily transform the LDAP=20
printable syntax into back into a reasonable presentation format,
e.g., a.b.c.d. That's why I'm not particularly concerned.

The only reason why I can think that you would want to break up
a DNS name into it's constituent parts would be to try to apply name
subordination techniques to it.  But name subordination is another=20
hold-over from the PEM days, whose utility has yet to be proven.

Given the lack of any obvious mapping of DNS names to an=20
organization's legal name, together with the problem that complex
organizations (like holding companies) are made up of independent=20
subsidiary corporations that have no obvious name relationship=20
(like EDS to GM), I believe that name subordination is nearly useless,
both for "traditional" DNs and for DNS names as well. And completely
useless for most e-mail names, given the tendency of people to acquire
their e-mail addresses from an ISP that has no correspondence with their
organization at all.

bob

>>> <[email-masked]> 05/14 10:40 AM >>>
Stephen Kent <[email-masked]>, in reply to Bob Jueneman writes:

>>In answer to John's last point, I agree that it would be possible
>>and under some circumstances desirable, to provide those alternative,
>>not rigidly bound names or other attributes by means of a directory.
>>But although I very much WANT to be able to look up certificates, CRLs,
>>etc. in a directory, I don't think that users should be COMPELLED
>>to.
>
>And I believe that users ought not be compelled to "make up" DNs when =
they
>have perfectly good DNS names!

Nobody's suggesting that users should make up DNs.  The suggestion is that
they (or rather the CA they register with) should follow an IETF standards
track RFC (RFC 2247) that defines a simple syntactic mapping from DNS name
"a.b.c.d" to DN "/DC=3Dd/DC=3Dc/DC=3Db/DC=3Da" (or "DC=3Da,DC=3Db,DC=3Dc,DC=
=3Dd" to use the
LDAP printable syntax).  RFC 2247 defines the two name forms as equivalent
- different ways of representing the same underlying abstract name, just =
as
the two strings "a.b.c.d" and "A.B.C.D" are merely different ways or
representing the same underlying DNS name.

John

Date: Thu, 14 May 1998 15:42:27 -0400
To: Paul Koning <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

Paul,

> Stephen> The most likely choices for user certs IDs are IP addresses
> Stephen> (if they are statically assigned), DNS names (if there is a
> Stephen> one-to-one user-to-host mapping and it's static), or rfc822
> Stephen> names (for pure user identification).  All of these are ID
> Stephen> forms you administrators are familiar with, as you specified
> Stephen> the scenario, so issuance of certs based on any of these
> Stephen> name forms should be "natural."  Each of these name forms
> Stephen> can be represented in certs as AltNames, or using standard
> Stephen> or ad hoc DN-embedding conventions.  For IPsec, we are
> Stephen> defining the preferred represnetations for these Internet
> Stephen> name forms, and the current draft on this topic calls for
> Stephen> use of the AltName formats, not DNs.
>
>I thought that AltNames made sense here, which is why I'm
>puzzled/disturbed at apparent efforts to restrict the use of
>AltNames.  If they are inappropriate for certain uses (which may be
>the case, though that isn't yet clear to me) then the obvious answer
>is to document those cases and recommend in the spec (or, maybe,
>require) to avoid AltNames for those specific situations.

We agree, but others on this list insist on the primacy of DNs in all
instances.

> Stephen> Also, for IPsec, t is not clear that one needs to go to a
> Stephen> directory to fetch certs for users or firewalls.  One can
> Stephen> exchange the certs as part of the IKE negotiation, in real
> Stephen> time.  Since you note that the users have to be autorized
> Stephen> for access, not just random public users, then the
> Stephen> distribution of certs (including CA certs) can be managed as
> Stephen> part of the enrollment process, which would also involve
> Stephen> creating ACL entries (SPD entries, to use IPsec
> Stephen> terminology).
>
>Yes, IKE has that mechanism, but by analogy with things like RADIUS it
>may also be attractive to put the applicable certs in a central place
>where the IPsec box can find them.

Yes, but be aware that such retrieval (absent caching) adds further to the
SA establishment time and creates another attack point for denial of
service.

Steve

From: =?iso-8859-1?Q?H=E4ger=F6=2C_Per?= <[email-masked]>
To: "'Robert Klerer'" <[email-masked]>, [email-masked]
Subject: SV: Searching a directory for certs
Date: Thu, 14 May 1998 21:13:38 +0200
Sender: [email-masked]

Hi !

You could set up the Access Control to not returning the e-mail =
addresses
(and other info) for an entry if that the search is issued by an =
anonymous
user. Or restrict the search to only return one match since the search =
your
doing on e-mail address should only return one match (that is if the =
user
doesn=B4t have more than one entry).

-------------------------------------------
Med V=E4nlig H=E4lsning / Best Regards
Per H=E4ger=F6
Senior Consultant & Product Manager
WM-data
Tel +46 8 7758204 | Fax +46 8 7758322=20
E-post: [email-masked]
------------------------------------------------------------------------=
----
---

> -----Ursprungligt meddelande-----
> Fr=E5n:	Robert Klerer [SMTP:[email-masked]]
> Skickat:	 den 14 maj 1998 18:34
> Till:	[email-masked]
> =C4mne:	Searching a directory for certs
>=20
> I=A0 looked through the archive and I did not find this issue, let me
> apologize if I am re-visiting a prior discussion.
>=20
> I am setting up a directory for a network provider, one of whose =
purposes
> is to be a certificate repository for several different =
organizations.=A0
> One of our requirements is to minimize the information disclosure for
> anonymous access.=A0
>=20
> For some of my services I know the DN of the other party, so a "read" =
of
> the directory (section 6 of draft-ietf-pkix-ipki2opp-07) can retrieve =
the
> certificate.=A0 But for email, I usually know the email address and =
perform
> a search (section 7 of draft-ietf-pkix-ipki2opp-07) returning the
> certificate and DN.=20
>=20
> What is stopping someone from searching for all of the email address =
in a
> organization to populate a commercial mailing list.=A0 My directory =
tool
> does not allow me to distinguish search type (exact match vs =
substring) by
> strength of bind.
>=20
> As we have the "read" by DN, do we need a "read" by email address - =
exact
> match, single returned entry?=A0=20
>=20
> =A0
>=20
> BTW:=A0 The change comments to the draft still points to tandem.com
>=20

Date: Thu, 14 May 1998 15:02:53 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Thanks!

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

 Stephen> Paul,
 >> Scenario: I build a box that implements IPsec, with IKE, with
 >> certificate based authentication.  Let's assume these are PKIX
 >> certificates as opposed to some other kind.
 >> 
 >> The box is an IP box, so the customer (i.e., the network support
 >> personnel there) understand very well how DNS names, IP addresses,
 >> and such things are administered.
 >> ...
 >> Now here's the issue: the customer has to set up access
 >> authorization to this box (i.e., the right to establish IPsec
 >> SAs).  This means creating certs for each of the end users that
 >> will be speaking IPsec to this box.  What do we tell them?  What
 >> sort of names should be used?  Who administers them?  What tools
 >> are used to do so?  What are the directories that are used (not
 >> just conceptually -- what products)?

 Stephen> The most likely choices for user certs IDs are IP addresses
 Stephen> (if they are statically assigned), DNS names (if there is a
 Stephen> one-to-one user-to-host mapping and it's static), or rfc822
 Stephen> names (for pure user identification).  All of these are ID
 Stephen> forms you administrators are familiar with, as you specified
 Stephen> the scenario, so issuance of certs based on any of these
 Stephen> name forms should be "natural."  Each of these name forms
 Stephen> can be represented in certs as AltNames, or using standard
 Stephen> or ad hoc DN-embedding conventions.  For IPsec, we are
 Stephen> defining the preferred represnetations for these Internet
 Stephen> name forms, and the current draft on this topic calls for
 Stephen> use of the AltName formats, not DNs.

I thought that AltNames made sense here, which is why I'm
puzzled/disturbed at apparent efforts to restrict the use of
AltNames.  If they are inappropriate for certain uses (which may be
the case, though that isn't yet clear to me) then the obvious answer
is to document those cases and recommend in the spec (or, maybe,
require) to avoid AltNames for those specific situations.

 Stephen> Also, for IPsec, t is not clear that one needs to go to a
 Stephen> directory to fetch certs for users or firewalls.  One can
 Stephen> exchange the certs as part of the IKE negotiation, in real
 Stephen> time.  Since you note that the users have to be autorized
 Stephen> for access, not just random public users, then the
 Stephen> distribution of certs (including CA certs) can be managed as
 Stephen> part of the enrollment process, which would also involve
 Stephen> creating ACL entries (SPD entries, to use IPsec
 Stephen> terminology).

Yes, IKE has that mechanism, but by analogy with things like RADIUS it 
may also be attractive to put the applicable certs in a central place
where the IPsec box can find them.

	paul

Date: Thu, 14 May 1998 14:29:11 -0400
To: Paul Koning <[email-masked]>, [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

Paul,

>Scenario: I build a box that implements IPsec, with IKE, with
>certificate based authentication.  Let's assume these are PKIX
>certificates as opposed to some other kind.
>
>The box is an IP box, so the customer (i.e., the network support
>personnel there) understand very well how DNS names, IP addresses, and
>such things are administered.
>
>Presumably we could (as, say, Netscape did) supply a handful of top
>level certificates along with the product to help bootstrap the cert
>hierarchy.  That might include an additional level: a top level cert
>for the customer (if he doesn't have one yet).

If the users are going to form closed communities, then I would not suggest
embeding CA certs by default, the way browsers do.  They are addressing a
different sort of user environment.

>Now here's the issue: the customer has to set up access authorization
>to this box (i.e., the right to establish IPsec SAs).  This means
>creating certs for each of the end users that will be speaking IPsec
>to this box.  What do we tell them?  What sort of names should be
>used?  Who administers them?  What tools are used to do so?  What are
>the directories that are used (not just conceptually -- what
>products)?

The most likely choices for user certs IDs are IP addresses (if they are
statically assigned), DNS names (if there is a one-to-one user-to-host
mapping and it's static), or rfc822 names (for pure user identification).
All of these are ID forms you administrators are familiar with, as you
specified the scenario, so issuance of certs based on any of these name
forms should be "natural."  Each of these name forms can be represented in
certs as AltNames, or  using standard or ad hoc DN-embedding conventions.
For IPsec, we are defining the preferred represnetations for these Internet
name forms, and the current draft on this topic calls for use of the
AltName formats, not DNs.

Also, for IPsec, t is not clear that one needs to go to a directory to
fetch certs for users or firewalls.  One can exchange the certs as part of
the IKE negotiation, in real time.  Since you note that the users have to
be autorized for access, not just random public users, then the
distribution of certs (including CA certs) can be managed as part of the
enrollment process, which would also involve creating ACL entries (SPD
entries, to use IPsec terminology).

You asked who administers the certs.  This depends on the environment, but
it often will be the same IT folks who manage the IPsec technology,
probably the firewall folks.  They can make use of IPsec as an alternative
user authentication technology, just as they maintain accounts in Radius
servers, etc.  I'd rather not comment on specific products available today,
but most IPsec firewall vendors I have seen have some form of cert issuing
capability available with their products.

Steve

From: [email-masked]
To: Stephen Kent <[email-masked]>
Date: Thu, 14 May 1998 14:17:39 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>If you don't agree on the difference between object classes defined by
>X.500 in the context of their definition of DNs, and the ITEF generating a
>standard that also defines how to represent DNS names in DNs, I don't we
>can have a useful conversation in this regard.

Maybe you could explain further the distinction you are trying to draw.
The X.500 series goes to great lengths to separate the abstract definition
of the directory (which is where DNs are defined) from the details of
particular attribute types and name-forms of the DNs that populate it.
X.501 says that the directory schema (which includes specification of the
DIT structure) is itself distributed, and that each administrative
authority establishes the part of the schema that applies to those portions
of the DIB it is responsible for.  The introduction to the X.521 spec
(which contains selected object classes and suggested name-forms) says that
"any Administrative Authority may define its own object classes or
subclasses for any purpose", although it does have a note that says that
"It is recommended that an object class defined by this document, or a
subclass derived from one, be used in preference to the generation of a new
one, whenever the semantics is approriate for the application".  Annex B of
X.521 (which contains "suggested name-forms", and is where the object
classes are arranged into name-forms and DIT structures, and where the
"/C=/O=/OU=/CN=" Organizational Person name form is defined) is marked as
being not an integral part of the standard.

RFC 2247 provides a good reason to define its own classes and name-forms -
the fact that none of the X.521 definitions are appropriate for DNS names -
and, in acordance with X.521, defines its own object classes to represent
objects named this way.  This name-form appears to be defined in full
accordance with the standard, so I really don't understand the grounds for
treating it as any less "real" than one of the X.521 "suggested
name-forms".

John

Date: Thu, 14 May 1998 13:47:00 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Having supplied some of the fuel for this discussion, I think I should 
supply a bit more to help explain just why this issue is bothering me
so much.

(Part of it comes from having sat through endless discussions in the
ATM Forum which basically amounted to "what do I tell the customers
that buy my boxes about how to get an ATM address".  The same sort of
issue comes up here.)

Scenario: I build a box that implements IPsec, with IKE, with
certificate based authentication.  Let's assume these are PKIX
certificates as opposed to some other kind.

The box is an IP box, so the customer (i.e., the network support
personnel there) understand very well how DNS names, IP addresses, and 
such things are administered.  

Presumably we could (as, say, Netscape did) supply a handful of top
level certificates along with the product to help bootstrap the cert
hierarchy.  That might include an additional level: a top level cert
for the customer (if he doesn't have one yet).

Now here's the issue: the customer has to set up access authorization
to this box (i.e., the right to establish IPsec SAs).  This means
creating certs for each of the end users that will be speaking IPsec
to this box.  What do we tell them?  What sort of names should be
used?  Who administers them?  What tools are used to do so?  What are
the directories that are used (not just conceptually -- what
products)?

	paul

Date: Thu, 14 May 1998 13:20:58 -0400
To: [email-masked], Stephen Kent <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

John,

>>>I agree, and in particular it's wrong to claim that an RFC 2247 name is
>>>somehow less "real" or more of a hack than an X.521 OrganizationalPerson
>>>name.
>>
>>Well, OrganizationalPerson is defined as a class in X.500, and DNs are
>>defined in X.500, but RFC 2247 is not X.500 and so I do think it has a
>>lesser standing, if only on that basis.
>
>OrganizationalPerson is defined within the X.500 series in a document
>titled "Selected Object Classes", not "The Most Important Object Classes",
>or "The Only Object Classes That May be Used".  The introduction to this
>document say that it contains definitions that may be useful across a range
>of applications of the directory.  The sorts of applications the writers of
>the document had in mind related to retrieving information (such a
>telephone numbers) primarily about people, not to retrieving X.509
>certificates for Internet hosts.  It shouldn't be any suprise that things
>deemed to be "useful" in the first context aren't particularly helpful in
>the second, nor should it be any suprise that names that do turn out to be
>useful in the second context weren't specified in a document addressed to
>the first.  That X.521 didn't define an object class for "InternetDNSname"
>doesn't give RFC 2247 names any lesser standing than the name forms that
>_are_ defined there.

If you don't agree on the difference between object classes defined by
X.500 in the context of their definition of DNs, and the ITEF generating a
standard that also defines how to represent DNS names in DNs, I don't we
can have a useful conversation in this regard.

Steve

From: [email-masked]
To: Stephen Kent <[email-masked]>
cc: [email-masked]
Date: Thu, 14 May 1998 13:00:37 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

>>I agree, and in particular it's wrong to claim that an RFC 2247 name is
>>somehow less "real" or more of a hack than an X.521 OrganizationalPerson
>>name.
>
>Well, OrganizationalPerson is defined as a class in X.500, and DNs are
>defined in X.500, but RFC 2247 is not X.500 and so I do think it has a
>lesser standing, if only on that basis.

OrganizationalPerson is defined within the X.500 series in a document
titled "Selected Object Classes", not "The Most Important Object Classes",
or "The Only Object Classes That May be Used".  The introduction to this
document say that it contains definitions that may be useful across a range
of applications of the directory.  The sorts of applications the writers of
the document had in mind related to retrieving information (such a
telephone numbers) primarily about people, not to retrieving X.509
certificates for Internet hosts.  It shouldn't be any suprise that things
deemed to be "useful" in the first context aren't particularly helpful in
the second, nor should it be any suprise that names that do turn out to be
useful in the second context weren't specified in a document addressed to
the first.  That X.521 didn't define an object class for "InternetDNSname"
doesn't give RFC 2247 names any lesser standing than the name forms that
_are_ defined there.

John

From: [email-masked]
To: Stephen Kent <[email-masked]>
cc: [email-masked]
Date: Thu, 14 May 1998 12:40:27 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Stephen Kent <[email-masked]>, in reply to Bob Jueneman writes:

>>In answer to John's last point, I agree that it would be possible
>>and under some circumstances desirable, to provide those alternative,
>>not rigidly bound names or other attributes by means of a directory.
>>But although I very much WANT to be able to look up certificates, CRLs,
>>etc. in a directory, I don't think that users should be COMPELLED
>>to.
>
>And I believe that users ought not be compelled to "make up" DNs when they
>have perfectly good DNS names!

Nobody's suggesting that users should make up DNs.  The suggestion is that
they (or rather the CA they register with) should follow an IETF standards
track RFC (RFC 2247) that defines a simple syntactic mapping from DNS name
"a.b.c.d" to DN "/DC=d/DC=c/DC=b/DC=a" (or "DC=a,DC=b,DC=c,DC=d" to use the
LDAP printable syntax).  RFC 2247 defines the two name forms as equivalent
- different ways of representing the same underlying abstract name, just as
the two strings "a.b.c.d" and "A.B.C.D" are merely different ways or
representing the same underlying DNS name.

John

From: "Robert Klerer" <[email-masked]>
To: <[email-masked]>
Subject: Searching a directory for certs
Date: Thu, 14 May 1998 12:34:12 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01BD7F34.994F9B40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I  looked through the archive and I did not find this issue, let me =
apologize if I am re-visiting a prior discussion.

I am setting up a directory for a network provider, one of whose =
purposes is to be a certificate repository for several different =
organizations.  One of our requirements is to minimize the information =
disclosure for anonymous access.=20

For some of my services I know the DN of the other party, so a "read" of =
the directory (section 6 of draft-ietf-pkix-ipki2opp-07) can retrieve =
the certificate.  But for email, I usually know the email address and =
perform a search (section 7 of draft-ietf-pkix-ipki2opp-07) returning =
the certificate and DN.=20

What is stopping someone from searching for all of the email address in =
a organization to populate a commercial mailing list.  My directory tool =
does not allow me to distinguish search type (exact match vs substring) =
by strength of bind.

As we have the "read" by DN, do we need a "read" by email address =96 =
exact match, single returned entry? =20

BTW:  The change comments to the draft still points to tandem.com

------=_NextPart_000_0010_01BD7F34.994F9B40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.2016.0"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>
<P><FONT size=3D3>I&nbsp; looked through the archive and I did not find =
this=20
issue, let me apologize if I am re-visiting a prior =
discussion.</FONT></P>
<P><FONT color=3D#000000><FONT size=3D3>I am setting up a directory for =
a network=20
provider, one of whose purposes is to be a certificate repository for =
several=20
different organizations.&nbsp; One of our requirements is to minimize =
the=20
information disclosure for anonymous access.</FONT></FONT><FONT=20
size=3D3></FONT>&nbsp;</P>
<P><FONT size=3D3>For some of my services I know the DN of the other =
party, so a=20
&quot;read&quot; of the directory (section 6 of =
draft-ietf-pkix-ipki2opp-07) can=20
retrieve the certificate.&nbsp; But for email, I usually know the email =
address=20
and perform a search (section 7 of draft-ietf-pkix-ipki2opp-07) =
returning the=20
certificate and DN. </FONT></P>
<P><FONT size=3D3>What is stopping someone from searching for all of the =
email=20
address in a organization to populate a commercial mailing list.&nbsp; =
My=20
directory tool does not allow me to distinguish search type (exact match =
vs=20
substring) by strength of bind.</FONT></P>
<P><FONT size=3D3>As we have the &quot;read&quot; by DN, do we need a=20
&quot;read&quot; by email address &ndash; exact match, single returned=20
entry?&nbsp; </FONT></P>
<P><FONT color=3D#000000 face=3D"" size=3D3></FONT>&nbsp;</P>
<P><FONT color=3D#000000 face=3D"" size=3D3>BTW:&nbsp; The change =
comments to the=20
draft still points to tandem.com</FONT></P></DIV></DIV></BODY></HTML>

------=_NextPart_000_0010_01BD7F34.994F9B40--

Date: Thu, 14 May 1998 10:02:20 -0400
To: Olivier Onimus <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage (again!)
Cc: [email-masked]
Sender: [email-masked]

Oliver,

>I may have missed something basic in the (very long) discussion
>you are follwing since several days, but IMO, the "semantics" of
>Alternate name in comparison with "Name" (e.g. for subject)
>is already (well) defined in X.509:
>
>"subject" and "Issuer" in Certificat are of type "Name". Name is defined in
>X.501 as =84SEQUENCE OF RelativeDistinguishedName".  This means that only R=
DNs
>(of a real or a virtual existing DIT) should be present at this level.
>
>In X.509, Chapter. 12.3.1 about the Extensions, it is said:
>
>
>    The following requirements relate to certificate subject and
>    certificate issuer attributes:
>	a) Certificates need to be usable by applications
>           that employ a variety of name forms, including
>           Internet electronic mail names, Internet domain names,
>           X.400 originator/recipient addresses, and EDI party names.
>           It is therefore necessary to be able to securely associate
>           multiple names of a variety of name forms with a certificate
>           subject or a certificate or CRL issuer.
>	b) A certificate user may need to securely know certain
>           identifying information about a subject in order to have
>           confidence that the subject is indeed the person or thing
>           intended. For example, information such as postal address,
>           position in a corporation, or a picture image may be required.
>           Such information may be conveniently represented as directory
>attributes,
>           but these attributes are not necessarily part of the
>distinguished name.
>           A certificate field is therefore needed for conveying additional
>           directory attributes beyond those in the distinguished name.
>
>
>
>What I do understand is, that the attributes of the =84Issuer" or =84Subjec=
t",
>which can not be coded in the fields =84issuer" or =84subject", because=
 they are
>not part of a RDN, can be coded as certificate-extension. That's all.

You may be missing the historical context in which this WG asserted, for
over a year, that DNs were optional for issuers and subjects, IF AltNames
were used.

>With the informations contained in "Issuer", I can identify (as software) a
>tree (DIT)
>in which I can identify in a UNIQUE way (as software) an entry using the
>information contained in "Subject". The extra information contained in the
>extension "AltName" may
>be used for me (as user) to identify the subject or the issuer of the
>certificate in another way. The informations are (as David P. Kemp said)
>"only extra identification information".

This is not the interpretation we have historically applied in this WG.

>Another remark before I finish: I don't want to defend here the x.509-world=
=2E
>I know, PKIX will profile the X.509 world in such a way the whole stuff wor=
ks
>and the designers and the implementors can easily understand what is meant.=
 I
>just thought that this discussion about "Alternate name semantics and usage=
"
>could take something from what is specified in X.509.....

We are aware of the original text, and we had chosen to adopt a different
approach. This was based on the fact that the text assumes an X.500
environment, which is NOT representative of the Internet

Date: Thu, 14 May 1998 10:02:20 -0400
To: Olivier Onimus <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage (again!)
Cc: [email-masked]
Sender: [email-masked]

Oliver,

>I may have missed something basic in the (very long) discussion
>you are follwing since several days, but IMO, the "semantics" of
>Alternate name in comparison with "Name" (e.g. for subject)
>is already (well) defined in X.509:
>
>"subject" and "Issuer" in Certificat are of type "Name". Name is defined in
>X.501 as =84SEQUENCE OF RelativeDistinguishedName".  This means that only R=
DNs
>(of a real or a virtual existing DIT) should be present at this level.
>
>In X.509, Chapter. 12.3.1 about the Extensions, it is said:
>
>
>    The following requirements relate to certificate subject and
>    certificate issuer attributes:
>	a) Certificates need to be usable by applications
>           that employ a variety of name forms, including
>           Internet electronic mail names, Internet domain names,
>           X.400 originator/recipient addresses, and EDI party names.
>           It is therefore necessary to be able to securely associate
>           multiple names of a variety of name forms with a certificate
>           subject or a certificate or CRL issuer.
>	b) A certificate user may need to securely know certain
>           identifying information about a subject in order to have
>           confidence that the subject is indeed the person or thing
>           intended. For example, information such as postal address,
>           position in a corporation, or a picture image may be required.
>           Such information may be conveniently represented as directory
>attributes,
>           but these attributes are not necessarily part of the
>distinguished name.
>           A certificate field is therefore needed for conveying additional
>           directory attributes beyond those in the distinguished name.
>
>
>
>What I do understand is, that the attributes of the =84Issuer" or =84Subjec=
t",
>which can not be coded in the fields =84issuer" or =84subject", because=
 they are
>not part of a RDN, can be coded as certificate-extension. That's all.

You may be missing the historical context in which this WG asserted, for
over a year, that DNs were optional for issuers and subjects, IF AltNames
were used.

>With the informations contained in "Issuer", I can identify (as software) a
>tree (DIT)
>in which I can identify in a UNIQUE way (as software) an entry using the
>information contained in "Subject". The extra information contained in the
>extension "AltName" may
>be used for me (as user) to identify the subject or the issuer of the
>certificate in another way. The informations are (as David P. Kemp said)
>"only extra identification information".

This is not the interpretation we have historically applied in this WG.

>Another remark before I finish: I don't want to defend here the x.509-world=
=2E
>I know, PKIX will profile the X.509 world in such a way the whole stuff wor=
ks
>and the designers and the implementors can easily understand what is meant.=
 I
>just thought that this discussion about "Alternate name semantics and usage=
"
>could take something from what is specified in X.509.....

We are aware of the original text, and we had chosen to adopt a different
approach. This was based on the fact that the text assumes an X.500
environment, which is NOT representative of the Internet, it's use of other
names forms and it's deployment of the DNS anw web servers as alternative
repositories for certs, CRLs, etc.

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: Bob Jueneman <[email-masked]>, [email-masked]
Sender: [email-masked]

John,

>>Peter said that one of the primary uses of alternate names
>>was to accommodate those name forms that can't be a DN,
>>e.g., almost everything useful.  I have to strongly disagree with
>>that notion, which I thought we had overthrown back in the
>>PEM days.
>>
>>To the best of my knowledge, the ITU does not act as any kind of
>>a schema registration "authority" for X.500 or anything else.
>>Nor, even less, do they act as a name registration authority for
>>names that are defined within any particular schema.
>>
>>So although it might be too strong to say that such a view
>>is ludicrous, I firmly believe that it would be wrong.
>>
>>I may be somewhat notorious for my "MPEG of my cat" view
>>of what a DN can contain, but to the best of my knowledge,
>>anyone who wanted to create an OID and a syntax description
>>for such an attribute would be PURRFECTLY within their rights
>>to include it within their certificate DN. So there is absolutely
>>no reason at all why an RFC822 name, DNS name, or anything else
>>that is at all reasonable could not be contained in a DN.  In
>>particular, neither PKIX, nor X.500, in fact, has to be constrained
>>by the oxymoronic "useful attributes" defined in X.520.
>
>I agree, and in particular it's wrong to claim that an RFC 2247 name is
>somehow less "real" or more of a hack than an X.521 OrganizationalPerson
>name.

Well, OrganizationalPerson is defined as a class in X.500, and DNs are
defined in X.500, but RFC 2247 is not X.500 and so I do think it has a
lesser standing, if only on that basis.

>>And to respond to John's comment, PKIX could in fact totally
>>ignore issues of what kinds of attributes are allowed for a DN
>>in a certificate, and PKIX would still work. Chains could be searched,
>>name constraints applied (assuming the basic comparison syntax is
>>supplied), etc.
>>
>>The only thing that won't work is _interoperability_, especially with
>>various kinds of directories.  Directories, especially most X.500
>>directories, are NOT general purpose relational search engines.
>
>My position is that a relying party shouldn't itself impose schema
>constraints on the names that it is willing to accept.  If it is using a
>directory to retrieve certificates, then that directory may well impose
>restrictions of its own, and that is a good reason for CAs to be careful
>about the sorts of names they issue certificates for, but, assuming that an
>end-system can obtain a certificate, it shouldn't refuse to use that
>certificate in a chain simply because the name contains an attribute that
>the end-system doesn't recognize.

A relying party has to understand the names it accepts, so it is not
unreasonable for it to impose syntactic constraints on such names as a side
effect of facilitating manageable implementations.  For the various
Internet anme forms, we understand the syntax and softwarecan easily
accommodate it. For arbitrary DNs, with unusual "(what the heck, I got an
OID for it") attributes, this is an unreasonable assumtion.

>>Most X.500 and similar directories I know of can find almost
>>anything very quickly, but ONLY if the search arguments have
>>been predefined as some kind of a filter. So given a name, you
>>can look up anything that is filed under that name, including say
>>street address, telephone number, e-mail address, certificates, and
>>the obligatory cat picture.
>>
>>Likewise, if you PREDEFINE the appropriate filters, you can look up
>>what is effectively an alias that doesn't have to be created specifically,
>of
>>say my telephone number, and get back a pointer to my name and all
>>the rest.
>>
>>But unless you have predefined it, you cannot enter a picture of my cat,
>>or even my e-mail address, and find anything else, unless you are
>>prepared to search the ENTIRE database for a match.
>>
>>Therefore, the CAs and the director service providers are going to
>>HAVE to play a strong role in defining what kind of names (schemas)
>>are acceptable if we want directories to work at all. Since PKIX is active
>>in this field, I would hope they would take the initiative, otherwise, I
>would
>>expect that the CAs would get together and decide for themselves --
>>after all, they have to sign the certificate containing the DN, and
>>presumably they take some degree of responsibility for the contents.
>
>I think this is an important thing to do, however, I don't think we need to
>hold up PKIX-1 for it.  PKIX-1 should explicitly allow names constructed
>using arbitrary attribute types.

We agree here.  Such schema definition is outside the scope of PKIX.

>>So my view is that the DN should contain names that are agreed within
>>the community to fall within an acceptable schema, AND ARE
>>SEARCHABLE WITHIN  A DIRECTORY. Otherwise, I would argue,
>>there is no reason to have a DN at all.
>
>Not all certificates necessarily need to be obtained from a directory,
>though.  An application protocol is entitled to provide some portion of the
>certificate chain needed to establish trust in the final key, so if a
>certificate is always used in the context of such a protocol, the fact that
>it might contain names using unusual schema ought not to matter, provided
>that the relying party can correctly verify that the subject of one cert
>"matches" the issuer of the next. Of course, with an unknown attribute,
>matching is a little tricky, but there is text pending for inclusion in
>PKIX-1 that specifies binary matching for all string syntaxes other than
>printableString, and while I'm not sure of the wisdom of doing this when an
>end-system knows how to apply X.520 matching rules, I think it's a
>perfectly acceptable fallback position for a relying party to take for
>attributes it doesn't recognise.

Precisely because not all certs need to be retrieved from an LDAP or X.500
directory, it is inappropriate to mandate DNs for all issuers of PKIX
compliant certs.

[remainde of message deleted because it just rehashes previous material
which I never liked in the first case ... :-)]

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: "David P. Kemp" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

David,

>> Apologies if I'm asking something that should be obvious from reading
>> the specs, but this long discussion makes me wonder.
>>
>> In much of the world we live in, it's well understood how to get
>> (a) an IP address, (b) a DNS name.
>>
>> On the other hand, X.500 style names (i.e., strings of the form "C=US,
>> ORG=bar, FOO=xxx...") are, most of the time, going to be received with
>> "what the heck is *that*?".  That's not a problem if we can simply
>> write some documentation to make it clear.
>
>Is it clear that an X.500 style name of the form "E=[email-masked]"
>means what one would expect it to mean?  The emailAddress DN attribute
>(1.2.840.113549.1.9.1, commonly abbreviated as "E") is already used
>in many certs.  Unfortunately, many CAs generally include it in
>a meaningless mishmash of a DN
>("C=US, ORG=Bar, CN=Fred Jones, E=[email-masked]") in which the fourth RDN
>has no subordinate relationship to the third; this misuse is what
>prompted the ITU to define GeneralName in the first place.
>But IMHO the proper response to DN abuse is not to create a whole new
>syntax, but to define a schema which would demonstrate the proper use
>of the existing DN syntax.

Yes, that's a very reaonsonable interpretation of such a DN.  But what
purpose is served by such a construct?  Most of the folks who are pushing
for DNs want to use them for LDAP or X.500 lookups.  This DN would be much
easier to lookup in the DNS than in any X.500 directory I know.

>
>> Does it amount to re-encoding the DNS name into a different syntax?
>
>Yes.
>
>> That works (except for the pain of explaining why a different syntax
>> that doesn' have any different semantics is useful).
>
>If one is prepared to require that all certs with DNS subjects are
>End Entity certs, then there is no difference in semantics and no reason
>to have a multi-RDN syntax for DNS names.

I am arguing for DNS names in issuer certs, not just end entities.

>However, DNS doesn't work that way.  It's a heirarchy, with registration
>delegated to administrators at lower levels.  If you want the CA topology
>to mirror the DNS administrative topology, then you want the CA for
>"DC=net, DC=vaultline" to be able to issue a CA cert for
>"DC=net, DC=vaultline, DC=santaclara" and have the normal name
>constraint process work as expected.  The ITU has not defined any
>processing rules to go along with GeneralName, so the semantics of the
>multi-RDN form *is* different than the undefined semantics of a single
>subjectAltName string of "dNSName=santaclara.vaultline.net".
>

We agree on this point.

>> Or does it
>> requiring going to a different authority and getting an additional
>> name in a different naming hierarchy?
>
>No!

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: Bob Jueneman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Bob,

>No apologies are necessary.  The questions you are asking are in fact
>recorded very precisely in the original X.DOT specifications. Unfortunately
>the specs are copyrighted and can only be referenced by visting the archives
>on the planet Vogon in person, after payment of 1000 International Standard
>Units of platinum, ISO 4217 alpha currency code XPT, numeric
>funds code 962. Unfortunately ISO 4217 does not specify what the
>standard units ARE, but only their names, so it might be grams, troy
>ounces, or mean solar mass equivalent.  Probably it is the latter,
>so bring your American Express card.
>>
>>In much of the world we live in, it's well understood how to get
>>(a) an IP address, (b) a DNS name.
>
>Actually, in MOST of the world we live in, it is far from obvious how one
>goes about getting an IP address, or even an DNS name.  Take a poll
>of 1000 AOL newbies, and ask them whether they fully understand the
>intricacies of DHCP, for example. I certainly don't pretend to.  Likewise
>a DNS name, if I'm behind a firewall on a corporate network.

The question is not whether folks who are unaware of Internet name spaces
know how to get such names.  You're needlessly confusing the issue.

>>On the other hand, X.500 style names (i.e., strings of the form "C=US,
>>ORG=bar, FOO=xxx...") are, most of the time, going to be received with
>>"what the heck is *that*?".  That's not a problem if we can simply
>>write some documentation to make it clear.

Clear, yes. Authoritative, unambiguous, and unique, no.

>On the other hand, I would suggest that most people _would_ understand
>a question such as "what country do you live in, i.e., what is your primary
>residence?" (We won't get into residence vs. domiciles).
>
>And most people would be able to answer the question, "What is the
>name of the organization you work for or are associated with?"
>
>Depending on the frequency of organization updates, answering a question
>about organizational units might be a bit more difficult, I suppose.
>
>Now the trickiest of all might be "What is your name?"  But that is
>because standards organizations, unfortunately including PKIX , worry
>excessively about the obscure minutia, and never get around to specifying
>whether the form is last name first, first name last, or what a surname is.
>I suppose it is due to early toilet training, or something -- anal retentive,
>I think it's called.

Bob, how can you, of all people, say this.  You have been the primary
progenitor of minutae in these discussions for almost a decade!

>Hopefully, the public CAs will enforce some discipline on this process,
>and if they don't, some very small number of dominant vendors will
>do so (unless the Justice Department gets into the act). At least I hope so.
>
>Notice that nowhere in this process did I ever use such X.400 business
>card jargon as c=US,O=foo, cn=Bar.  And anyone's GUI that does
>use such junk ought to be banned, at least if it is intended for the
>casual user.
>
>(If, however, it is the network administrator, or the directory administrator,
>or other reasonably skilled person who is filling out these screens, then
>a certain latitude can perhaps be tolerated.  Just like doctors and lawyers,
>system administrators have to use a specialized language to communicate
>with their brethren, or anybody might be able to do this stuff! :-)
>>
>>However, what *is* critical is that there has to be a well defined,
>>easily executed, and effective way for people to obtain the names they
>>need.  It isn't clear to me yet from the discussion whether this is
>>the case, or if so, what the process is.
>
>People don't OBTAIN names, they HAVE names, or they are given them,
>typically by their parents. People who work for organizations and choose
>(or are told) to use that organizational person class (excuse the jargon)
>inherit those names. People who chose to be identified by their residential
>addresses look on their mailbox. People who only want to be identified by
>obscure 8 character e-mail names have to ask their system administrator
>what they should use, to make sure it doesn't give away corporate secrets.

The names people HAVE and not DNs!  They are DNS names, RFC822 names, IP
addresses, URLs, account numbers with varioiusorganizations, etc.  None of
these is a natural DN.  Also, we all have lots of names and no single DN
will suffice to meaningfully identify us in all the contexts in which we
communicate.

[rest of text snipped because I can't stand it anymore ...]

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: Bob Jueneman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Bob,

>This has been a very illuminating discussion.
>
>First off, I suppose I should apologize for using the term "ludicrous."
>I did not mean to deprecate anyone's opinion that differed from
>mine. But there are apparently some rather divergent views.
>
>Peter said that one of the primary uses of alternate names
>was to accommodate those name forms that can't be a DN,
>e.g., almost everything useful.  I have to strongly disagree with
>that notion, which I thought we had overthrown back in the
>PEM days.

As the PEM WG chair, that's not my recollection of the outcome ofn our
discussions 'way back then.

>To the best of my knowledge, the ITU does not act as any kind of
>a schema registration "authority" for X.500 or anything else.
>Nor, even less, do they act as a name registration authority for
>names that are defined within any particular schema.
>
>So although it might be too strong to say that such a view
>is ludicrous, I firmly believe that it would be wrong.

That's not my point Bob, as I mentioned in a previous message.

>I may be somewhat notorious for my "MPEG of my cat" view
>of what a DN can contain, but to the best of my knowledge,
>anyone who wanted to create an OID and a syntax description
>for such an attribute would be PURRFECTLY within their rights
>to include it within their certificate DN. So there is absolutely
>no reason at all why an RFC822 name, DNS name, or anything else
>that is at all reasonable could not be contained in a DN.  In
>particular, neither PKIX, nor X.500, in fact, has to be constrained
>by the oxymoronic "useful attributes" defined in X.520.

You could do it, and it would be as inappropriate as a DN now as it was
when you first suggested it.

>And to respond to John's comment, PKIX could in fact totally
>ignore issues of what kinds of attributes are allowed for a DN
>in a certificate, and PKIX would still work. Chains could be searched,
>name constraints applied (assuming the basic comparison syntax is
>supplied), etc.
>
>The only thing that won't work is _interoperability_, especially with
>various kinds of directories.  Directories, especially most X.500
>directories, are NOT general purpose relational search engines.

No, they are not, and they also are not the only game in town.

>Most X.500 and similar directories I know of can find almost
>anything very quickly, but ONLY if the search arguments have
>been predefined as some kind of a filter. So given a name, you
>can look up anything that is filed under that name, including say
>street address, telephone number, e-mail address, certificates, and
>the obligatory cat picture.
>
>Likewise, if you PREDEFINE the appropriate filters, you can look up
>what is effectively an alias that doesn't have to be created specifically, of
>say my telephone number, and get back a pointer to my name and all
>the rest.
>
>But unless you have predefined it, you cannot enter a picture of my cat,
>or even my e-mail address, and find anything else, unless you are
>prepared to search the ENTIRE database for a match.
>
>Therefore, the CAs and the director service providers are going to
>HAVE to play a strong role in defining what kind of names (schemas)
>are acceptable if we want directories to work at all. Since PKIX is active
>in this field, I would hope they would take the initiative, otherwise, I
>would
>expect that the CAs would get together and decide for themselves --
>after all, they have to sign the certificate containing the DN, and
>presumably they take some degree of responsibility for the contents.
>
>So my view is that the DN should contain names that are agreed within
>the community to fall within an acceptable schema, AND ARE
>SEARCHABLE WITHIN  A DIRECTORY. Otherwise, I would argue,
>there is no reason to have a DN at all.

I, for one, am not willing to defer to the whims of directiry service
providers.  This model strikes me as outdated, especially given the lack of
substantive directory services being offered in the X.500 domain.

>At the admitted risk of overloading the semantic content of the
>DN, I would also propose that the DN comport more or less well with
>the more or less "official" name of the subject, i.e., the name that is
>legally
>recognized as being associated with that entity.  That doesn't necessarily
>rule out the use of an e-mail address in the appropriate contexts, but it
>probably does rule out my cat.  (We sometimes have a disagreement on
>this issue, but I claim that I own the cat, not vice versa. Not to get into
>SPKI semantics, but my name is a legitimate qualifier for the cat, not
>the other way around, at least until he can open his own cans of cat food.)

This is where value judgements become critical, since there is no arbiter
for DNs, and CAs ought not have to make such judgements.  It only provides
business for lawyers!

>So what purpose is or should be served by alternate names?
>
>Well, in my view, at least, they are representations made by the subscriber
>to the CA, and hence to relying parties, and as such may have certain legal
>consequences. So even if the CA does not have the resources to do a full
>due diligence investigation of their veracity, that doesn't mean that a
>subscriber is entitled to make any representations he wishes in this regard.

On this later point we agree, but I think of AltNames as primary,
verifiable IDs in the cases in question, not ancilliary IDs.

>Ideally, anything contained in an alternate name should carry an explicit
>Nonverified Subscriber Information flag, in order to make this much clearer.
>But failing that, the CA at least ought to spell out in their CPS whether or
>not they independently verify the subscriber's right-to-use and perhaps global
>unambiguity of those attributes.

Bob, we don't have such a flag, despite your urging for several years.
Perhaps the reason is because it's just a bad idea to put such info into a
cert!

[snip material having to do with foreign names and characters sets]

>In answer to John's last point, I agree that it would be possible
>and under some circumstances desirable, to provide those alternative,
>not rigidly bound names or other attributes by means of a directory.
>But although I very much WANT to be able to look up certificates, CRLs,
>etc. in a directory, I don't think that users should be COMPELLED
>to.

And I believe that users ought not be compelled to "make up" DNs when they
have perfectly good DNS names!

>If this gets to be too much of an impasse, we could always define the
>syntax for an alternate subject (or issuer) name to be a compound attribute,
>and define on a per attribute or even per name basis a Nonverified
>Subscriber Information bit.

Nice try Bob, but we're still not buying into NVI!

>So I would modify David's taxonomy to include a fourth option, which
>would be my preference:
>
>" iv) They are alternative names which are a representation
>made by the subscriber to the CA and/or any relying party
>which may have legal consequences, but which may or
>may not have been independently verified by the CA. They
>may be used by end-systems for display to the user in
>security-related contexts, and may also be used for such
>secondary purposes as automatic e-mail or http address
>confirmation. They are not used in chain-building, certificate
>retrieval, certificate verification, or constraint processing."
>

I vote a strong "NO" for this one.

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: "David P. Kemp" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

David,

>> Alternative Names
>>
>> The subject and issuer alternative names are used to specify all the things
>> which can't be given in a DN, which for most purposes means practically
>> everything of any use on the Internet.
>
>Can't is such a strong word.  "Sometimes aren't given in a DN" is more
>accurate, since rfc822 names are often (incorrectly) included in
>mixed-namespace DNs.  In your experience, what percentage of the certs
>which contain rfc822 names encode them in an AltName extension?

I'll answer for Peter, and say 0%.  But that's understandable since people
were issuing version 1 certs and didn't have a good place to put the rfc822
names.  But, now that we have an AltName syntax for 822 names, we should
use it.

>> This would require an amendment to X.509v3 though, I'm not sure how likely
>> that is to happen.  As it currently stands, the altName semantics are too
>> ambiguous to make it possible to rely on altNames for much.

[snip]

>
>A different solution which does not require an amendment to X.509:
>
> * AltName extensions are never used in path development, only the
>   subject and issuer fields are used.  The AltName extensions are
>   used only for extra identification information, verified or not
>   as described in the CA's CPS.
>
> * subjects which have one true, certified name would have that name
>   encoded as a DN.  RDN attributes already exist for emailAddress and
>   DNS name component.  Additional attributes could be defined to hold
>   the string form of a full DNS name, URI, EDIPartyName, etc.
>   (An alternative, which I don't like but which should be mentioned
>   anyway for completeness, is to define a single attribute with syntax
>   GeneralName which could hold any nameform.)
>
> * subjects which have more than one certified subject name should have
>   more than one certificate.  (I'd argue that those certs should have
>   different public keys, but that's a different thread :-).

Yes, one could do this, but it would be wrong :-)!  This proposal is
essentially a throwback to v1 cert names, plus the notion of non-verified
info (AltNames) in certs, which is a abbrogation of CA responsibility.

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: Bob Jueneman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

Bob,

>My point was that in my view, at least, the primary purpose for alternate
>subject anmes (and even alternate issuer names) was to convey additional
>optional information to the relying party.

Yes, that's an appropriate X.500-centric view, but this is the Internet.
We don't need no stinkin' DNs :-).

>If we start using them to convey all sorts of mandatory contraints, impose
>a requirement to be able to search for them in a directory, etc.,  then I
>think we have started down a different kind of semantics entirely.

We have a global repository in which they fit quite nicely, i.e., the DNS.

>I mentioned something along these lines to Hoyt Kesterson a while ago, and
>I believe he told me that X.500 '97 provides the ability have multiple
>DNs, presumably for the same object.  I clearly don't undertand what the
>difference is between a DN and an alias to a ND in a directory, but having
>multiple DNs is a certificate, quite independent of the altSubjectName
>_semantics_ would be worth exploring, I think.

Good question for someone else.

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: "David P. Kemp" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

David,

>> From: [email-masked]
>>
>> I agree that things are very much simpler if we can
>> prescribe the use of DNs in all certificates, and I'd
>> be quite happy with that restriction.  However, I don't
>> see why PKIX needs to say anything about schema.  PKIX
>> systems ought to be able to handle any X.500 name,
>> regardless of whether that name follows an X.520/X.521
>> schema, or whether it uses some private schema.
>
>John,
>  I agree almost completely.  The exception: PKIX should say something
>about schema: it may reasonably define mandatory and optional schema to
>promote interoperablity.  But PKIX and X.509 should not prohibit the
>use of other (private or agreed-to-elsewhere) schema.
>
>Bob says:
>
>>    The question of who "owns" or registers name in the DN space is not
>>    only ludicrous, but moot.  CAs are going to define them, and
>>    directory service providers are going to decide whether or not that
>>    schema is acceptable for their directory, and everything else will
>>    spill on the floor.
>
>The question isn't ludicrous, but "own" may have been a poor choice
>of words.  Is there any question that Naming Authorities (such as
>the IETF) exist, and that rfc822 names and DNS names are assigned
>in accordance with a reasonably well defined registration procedure?

We agree. See also my comments to Bob.

>The question of ownership only came up as a result of the assertion
>that the ITU owns the DN structure and that names registered by
>non-ITU NAs such as the IETF could/should not appear in a DN.  I
>wouldn't call this assertion "ludicrous", but I do disagree with it.

I don't think I have said this.  What I meant was that the ITU or its
designates would be the nominal arbiters of DNs, and that we have no such
arbiters.  That is a problem, irrespective of use of the term "owns."

>Schemas will be defined by PKIX and privately, and as you say, CAs,
>application developers, and directory providers will decide which schemas
>to support.  Schemas for representing rfc822 and DNS names as RDN
>attributes should live or die based on their utility, not be automatically
>rejected because "the ITU owns the DN space" and defines an AltName
>extension to hold those other names.
>
Schema definition is a directory issue, not a PKIX issue, though I admit
the common interest.  We defined an LDAP schema for management objects only
when requested by the IESG, as we were developing new objects.  For DNs,
this is not the case and I believe it is outside of our charter.
>
>
>> So, we have at least three different possible sets of
>> semantics for the AltName fields:
>>
>> i)  They are "official" names, and should be used to
>> link certificates together in chain-building (perhaps
>> only if there aren't DNs in ther certificates).  The
>> current PKIX-1 draft is consistent with this
>> interpretation, but doesn't define how the linkage is
>> to be performed.
>>
>> ii) They are nicknames, chosen by the end-system and
>> unverified by the CA.  They are therefore not to be
>> believed by end systems, and should not be displayed
>> to the user in any security-related context.  They are
>> not used in chain-building.
>>
>> iii) They are approved alternative names, verified by
>> the CA, and may be used by end-systems for display to
>> the user in security-related contexts.  They are not
>> used in chain-building.
>>
>> We need to decide what these names mean, and what an
>> end-system is required/permitted to do with them
>> before we can include them in the PKIX profile.
>
>
>My vote is for ii) or iii): AltName extensions are prohibited in chain
>building.  Verifying (and the strength of verification) is a matter to
>be described in the CPS.  Displaying is a UI issue - don't go there.

I vote for i!

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

John,

>
>So, we have at least three different possible sets of
>semantics for the AltName fields:
>
>i)  They are "official" names, and should be used to
>link certificates together in chain-building (perhaps
>only if there aren't DNs in ther certificates).  The
>current PKIX-1 draft is consistent with this
>interpretation, but doesn't define how the linkage is
>to be performed.

This is my position and I agree that Part 1 needs to do a better job to
address the processing of AltName-only certs.

>ii) They are nicknames, chosen by the end-system and
>unverified by the CA.  They are therefore not to be
>believed by end systems, and should not be displayed
>to the user in any security-related context.  They are
>not used in chain-building.

And if one does this, I question the appropriateness of putting them in a
cert, just as you do.

>iii) They are approved alternative names, verified by
>the CA, and may be used by end-systems for display to
>the user in security-related contexts.  They are not
>used in chain-building.

One might do this, but for the Internet context I believe this is an
inppropriate interpretation for DNS names, RFC822 Names, IP addresses and
URLs.

>We need to decide what these names mean, and what an
>end-system is required/permitted to do with them
>before we can include them in the PKIX profile.

Agreed.

Steve

Date: Thu, 14 May 1998 10:02:20 -0400
To: Bob Jueneman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

Bob,

>My very strong preference is to mandate the use of DNs in certificates,
>both for end-entities and especially for CAs.  And the schema for these
>DNs ought to be drawn from a rather limited set of the allegedly "useful
>attributes" defined in X.520, unless or until PKIX gets around (after five
>years and counting) to defining an acceptable schema.

You and John Wray both advocate DNs for issuers, but your motivations and
his don't  match.  I'm very much opposed to imposing constraints on DNs for
PKIX compliance, because I see too many opportunities to create useful,
closed PKIs where the form of the Dn should be dictated solely by the CA.
In open PKIs, DNs conforming to a well-defined schema would be good, if
only we had X.500 (instead of LDAP) to work with, and if someone were
authoritative for the DNs.  Absent these facilities, I cannot endorse
mandating DN use of issuers, especially in cases where the names are really
drawn from other spaces where we have well-defined AltName extensions.

>Given such a restriction, I can at least be guaranteed a way of finding
>and/or revoking a certificate, although adding the hash of the public key
>would be better yet.

No you can't, given the state of directories.

>I really can't take seriously any proposal to apply name subordination
>constraints, etc., on subjectAltNames when the intent was to be rather
>loose about what those names were intended to contain.

We disagree.  The IETF is the cognizant body for deciding how to employ
DNS, RFC822, and IP address AltNames.  Until very recently, the PKIX Part 1
spec was explicit about NOT requiring use of issuer or subject DNs.  I'd
like to maintain that feature.

>The question of who "owns" or registers name in the DN space is not only
>ludicrous, but moot.  CAs are going to define them, and directory service
>providers are going to decide whether or not that schema is acceptable for
>their directory, and everything else will spill on the floor.

Again we disagree, and I'm a CA.  (Well, I'm the CTO for a major CA; close
enough!)  This approach has gotten us terrible bastardizations of DNs in
many certs now, but we have an opportunity to avoid that in the future.

>The thread that John was discussing may or may not have been the one on
>cert-talk where I was discussing what to do about multilingual countries,
>but there is clearly a need to define at least "roughly equivalent" names
>that are either official or unofficial translations or transliterations of
>the presumably "official" primary DN.

Nope, wrong thread.  Following text related to it deleted ...

>It has even been suggested that we should take advantage of the "other
>name" form, and allow a JPEG logo to be included in subjectAltName, and
>presumably issuerAltName as well. I think that is a very reasonable
>suggestion, as the logo is more likely to be recognized internationally
>than the name, whether translated or not. but obviously I don't expect to
>do a name search against a logo, much less a name subordination constraint.

I too am in favor of including a JPEG logo for registered trademarks, for a
similar reason.  The goal of a cert is to identify the holder of the
corresponding private key, in a fashion meaningful to relying parties.  The
problem we face with DNs is a lack of authoritative sources, which forces a
CA to make a value judgement about whether the assertede DN is appropriate,
given some set of supporting documentation.  In contrast, we have the
requisite, authoritative sources for DNS names, etc. and we ought to make
use of them.  However, since a user may guess a DNS name for a well-known
organization and find that the target is not the one he/she expected, I'm
in favor of including a logo as a means of minimizing confusion.  it would
be nice, though, of we could keep the size down.

>Although it is (normally) perfectly feasible for a directory provider to
>map the alternate names to directory aliases, this isn't a universal
>requirement. the relying party can either do it or not, as he sees fit.

I don't care.  I'm more interested in the innate accuracy of the AltName
construct than it's use as an alias.= in and X.500 directory.

>So my bottom line is that the alternate names should be primarily intended
>for use as a human-readable confirmation of the subscriber's identity, but
>not necessarily for use as a means of searching for that name.

And I say that AltNames should be the primary ID form when the identity is
drawn from a space for which we have an AltName extension and for which
there is an authoritative arbiter of the name space.

>If someone requires that an RFC822 name or a DNS name be included, I would
>think that in most cases it would suffice to include it in the alternate
>name form, and comparisons at the application level can be done against
>that name. If it is absolutely essential to include such a construct in
>the DN, we ought to define an attribute and assign it a suitable OID.  I
>would hate to see the semantics of commonName being debased more and more,
>just because implementors (or standards groups) are too lazy to define
>something more precisely.

This comment suppirts neither my position nor John's, so I'll pass on it.

Steve

Date: Tue, 12 May 1998 18:31:30 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

>>" iv) They are alternative names which are a representation
>>made by the subscriber to the CA and/or any relying party
>>which may have legal consequences, but which may or
>>may not have been independently verified by the CA. They
>>may be used by end-systems for display to the user in
>>security-related contexts, and may also be used for such
>>secondary purposes as automatic e-mail or http address
>>confirmation. They are not used in chain-building, certificate
>>retrieval, certificate verification, or constraint processing."
>
>I'm perfectly happy with that interpretation, although I'd prefer to =
extend
>"They may be used by end-systems for display to the user in
>security-related contexts" to something like "They may be used by
>end-systems for display to the user in security-related contexts, but =
that
>such display should be accompanied by a disclaimer that the authenticity =
of
>such names may not have been verified by the CA, and that the CA's CPS
>should be consulted before placing the same level of trust in an altName =
as
>in a DN".  This interpretation would be a change from the behavior
>specified in the current draft of PKIX-1, which uses altName fields for
>chain-building.
>
>John
>
I'd be comfortable with that interpretation, although I would prefer to
see a Nonverified Subscriber Information flag be made explicit. Having to
read a very lengthy CPS is bad enough, but having to read various
amendments and keep up with them because the CA says that they
are binding is much, much worse.

Bob

Date: Tue, 12 May 1998 11:29:08 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: [email-masked]
CC: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Hi Denis,
    I thought the KeyIdentifier WAS the hash of the public key. On
re-reading Part 1, I see that it is the hash of the public key if
one is not present in the issuer's certificate. If it is present,
it could be the integer 1 for all anyone knows.

So you are right - this spec needs to spell out exactly what is in
that field:

The hash shall be calculated over the value (excluding tag and length)
of the BIT STRING subjectPublicKey in the issuer's certificate.

Would that work?

Regards,
Ambarish

Denis Pinkas wrote:
> 
> Ambarish,
> 
> I see two problems with your proposal.
> 
> > Hi All,
> >     Given the amount of debate on this topic, I am proposing the
> > following structure to identify a certificate in OCSP:
> >
> > CertID ::= SEQUENCE {
> >    issuerNameAndKey     IssuerNameAndKey,
> >    serialNumber         CertificateSerialNumber }
> >
> > IssuerNameAndKey ::= SEQUENCE {
> >    issuer                       Name,
> >    issuerAltName        [0]     EXPLICIT IssuerAltName OPTIONAL,
> >    keyIdentifier                KeyIdentifier }
> 
> This is a structure that is different from the "option 3". Why ?
> 
> The proposed structure would be roughly equivalent if the KeyIdentifier
> were a hash of the public key of the CA. Since a keyIdentifier is only a
> bit string, it will NOT prevent collisions.
> 
> Why don't you take the "option 3 " ?
> 
> Denis
> 
> > Will this address everyone's concerns?
> > If you want to just use the Issuer's key as the method of figuring
> > out the issuer, you can do that. If you want to use the Name and/or
> > the AltName, that will also work.
> >
> > Comments?
> >
> > Ambarish
> >
> > --
> > 
-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Tue, 12 May 1998 18:53:36 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Ambarish Malpani <[email-masked]>
CC: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Ambarish,

I see two problems with your proposal.

> Hi All,
>     Given the amount of debate on this topic, I am proposing the
> following structure to identify a certificate in OCSP:
> 
> CertID ::= SEQUENCE {
>    issuerNameAndKey     IssuerNameAndKey,
>    serialNumber         CertificateSerialNumber }
> 
> IssuerNameAndKey ::= SEQUENCE {
>    issuer                       Name,
>    issuerAltName        [0]     EXPLICIT IssuerAltName OPTIONAL,
>    keyIdentifier                KeyIdentifier }

This is a structure that is different from the "option 3". Why ?

The proposed structure would be roughly equivalent if the KeyIdentifier
were a hash of the public key of the CA. Since a keyIdentifier is only a
bit string, it will NOT prevent collisions.

Why don't you take the "option 3 " ?

Denis

> Will this address everyone's concerns?
> If you want to just use the Issuer's key as the method of figuring
> out the issuer, you can do that. If you want to use the Name and/or
> the AltName, that will also work.
> 
> Comments?
> 
> Ambarish
> 
> --
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                              (650) 849-9880
> ValiCert, Inc.                                  [email-masked]
> 3160 W. Bayshore Road                         http://www.valicert.com
> Palo Alto, CA 94303

-- 
      Denis Pinkas     Bull S.A.          mailto:[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

From: [email-masked]
To: "Bob Jueneman" <[email-masked]>
cc: [email-masked]
Date: Tue, 12 May 1998 12:01:27 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Bob Jueneman <[email-masked]> writes:

>Peter said that one of the primary uses of alternate names
>was to accommodate those name forms that can't be a DN,
>e.g., almost everything useful.  I have to strongly disagree with
>that notion, which I thought we had overthrown back in the
>PEM days.
>
>To the best of my knowledge, the ITU does not act as any kind of
>a schema registration "authority" for X.500 or anything else.
>Nor, even less, do they act as a name registration authority for
>names that are defined within any particular schema.
>
>So although it might be too strong to say that such a view
>is ludicrous, I firmly believe that it would be wrong.
>
>I may be somewhat notorious for my "MPEG of my cat" view
>of what a DN can contain, but to the best of my knowledge,
>anyone who wanted to create an OID and a syntax description
>for such an attribute would be PURRFECTLY within their rights
>to include it within their certificate DN. So there is absolutely
>no reason at all why an RFC822 name, DNS name, or anything else
>that is at all reasonable could not be contained in a DN.  In
>particular, neither PKIX, nor X.500, in fact, has to be constrained
>by the oxymoronic "useful attributes" defined in X.520.

I agree, and in particular it's wrong to claim that an RFC 2247 name is
somehow less "real" or more of a hack than an X.521 OrganizationalPerson
name.

>And to respond to John's comment, PKIX could in fact totally
>ignore issues of what kinds of attributes are allowed for a DN
>in a certificate, and PKIX would still work. Chains could be searched,
>name constraints applied (assuming the basic comparison syntax is
>supplied), etc.
>
>The only thing that won't work is _interoperability_, especially with
>various kinds of directories.  Directories, especially most X.500
>directories, are NOT general purpose relational search engines.

My position is that a relying party shouldn't itself impose schema
constraints on the names that it is willing to accept.  If it is using a
directory to retrieve certificates, then that directory may well impose
restrictions of its own, and that is a good reason for CAs to be careful
about the sorts of names they issue certificates for, but, assuming that an
end-system can obtain a certificate, it shouldn't refuse to use that
certificate in a chain simply because the name contains an attribute that
the end-system doesn't recognize.

>Most X.500 and similar directories I know of can find almost
>anything very quickly, but ONLY if the search arguments have
>been predefined as some kind of a filter. So given a name, you
>can look up anything that is filed under that name, including say
>street address, telephone number, e-mail address, certificates, and
>the obligatory cat picture.
>
>Likewise, if you PREDEFINE the appropriate filters, you can look up
>what is effectively an alias that doesn't have to be created specifically,
of
>say my telephone number, and get back a pointer to my name and all
>the rest.
>
>But unless you have predefined it, you cannot enter a picture of my cat,
>or even my e-mail address, and find anything else, unless you are
>prepared to search the ENTIRE database for a match.
>
>Therefore, the CAs and the director service providers are going to
>HAVE to play a strong role in defining what kind of names (schemas)
>are acceptable if we want directories to work at all. Since PKIX is active
>in this field, I would hope they would take the initiative, otherwise, I
would
>expect that the CAs would get together and decide for themselves --
>after all, they have to sign the certificate containing the DN, and
>presumably they take some degree of responsibility for the contents.

I think this is an important thing to do, however, I don't think we need to
hold up PKIX-1 for it.  PKIX-1 should explicitly allow names constructed
using arbitrary attribute types.

>So my view is that the DN should contain names that are agreed within
>the community to fall within an acceptable schema, AND ARE
>SEARCHABLE WITHIN  A DIRECTORY. Otherwise, I would argue,
>there is no reason to have a DN at all.

Not all certificates necessarily need to be obtained from a directory,
though.  An application protocol is entitled to provide some portion of the
certificate chain needed to establish trust in the final key, so if a
certificate is always used in the context of such a protocol, the fact that
it might contain names using unusual schema ought not to matter, provided
that the relying party can correctly verify that the subject of one cert
"matches" the issuer of the next. Of course, with an unknown attribute,
matching is a little tricky, but there is text pending for inclusion in
PKIX-1 that specifies binary matching for all string syntaxes other than
printableString, and while I'm not sure of the wisdom of doing this when an
end-system knows how to apply X.520 matching rules, I think it's a
perfectly acceptable fallback position for a relying party to take for
attributes it doesn't recognise.

>So what purpose is or should be served by alternate names?
>
>Well, in my view, at least, they are representations made by the
subscriber
>to the CA, and hence to relying parties, and as such may have certain
legal
>consequences. So even if the CA does not have the resources to do a full
>due diligence investigation of their veracity, that doesn't mean that a
>subscriber is entitled to make any representations he wishes in this
regard.
>
>Ideally, anything contained in an alternate name should carry an explicit
>Nonverified Subscriber Information flag, in order to make this much
clearer.
>But failing that, the CA at least ought to spell out in their CPS whether
or
>not they independently verify the subscriber's right-to-use and perhaps
global
>unambiguity of those attributes.
>
>In answer to John's last point, I agree that it would be possible
>and under some circumstances desirable, to provide those alternative,
>not rigidly bound names or other attributes by means of a directory.
>But although I very much WANT to be able to look up certificates, CRLs,
>etc. in a directory, I don't think that users should be COMPELLED
>to.
>
>If this gets to be too much of an impasse, we could always define the
>syntax for an alternate subject (or issuer) name to be a compound
attribute,
>and define on a per attribute or even per name basis a Nonverified
>Subscriber Information bit.
>
>So I would modify David's taxonomy to include a fourth option, which
>would be my preference:
>
>" iv) They are alternative names which are a representation
>made by the subscriber to the CA and/or any relying party
>which may have legal consequences, but which may or
>may not have been independently verified by the CA. They
>may be used by end-systems for display to the user in
>security-related contexts, and may also be used for such
>secondary purposes as automatic e-mail or http address
>confirmation. They are not used in chain-building, certificate
>retrieval, certificate verification, or constraint processing."

I'm perfectly happy with that interpretation, although I'd prefer to extend
"They may be used by end-systems for display to the user in
security-related contexts" to something like "They may be used by
end-systems for display to the user in security-related contexts, but that
such display should be accompanied by a disclaimer that the authenticity of
such names may not have been verified by the CA, and that the CA's CPS
should be consulted before placing the same level of trust in an altName as
in a DN".  This interpretation would be a change from the behavior
specified in the current draft of PKIX-1, which uses altName fields for
chain-building.

John

Date: Tue, 12 May 1998 09:45:05 +0200
To: [email-masked]
From: [email-masked] (Olivier Onimus)
Subject: Re: Alternate name semantics and usage (again!)
Sender: [email-masked]

Hi,

I may have missed something basic in the (very long) discussion
you are follwing since several days, but IMO, the "semantics" of
Alternate name in comparison with "Name" (e.g. for subject)=20
is already (well) defined in X.509:

"subject" and "Issuer" in Certificat are of type "Name". Name is defined in
X.501 as =84SEQUENCE OF RelativeDistinguishedName".  This means that only=
 RDNs
(of a real or a virtual existing DIT) should be present at this level.

In X.509, Chapter. 12.3.1 about the Extensions, it is said:

    The following requirements relate to certificate subject and=20
    certificate issuer attributes:
	a) Certificates need to be usable by applications=20
           that employ a variety of name forms, including=20
           Internet electronic mail names, Internet domain names,=20
           X.400 originator/recipient addresses, and EDI party names.
           It is therefore necessary to be able to securely associate
           multiple names of a variety of name forms with a certificate
           subject or a certificate or CRL issuer.
	b) A certificate user may need to securely know certain
           identifying information about a subject in order to have
           confidence that the subject is indeed the person or thing
           intended. For example, information such as postal address,
           position in a corporation, or a picture image may be required.
           Such information may be conveniently represented as directory
attributes,
           but these attributes are not necessarily part of the
distinguished name.
           A certificate field is therefore needed for conveying additional
           directory attributes beyond those in the distinguished name.

What I do understand is, that the attributes of the =84Issuer" or =84Subject=
",
which can not be coded in the fields =84issuer" or =84subject", because they=
 are
not part of a RDN, can be coded as certificate-extension. That's all.

With the informations contained in "Issuer", I can identify (as software) a
tree (DIT)
in which I can identify in a UNIQUE way (as software) an entry using the
information contained in "Subject". The extra information contained in the
extension "AltName" may=20
be used for me (as user) to identify the subject or the issuer of the
certificate in another way. The informations are (as David P. Kemp said)
"only extra identification information".

Another remark before I finish: I don't want to defend here the x.509-world.=
=20
I know, PKIX will profile the X.509 world in such a way the whole stuff=
 works
and the designers and the implementors can easily understand what is meant.=
 I
just thought that this discussion about "Alternate name semantics and usage"
could take something from what is specified in X.509.....

Olivier

Date: Mon, 11 May 1998 16:58:20 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Hi All,
    Given the amount of debate on this topic, I am proposing the
following structure to identify a certificate in OCSP:

CertID ::= SEQUENCE {
   issuerNameAndKey     IssuerNameAndKey,
   serialNumber         CertificateSerialNumber }

IssuerNameAndKey ::= SEQUENCE {
   issuer			Name,
   issuerAltName	[0]	EXPLICIT IssuerAltName OPTIONAL,
   keyIdentifier		KeyIdentifier }

Will this address everyone's concerns?
If you want to just use the Issuer's key as the method of figuring
out the issuer, you can do that. If you want to use the Name and/or
the AltName, that will also work.

Comments?

Ambarish

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Mon, 11 May 1998 16:15:00 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

>Apologies if I'm asking something that should be obvious from reading
>the specs, but this long discussion makes me wonder.

No apologies are necessary.  The questions you are asking are in fact
recorded very precisely in the original X.DOT specifications. Unfortunately=
=20
the specs are copyrighted and can only be referenced by visting the =
archives=20
on the planet Vogon in person, after payment of 1000 International =
Standard=20
Units of platinum, ISO 4217 alpha currency code XPT, numeric=20
funds code 962. Unfortunately ISO 4217 does not specify what the=20
standard units ARE, but only their names, so it might be grams, troy=20
ounces, or mean solar mass equivalent.  Probably it is the latter,=20
so bring your American Express card.
>
>In much of the world we live in, it's well understood how to get
>(a) an IP address, (b) a DNS name.

Actually, in MOST of the world we live in, it is far from obvious how one
goes about getting an IP address, or even an DNS name.  Take a poll
of 1000 AOL newbies, and ask them whether they fully understand the=20
intricacies of DHCP, for example. I certainly don't pretend to.  =
Likewise=20
a DNS name, if I'm behind a firewall on a corporate network.
>
>On the other hand, X.500 style names (i.e., strings of the form =
"C=3DUS,=20
>ORG=3Dbar, FOO=3Dxxx...") are, most of the time, going to be received =
with=20
>"what the heck is *that*?".  That's not a problem if we can simply
>write some documentation to make it clear.

On the other hand, I would suggest that most people _would_ understand=20
a question such as "what country do you live in, i.e., what is your =
primary=20
residence?" (We won't get into residence vs. domiciles).

And most people would be able to answer the question, "What is the=20
name of the organization you work for or are associated with?"

Depending on the frequency of organization updates, answering a question
about organizational units might be a bit more difficult, I suppose.

Now the trickiest of all might be "What is your name?"  But that is
because standards organizations, unfortunately including PKIX , worry=20
excessively about the obscure minutia, and never get around to specifying
whether the form is last name first, first name last, or what a surname =
is.
I suppose it is due to early toilet training, or something -- anal =
retentive,
I think it's called.

Hopefully, the public CAs will enforce some discipline on this process,=20
and if they don't, some very small number of dominant vendors will=20
do so (unless the Justice Department gets into the act). At least I hope =
so.

Notice that nowhere in this process did I ever use such X.400 business=20
card jargon as c=3DUS,O=3Dfoo, cn=3DBar.  And anyone's GUI that does=20
use such junk ought to be banned, at least if it is intended for the =
casual user.

(If, however, it is the network administrator, or the directory administrat=
or,
or other reasonably skilled person who is filling out these screens, then
a certain latitude can perhaps be tolerated.  Just like doctors and =
lawyers,
system administrators have to use a specialized language to communicate
with their brethren, or anybody might be able to do this stuff! :-)
>
>However, what *is* critical is that there has to be a well defined,
>easily executed, and effective way for people to obtain the names they=20
>need.  It isn't clear to me yet from the discussion whether this is
>the case, or if so, what the process is.

People don't OBTAIN names, they HAVE names, or they are given them,
typically by their parents. People who work for organizations and =
choose=20
(or are told) to use that organizational person class (excuse the =
jargon)=20
inherit those names. People who chose to be identified by their residential=
=20
addresses look on their mailbox. People who only want to be identified by
obscure 8 character e-mail names have to ask their system administrator=20
what they should use, to make sure it doesn't give away corporate secrets.
>
>Does it amount to re-encoding the DNS name into a different syntax?
>That works (except for the pain of explaining why a different syntax
>that doesn' have any different semantics is useful).  Or does it
>requiring going to a different authority and getting an additional
>name in a different naming hierarchy?  If so, which authority?

Note that the ordinary DNS name hardly has any syntax specified=20
at all, except that the various names are separated by periods.

Syntactically, com.novell.www would be a perfectly legitimate=20
DNS name.  It isn't a legal name SEMANTICALLY, because the DNS
name registration folks won't honor www as a suffix.  Aside from that=20
point, almost anything goes -- .foo.bar.www.novell.com would be fine.

So if you wanted to code up such a name in X.500 style, what you
SHOULD do is create an attribute, say

dnsName ::=3D DnsName IDENTIFIED BY (<attribute OID>)
DnsName ::=3D DIRECTORY STRING

If you were so inclined, you might say something about the included=20
periods, say in the comments field, but you don't really have to.=20
And you certainly don't have to break up the name
into various arbitrary labeled components -- syntactic chaff.

Unfortunately, people were either too ignorant, too lazy, in a big =
hurry,=20
or thought that God and/or the ITU had already invented all of=20
legal X.500 names, and so they perverted the already obscure=20
semantic definition of commonName by using it for DNS names,
RFC822 names, yada, yada, yada. And all of the lessons people
learned about the virtues of strong typing in Computer Science 101
went right out the window.

Naughty, naughty, naughty!

Bob

Date: Mon, 11 May 1998 16:49:56 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

> From: Paul Koning <[email-masked]>
> 
> Apologies if I'm asking something that should be obvious from reading
> the specs, but this long discussion makes me wonder.
> 
> In much of the world we live in, it's well understood how to get
> (a) an IP address, (b) a DNS name.
> 
> On the other hand, X.500 style names (i.e., strings of the form "C=US, 
> ORG=bar, FOO=xxx...") are, most of the time, going to be received with 
> "what the heck is *that*?".  That's not a problem if we can simply
> write some documentation to make it clear.

Is it clear that an X.500 style name of the form "E=[email-masked]"
means what one would expect it to mean?  The emailAddress DN attribute
(1.2.840.113549.1.9.1, commonly abbreviated as "E") is already used
in many certs.  Unfortunately, many CAs generally include it in
a meaningless mishmash of a DN
("C=US, ORG=Bar, CN=Fred Jones, E=[email-masked]") in which the fourth RDN
has no subordinate relationship to the third; this misuse is what
prompted the ITU to define GeneralName in the first place.
But IMHO the proper response to DN abuse is not to create a whole new
syntax, but to define a schema which would demonstrate the proper use
of the existing DN syntax.

> Does it amount to re-encoding the DNS name into a different syntax?

Yes.

> That works (except for the pain of explaining why a different syntax
> that doesn' have any different semantics is useful).

If one is prepared to require that all certs with DNS subjects are
End Entity certs, then there is no difference in semantics and no reason
to have a multi-RDN syntax for DNS names.

However, DNS doesn't work that way.  It's a heirarchy, with registration
delegated to administrators at lower levels.  If you want the CA topology
to mirror the DNS administrative topology, then you want the CA for
"DC=net, DC=vaultline" to be able to issue a CA cert for
"DC=net, DC=vaultline, DC=santaclara" and have the normal name
constraint process work as expected.  The ITU has not defined any
processing rules to go along with GeneralName, so the semantics of the
multi-RDN form *is* different than the undefined semantics of a single
subjectAltName string of "dNSName=santaclara.vaultline.net".

> Or does it
> requiring going to a different authority and getting an additional
> name in a different naming hierarchy?

No!

Date: Mon, 11 May 1998 14:53:43 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Apologies if I'm asking something that should be obvious from reading
the specs, but this long discussion makes me wonder.

In much of the world we live in, it's well understood how to get
(a) an IP address, (b) a DNS name.

On the other hand, X.500 style names (i.e., strings of the form "C=US, 
ORG=bar, FOO=xxx...") are, most of the time, going to be received with 
"what the heck is *that*?".  That's not a problem if we can simply
write some documentation to make it clear.

However, what *is* critical is that there has to be a well defined,
easily executed, and effective way for people to obtain the names they 
need.  It isn't clear to me yet from the discussion whether this is
the case, or if so, what the process is.

Does it amount to re-encoding the DNS name into a different syntax?
That works (except for the pain of explaining why a different syntax
that doesn' have any different semantics is useful).  Or does it
requiring going to a different authority and getting an additional
name in a different naming hierarchy?  If so, which authority?

	paul

Date: Mon, 11 May 1998 12:57:32 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

John, Peter, and David,

This has been a very illuminating discussion.

First off, I suppose I should apologize for using the term "ludicrous."
I did not mean to deprecate anyone's opinion that differed from=20
mine. But there are apparently some rather divergent views.

Peter said that one of the primary uses of alternate names
was to accommodate those name forms that can't be a DN,
e.g., almost everything useful.  I have to strongly disagree with
that notion, which I thought we had overthrown back in the=20
PEM days.

To the best of my knowledge, the ITU does not act as any kind of=20
a schema registration "authority" for X.500 or anything else.=20
Nor, even less, do they act as a name registration authority for
names that are defined within any particular schema.

So although it might be too strong to say that such a view=20
is ludicrous, I firmly believe that it would be wrong.

I may be somewhat notorious for my "MPEG of my cat" view
of what a DN can contain, but to the best of my knowledge,
anyone who wanted to create an OID and a syntax description
for such an attribute would be PURRFECTLY within their rights
to include it within their certificate DN. So there is absolutely=20
no reason at all why an RFC822 name, DNS name, or anything else
that is at all reasonable could not be contained in a DN.  In=20
particular, neither PKIX, nor X.500, in fact, has to be constrained
by the oxymoronic "useful attributes" defined in X.520.

And to respond to John's comment, PKIX could in fact totally=20
ignore issues of what kinds of attributes are allowed for a DN
in a certificate, and PKIX would still work. Chains could be searched,
name constraints applied (assuming the basic comparison syntax is
supplied), etc.

The only thing that won't work is _interoperability_, especially with
various kinds of directories.  Directories, especially most X.500
directories, are NOT general purpose relational search engines.

Most X.500 and similar directories I know of can find almost=20
anything very quickly, but ONLY if the search arguments have=20
been predefined as some kind of a filter. So given a name, you=20
can look up anything that is filed under that name, including say=20
street address, telephone number, e-mail address, certificates, and=20
the obligatory cat picture.

Likewise, if you PREDEFINE the appropriate filters, you can look up
what is effectively an alias that doesn't have to be created specifically, =
of
say my telephone number, and get back a pointer to my name and all=20
the rest.

But unless you have predefined it, you cannot enter a picture of my cat,
or even my e-mail address, and find anything else, unless you are=20
prepared to search the ENTIRE database for a match.=20

Therefore, the CAs and the director service providers are going to=20
HAVE to play a strong role in defining what kind of names (schemas)
are acceptable if we want directories to work at all. Since PKIX is active
in this field, I would hope they would take the initiative, otherwise, I =
would=20
expect that the CAs would get together and decide for themselves --=20
after all, they have to sign the certificate containing the DN, and=20
presumably they take some degree of responsibility for the contents.

So my view is that the DN should contain names that are agreed within=20
the community to fall within an acceptable schema, AND ARE=20
SEARCHABLE WITHIN  A DIRECTORY. Otherwise, I would argue,=20
there is no reason to have a DN at all.

At the admitted risk of overloading the semantic content of the=20
DN, I would also propose that the DN comport more or less well with
the more or less "official" name of the subject, i.e., the name that is =
legally=20
recognized as being associated with that entity.  That doesn't necessarily
rule out the use of an e-mail address in the appropriate contexts, but it
probably does rule out my cat.  (We sometimes have a disagreement on
this issue, but I claim that I own the cat, not vice versa. Not to get =
into
SPKI semantics, but my name is a legitimate qualifier for the cat, not=20
the other way around, at least until he can open his own cans of cat =
food.)

So what purpose is or should be served by alternate names?

Well, in my view, at least, they are representations made by the subscriber=
=20
to the CA, and hence to relying parties, and as such may have certain =
legal
consequences. So even if the CA does not have the resources to do a =
full=20
due diligence investigation of their veracity, that doesn't mean that a=20
subscriber is entitled to make any representations he wishes in this =
regard.

Ideally, anything contained in an alternate name should carry an explicit
Nonverified Subscriber Information flag, in order to make this much =
clearer.
But failing that, the CA at least ought to spell out in their CPS whether =
or=20
not they independently verify the subscriber's right-to-use and perhaps =
global
unambiguity of those attributes. =20

As I said in response to a private question regarding alternate language
names:

My position would be that even if an attribute were flagged with a=20
Nonverified Subscriber Information flag, it is still a representation=20
that is made by the CA, and hence to relying parties. The only
issue is whether the CA is capable of performing some additional=20
due diligence investigation at the time of issuance.

I don't want to necessarily force the CA to become a linguistics
expert in every possible language I might like to include in my
certificate, in order to have it be readable by my customers or=20
relying parties.

However, I do believe that if someone notices that the DN says
"Itty Bitty Movers" and the translation into Aramaic, Urdu, etc., says
International Business Machines Corp., SOMEBODY will be competent
in both languages, and will blow the whistle. Then either the CA will
revoke the certificate, or people will stop relying on that CA.

Reputation capital punishment in either case.

In answer to John's last point, I agree that it would be possible
and under some circumstances desirable, to provide those alternative,
not rigidly bound names or other attributes by means of a directory.
But although I very much WANT to be able to look up certificates, CRLs,
etc. in a directory, I don't think that users should be COMPELLED
to. =20

If this gets to be too much of an impasse, we could always define the=20
syntax for an alternate subject (or issuer) name to be a compound =
attribute,
and define on a per attribute or even per name basis a Nonverified
Subscriber Information bit.

So I would modify David's taxonomy to include a fourth option, which
would be my preference:

" iv) They are alternative names which are a representation
made by the subscriber to the CA and/or any relying party
which may have legal consequences, but which may or=20
may not have been independently verified by the CA. They=20
may be used by end-systems for display to the user in=20
security-related contexts, and may also be used for such=20
secondary purposes as automatic e-mail or http address=20
confirmation. They are not used in chain-building, certificate=20
retrieval, certificate verification, or constraint processing."

Bob

From: Ellen_McDermott/CAM/[email-masked]
To: [email-masked]
cc: Ellen_McDermott/CAM/[email-masked]
Date: Mon, 11 May 1998 13:55:32 -0400
Subject: -request to subscribe
Sender: [email-masked]

Date: Mon, 11 May 1998 12:28:02 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

> From: [email-masked] (Peter Gutmann)
>  
> Alternative Names
>  
> The subject and issuer alternative names are used to specify all the things
> which can't be given in a DN, which for most purposes means practically
> everything of any use on the Internet.

Can't is such a strong word.  "Sometimes aren't given in a DN" is more
accurate, since rfc822 names are often (incorrectly) included in
mixed-namespace DNs.  In your experience, what percentage of the certs
which contain rfc822 names encode them in an AltName extension?

  [snip - excellent discussion of the ambiguities created by
          the AltName extension]

> The solution to this problem would be to split the altName into two new 
> extensions, a true _alt__Name_ which provides a single _alternative_ to the 
> subject_Name_ (for example a single dNSName or rfc822Name) and which is used 
> only when the subject DN is empty, and a collection of other information 
> about the subject which follows the current altName syntax but which is used 
> strictly for informational purposes.  The true altName provides a single 
> alternative for the subjectName, and the informational altName provides any 
> extra identification information which the subject may want to include with 
> their certificate.
>  
> -- Snip --
>  
> This would require an amendment to X.509v3 though, I'm not sure how likely 
> that is to happen.  As it currently stands, the altName semantics are too 
> ambiguous to make it possible to rely on altNames for much.

A different solution which does not require an amendment to X.509:

 * AltName extensions are never used in path development, only the
   subject and issuer fields are used.  The AltName extensions are
   used only for extra identification information, verified or not
   as described in the CA's CPS.

 * subjects which have one true, certified name would have that name
   encoded as a DN.  RDN attributes already exist for emailAddress and
   DNS name component.  Additional attributes could be defined to hold
   the string form of a full DNS name, URI, EDIPartyName, etc.
   (An alternative, which I don't like but which should be mentioned
   anyway for completeness, is to define a single attribute with syntax
   GeneralName which could hold any nameform.)

 * subjects which have more than one certified subject name should have
   more than one certificate.  (I'd argue that those certs should have
   different public keys, but that's a different thread :-).

Date: Mon, 11 May 1998 18:21:26 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: [email-masked]
CC: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

John Wray wrote:

(text deleted)

> >                                  If we can solve the case of name
> >constraints with DNs, I see no reason why we could not solve it for
> >rfc822 and dNSName. This would at least allow an issuer name to be
> >either a DN or an rfc822 or a dNSName.
> 
> "Either" is the key qualifier.  Today, the PKIX-1 spec allows a certificate
> to carry an Issuer name and a number of IssuerAltNames, and this is the
> source of many of the problems I referred to in my earlier post.  If we
> were to constrain PKIX CAs to identify themselves in certificates using
> only a single name (i.e. either a DN which would go in the issuer field of
> certificates they cut, or a single rfc822 or dNSName which would be placed
> in the IssuerAltName extension of their certificates), that would go a long
> way towards simplifying the problem. 

This is exactly the case I would like to be supported.

>  Subtree constraints are already
> defined for both of these AltName types.

Would you point out to the text you refer ?
 
> The issue still remains of what do constraints mean in a certificate chain
> that crosses over between name-spaces. 

This is much more complex and I wonder if we can find an easy solution
for this. I would be satisfied if we could, at this time, address only
the case with a uniform naming.

> Suppose I have a certificate chain
> that starts in the DN namespace, and in which subtree constraints are
> applied by some early certificate.  Can a later CA-certificate (with an
> issuer DN permitted by the subtree constraints) contain a subject field
> expressed using the dNSName syntax?  How about if the DN-namespace
> constraints permit the use of names below the /DC=xxx root that matches the
> first domain component in the dNSName of the certificate in question?  This
> problem is one argument for preferring the use of RFC2247-format DNs names
> over dNSNames when trying to put a DNS name into a certificate.

I wonder if this is so easy since in one case you have a sequence of
"DC" versus a structure that contains no "DC=" at all. :-)

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[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: Mon, 11 May 1998 11:36:54 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

> From: [email-masked]
> 
> I agree that things are very much simpler if we can
> prescribe the use of DNs in all certificates, and I'd
> be quite happy with that restriction.  However, I don't
> see why PKIX needs to say anything about schema.  PKIX
> systems ought to be able to handle any X.500 name,
> regardless of whether that name follows an X.520/X.521
> schema, or whether it uses some private schema.

John,
  I agree almost completely.  The exception: PKIX should say something
about schema: it may reasonably define mandatory and optional schema to
promote interoperablity.  But PKIX and X.509 should not prohibit the
use of other (private or agreed-to-elsewhere) schema.

Bob says:

>    The question of who "owns" or registers name in the DN space is not
>    only ludicrous, but moot.  CAs are going to define them, and
>    directory service providers are going to decide whether or not that
>    schema is acceptable for their directory, and everything else will
>    spill on the floor.

The question isn't ludicrous, but "own" may have been a poor choice
of words.  Is there any question that Naming Authorities (such as
the IETF) exist, and that rfc822 names and DNS names are assigned
in accordance with a reasonably well defined registration procedure?

The question of ownership only came up as a result of the assertion
that the ITU owns the DN structure and that names registered by
non-ITU NAs such as the IETF could/should not appear in a DN.  I
wouldn't call this assertion "ludicrous", but I do disagree with it.

Schemas will be defined by PKIX and privately, and as you say, CAs,
application developers, and directory providers will decide which schemas
to support.  Schemas for representing rfc822 and DNS names as RDN
attributes should live or die based on their utility, not be automatically
rejected because "the ITU owns the DN space" and defines an AltName
extension to hold those other names.

> So, we have at least three different possible sets of
> semantics for the AltName fields:
> 
> i)  They are "official" names, and should be used to
> link certificates together in chain-building (perhaps
> only if there aren't DNs in ther certificates).  The
> current PKIX-1 draft is consistent with this
> interpretation, but doesn't define how the linkage is
> to be performed.
> 
> ii) They are nicknames, chosen by the end-system and
> unverified by the CA.  They are therefore not to be
> believed by end systems, and should not be displayed
> to the user in any security-related context.  They are
> not used in chain-building.
> 
> iii) They are approved alternative names, verified by
> the CA, and may be used by end-systems for display to
> the user in security-related contexts.  They are not
> used in chain-building.
> 
> We need to decide what these names mean, and what an
> end-system is required/permitted to do with them
> before we can include them in the PKIX profile.

My vote is for ii) or iii): AltName extensions are prohibited in chain
building.  Verifying (and the strength of verification) is a matter to
be described in the CPS.  Displaying is a UI issue - don't go there.

From: Sharon Boeyen <[email-masked]>
To: [email-masked], "'Scott, Greg'" <[email-masked]>
Subject: RE: Question re ipki2opp-07
Date: Mon, 11 May 1998 09:11:03 -0400
Sender: [email-masked]

Scott, I don't recall seeing a reply to this, but I've been away and am a
bit behind with email, so in case no one has responded yet:

The difference between the filtering ability in the two sections is that in
6.2.1 filtering is only permitted on the objectClass attribute and only the
"presence" test is supported. In 7.2.1 the enhanced filtering functionality
is that filtering can be done on any attribute and all LDAPv2 match types
can be tested, not just the presence test. Hope this helps.

Sharon

> ----------
> From: 	Scott, Greg[SMTP:[email-masked]]
> Sent: 	May 5, 1998 9:53 AM
> To: 	[email-masked]
> Subject: 	Question re ipki2opp-07
> 
>    This is probably painfully obvious to most, but I'm just asking to be 
>    sure.
>    
>    In section 6.2.1 the filter is defined as:
>    
>            Filter ::=
>              CHOICE {
>                      present       [7] AttributeType, -- "objectclass"
> only
>                     }
>    
>    In 7.2.1 the text states that an element added to this service is:
>    
>      "- Enhanced filter capability"
>    
>    but there is no ASN.1 code redefining Filter.  
>    
>    Does this mean that the full range of filter conditions defined in RFC 
>    1777 section 4.3 is now available?
>    
>    Thanks,
>    
>    Greg
>    
>    PS. Spelling and grammar nits:
>       
>        Section 6.2.2, I believe that "The application/relying party may 
>        ..." should read "The application/replying party may ..."
>        
>        Section 7, "To search ,using ..." should read "To search, using
> ..."
> 

From: [email-masked]
To: "Bob Jueneman" <[email-masked]>
cc: [email-masked]
Date: Mon, 11 May 1998 08:37:46 -0400
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Bob Jueneman <[email-masked]> writes:

>My very strong preference is to mandate the use of
>DNs in certificates, both for end-entities and especially
>for CAs.  And the schema for these DNs ought to be drawn
>from a rather limited set of the allegedly "useful
>attributes" defined in X.520, unless or until PKIX
>gets around (after five years and counting) to
>defining an acceptable schema.

I agree that things are very much simpler if we can
prescribe the use of DNs in all certificates, and I'd
be quite happy with that restriction.  However, I don't
see why PKIX needs to say anything about schema.  PKIX
systems ought to be able to handle any X.500 name,
regardless of whether that name follows an X.520/X.521
schema, or whether it uses some private schema.  While
individual CAs might well impose schema constraints
on the names they will issue certificates for, we
shouldn't build such restrictions into the PKIX specs,
as our ideas of what are appropriate constraints are
likely to change over time.  End systems in particular
ought to be able to do chain verification on certificates
regardless of the schema followed by the DNs in those
certificates.

>I believe that it is reasonable to require the CA do
>perform its due diligence on the DN, maybe even vouching
>for the organization's right to use.  However, I very
>much doubt that most CAs would step up to a due
>diligence verification of  all of the possible
>alternative spellings and translations. Nor should
>they have to, especially if such constructs are
>presented as alternate names.

If the CA hasn't verified a name, and isn't asserting
anything about its validity, what business does it
have signing it?  If an end-system has a need for
alternative "nicknames", then it should use a
directory service to publish those names, not try
to piggy-back them on the certificate infrastructure.

>So my bottom line is that the alternate names should
>be primarily intended for use as a human-readable
>confirmation of the subscriber's identity, but not
>necessarily for use as a means of searching for that name.

That's a very diffeent use from what the previous para
described.  This sounds like the CA's signature acts as
a stamp of approval on the AltNames - the CA asserts
that they are valid aliases for the subject DN, and as a
result of this CA approval, an end-system would feel
justified in using one of these AltNames in user display,
for example.

So, we have at least three different possible sets of
semantics for the AltName fields:

i)  They are "official" names, and should be used to
link certificates together in chain-building (perhaps
only if there aren't DNs in ther certificates).  The
current PKIX-1 draft is consistent with this
interpretation, but doesn't define how the linkage is
to be performed.

ii) They are nicknames, chosen by the end-system and
unverified by the CA.  They are therefore not to be
believed by end systems, and should not be displayed
to the user in any security-related context.  They are
not used in chain-building.

iii) They are approved alternative names, verified by
the CA, and may be used by end-systems for display to
the user in security-related contexts.  They are not
used in chain-building.

We need to decide what these names mean, and what an
end-system is required/permitted to do with them
before we can include them in the PKIX profile.

John

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Reply-To: [email-masked]
Date: Sat, 9 May 1998 09:11:51 (NZST)
Sender: [email-masked]

>My point was that in my view, at least, the primary purpose for alternate
>subject anmes (and even alternate issuer names) was to convey additional
>optional information to the relying party.
>
>If we start using them to convey all sorts of mandatory contraints, impose a
>requirement to be able to search for them in a directory, etc.,  then I think
>we have started down a different kind of semantics entirely.
 
I cover this problem in a not-yet-released version of the X.509 style guide, 
here's the section on altNames:
 
-- Snip --
 
Alternative Names
 
The subject and issuer alternative names are used to specify all the things
which can't be given in a DN, which for most purposes means practically
everything of any use on the Internet.  This includes email addresses, URL's
for web pages, server addresses, and other odds and ends like X.400 and EDI
addresses.  There's also a facility to include your postal address, physical
address, phone, fax and pager numbers, and of course the essential MPEG of your
cat.  
 
The alternative names can be used for certificate identification in place of
the DN's, however the exact usage is somewhat unclear.  In particular if an
altName is used for certificate chaining purposes, there's a roughly 50/50
split of opinion as to whether all the items in the altName must match or any
one of the items must match.  For example if an altName contains three URL's in
the issuer and one in the client (which matches one of the issuer URL's), noone
really knows whether this counts as a valid altName match or not.  Eventually
someone will make a decision one way or the other, probably the S/MIME
standards group who are rather reliant on altNames for some things.  Until this
is sorted out, it's not a good idea to rely on altNames for chaining.
 
This confusion is caused by the fact that an altName is serving two 
conflicting purposes.  The first of these is to provide extra information on 
the certificate owner which can't be specified in the DN, including things 
like their phone number, email address, and physical address.  The second is 
to provide an alternative to the ITU-managed (or, strictly speaking, 
non-managed) DN space.  For example a DNS name or IP address, which falls 
outside the range of ITU (non-)management, is controlled by the IETF, which 
has jurisdiction over the name space of the Internet-related altName 
components.  However since an altName can only specify a collection of names 
with a single critical attribute to cover all of them, there's no way to 
differentiate between something which really is critical (for example an 
rfc822Name being used in place of DN) and something which is merely present to 
provide extra details on the certificate owner (an rfc822Name being provided 
as a contact address).  One IETF draft overloaded this even further by forcing 
authorityInfoAccess semantics onto some of the altName components.
 
This ambiguity is complicated by the presence of other attributes like path 
processing constraints.  For example does an included or excluded subtree 
constraint containing a DN cover the subjectName DN, the altName 
directoryName, or both?.  More seriously, since a subjectName and altName 
directoryName have the same form, it's possible to specify an identical DN in 
two different ways across an issuer and subject cert, leading to the same 
problem described below in the name constraints section in which it's possible 
to evade constraint checks by using alternative encodings for the same item.
 
The solution to this problem would be to split the altName into two new 
extensions, a true _alt__Name_ which provides a single _alternative_ to the 
subject_Name_ (for example a single dNSName or rfc822Name) and which is used 
only when the subject DN is empty, and a collection of other information about 
the subject which follows the current altName syntax but which is used 
strictly for informational purposes.  The true altName provides a single 
alternative for the subjectName, and the informational altName provides any 
extra identification information which the subject may want to include with 
their certificate.
 
-- Snip --
 
This would require an amendment to X.509v3 though, I'm not sure how likely 
that is to happen.  As it currently stands, the altName semantics are too 
ambiguous to make it possible to rely on altNames for much.
 
Peter.

Date: Fri, 08 May 1998 11:55:25 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

My point was that in my view, at least, the primary purpose for alternate =
subject anmes (and even alternate issuer names) was to convey additional =
optional information to the relying party.

If we start using them to convey all sorts of mandatory contraints, impose =
a requirement to be able to search for them in a directory, etc.,  then I =
think we have started down a different kind of semantics entirely.

I mentioned something along these lines to Hoyt Kesterson a while ago, and =
I believe he told me that X.500 '97 provides the ability have multiple =
DNs, presumably for the same object.  I clearly don't undertand what the =
difference is between a DN and an alias to a ND in a directory, but having =
multiple DNs is a certificate, quite independent of the altSubjectName =
_semantics_ would be worth exploring, I think.

Can someone address this issue, like Sharon or Hoyt?

Bob>
>
>>>> Tony Bartoletti <[email-masked]> 05/08 11:38 AM >>>
>At 12:13 PM 5/7/98 -0600, Bob Jueneman wrote:
>>More seriously, though, where would the user get the logo in the first
>>place, from which to derive the hash in order to begin the search?
>>
>>Or were you only addressing the question of how to file a certificate=20
>>you already had in hand?
>>
>>bob
>
>Actually, I assumed that the "transaction-initiating party" (owner of
>the logo, in this case) would need to convey its location as part of
>the transaction.  But this is not helpful when the RP needs to collect
>yet-other-certs up a chain (cert-pull)...
>
>There would need to be a logo-link (uri) in each cert, akin to the way a
>CA may point to their CPS, for instance.  I am not really up to speed
>on the syntax/handling of subjectAltName.  If it could be an "object"
>then "hashLogo+uri" would be informational of itself, and provide a
>secure foundation for displaying a faithful "picture" for ID purposes.
>
>(I hadn't tried to work it out;)
>
>I suppose I just take it on faith that "a name is a bit-string" and how
>the bits are interpreted is a different matter.  But its not an independen=
t
>matter.  The method of interpretation must be joined with the bit-string
>in order to allow it to convey given meaning.
>
>I like the idea of a jpeg image/logo as a "name". (make it so;)

Date: Fri, 08 May 1998 10:38:30 -0700
To: "Bob Jueneman" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

At 12:13 PM 5/7/98 -0600, Bob Jueneman wrote:
>More seriously, though, where would the user get the logo in the first
>place, from which to derive the hash in order to begin the search?
>
>Or were you only addressing the question of how to file a certificate 
>you already had in hand?
>
>bob

Actually, I assumed that the "transaction-initiating party" (owner of
the logo, in this case) would need to convey its location as part of
the transaction.  But this is not helpful when the RP needs to collect
yet-other-certs up a chain (cert-pull)...

There would need to be a logo-link (uri) in each cert, akin to the way a
CA may point to their CPS, for instance.  I am not really up to speed
on the syntax/handling of subjectAltName.  If it could be an "object"
then "hashLogo+uri" would be informational of itself, and provide a
secure foundation for displaying a faithful "picture" for ID purposes.

(I hadn't tried to work it out;)

I suppose I just take it on faith that "a name is a bit-string" and how
the bits are interpreted is a different matter.  But its not an independent
matter.  The method of interpretation must be joined with the bit-string
in order to allow it to convey given meaning.

I like the idea of a jpeg image/logo as a "name". (make it so;)

___tony___

>>>> Tony Bartoletti <[email-masked]> 05/07 11:43 AM >>>
>At 09:19 AM 5/7/98 -0600, you wrote, in part:
>
>>It has even been suggested that we should take advantage of the "other
>name" form, and allow a JPEG logo to be included in subjectAltName, and
>presumably issuerAltName as well. I think that is a very reasonable
>suggestion, as the logo is more likely to be recognized internationally
>than the name, whether translated or not. but obviously I don't expect to
>do a name search against a logo, much less a name subordination constraint.
>
>Once bandwidth grows to allow JPEG images for _displayable_ names, it may
>make sense to provide a means to convey "HashOfJPEGID" in some field that
>one _could_ search on.
>
>I believe bandwidth WILL become so available, so one should plan for what
>it will allow.
>
>my two cents.
>
>___tony___
>
>
>Tony Bartoletti                                             LL
>SPI-NET GURU                                             LL LL
>Computer Security Technology Center                   LL LL LL
>Lawrence Livermore National Lab                       LL LL LL
>PO Box 808, L - 303                                   LL LL LLLLLLLL
>Livermore, CA 94551-9900                              LL LLLLLLLL
>email: [email-masked]   phone: 510-422-3881             LLLLLLLL
>
>
>

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Fri, 08 May 1998 14:55:33 +0100
From: "Stephen P. Wilson" <[email-masked]>
Organization: Defence Evaluation & Research Agency.
To: Bob Jueneman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

Bob Jueneman wrote:
> 
> More seriously, though, where would the user get the logo in the first
> place, from which to derive the hash in order to begin the search?

I suppose if there was a web page for whoever it was you were trying to
obtain the logo of - you could get it from there.

I think there is a much more fundamental problem than that though -
finding things by a simple text name is fairly simple - I don't think
anyone would have a problem spotting a the difference between "Stephen"
and Stephqn" - but, if you have a few hundred bytes of binary data,
that's kind of different - try taking a jpeg, and changing one pixel
from say RGB 0,0,0 (black) to RGB 0,0,1 (nearly black) - how many people
could actually tell the difference? - and, I'm sure they would generate
completely different hash values (especially as they are a compressed
file format - so I don't think it would even be just a single byte that
would change). the same thing goes for resizing the image (slightly more
obvious), changing the colour depth, and a whole host of things you can
do to graphic images which change them so subtly that it might not be
noticable.

Of course, that's not even considering the problems when companies start
redesigning their logos...

Stephen.

-- 
Stephen Wilson. BSc (hons), AMIEE.          [email-masked] 
The views and statements contained in this message are entirely those 
of the author and should not be considered as the opinion or policy 
of any other person or organisation.

From: "Miklos, Sue A." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: SHA-1 and RSA for signing certificates
Date: Fri, 8 May 1998 08:26:50 -0400
Sender: [email-masked]

Based on the Specification FIPS PUB 186, Digital Signature Standard,
dated  19 May 1994 (from NIST) the OID - iso(1) member-body(2) us(840)
x9-57(10040) x9algorithm(4) id-dsa-with-sha1(3) 1.2.840.10040.4.3  

and, I believe the American National Standard X9.57-199x Public Key
Cryptography for the Financial Services Industry: Certificate Management
21 June 1996  also references this oid.  The question for the X9 folks
is whether this oid will be preserved in an international registry.

Sandi

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Thursday, May 07, 1998 11:35 PM
>To: 	[email-masked]
>Cc: 	[email-masked]
>Subject: 	Re: SHA-1 and RSA for signing certificates
>
>>Section 7.2 of PKIX part 1 documents that the object identifier that shall
>>be
>>used to identify certificates signed using SHA-1 with the RSA algorithm will
>>be:
>>
>>        sha1WithRSASignature OBJECT IDENTIFIER  ::=  {
>>            iso(1) identified-organization(3) oiw(14)
>>            secsig(3) algorithm(2) 29  }
>>
>>In the S/MIME -msg draft, section A.4:
>>
>>sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
>>   {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}
>>
>>Who's gonna fix their stuff?
>>
>>I believe that the interpretation of the value represented by both of these
>>OIDs is exactly the same, only there are two different OIDs (only two?!?).
> 
>There are more than a dozen OID's covering SHA and DSA, but only two that I
>know of for SHA and RSA.  The correct ones (well, the OIDs du jour anyway)
>are:
> 
>  SHA-1: sha1 (1 3 14 3 2 26)
>  DSA: dsa (1 2 840 10040 4 1)
>  SHA-1 and DSA: dsaWithSha1 (1 2 840 10040 4 3)
>  SHA-1 and RSA: sha-1WithRSAEncryption (1 2 840 113549 1 1 5)
> 
>The SHA-1 OID is from the mostly-deprecated OIW arc, FIPS 180 never defined
>an
>OID for it but presumably once SHA-1 appears in other standards (eg ISO
>10118-3) it'll get a different OID.
> 
>Peter.
> 
>
>

From: Graham Bland <[email-masked]>
Date: Fri, 8 May 1998 8:42:20 +0000
To: [email-masked]
Subject: RE: Standards for Digitally Signed Docum
Sender: [email-masked]

IDUP-GSS is an API being developed by the cat-ietf group for handling=20
protection and authentication of independant data units
 Extract from abstract of draft-ietf-cat-idup-gss-11=2Etxt follows

   The IDUP-GSS-API extends the GSS-API [RFC-2078] for applications
   requiring protection of a generic data unit (such as a file or
   message) in a way which is independent of the protection of any other
   data unit and independent of any concurrent contact with designated
   ''receivers'' of the data unit=2E  Thus, it is suitable for applications
   such as secure electronic mail where data needs to be protected
   without any on-line connection with the intended recipient(s) of that
   data=2E  The protection offered by IDUP includes services such as data
   origin authentication with data integrity, data confidentiality with
   data integrity, and support for non-repudiation services=2E  Subsequent
   to being protected, the data unit can be transferred to the
   recipient(s) - or to an archive - perhaps to be processed
   (''unprotected'') only days or years later=2E

   Throughout the remainder of this document, the ''unit'' of data
   described in the above paragraph will be referred to as an IDU
   (Independent Data Unit)=2E  The IDU can be of any size (the application
   may, if it wishes, split the IDU into pieces and have the protection
   computed a piece at a time, but the resulting protection token
   applies to the entire IDU)=2E  However, the primary characteristic of
   an IDU is that it represents a stand-alone unit of data whose
   protection is entirely independent of any other unit of data=2E  If an
   application protects several IDUs and sends them all to a single
   receiver, the IDUs may be unprotected by that receiver in any order
   over any time span; no logical connection of any kind is implied by
   the protection process itself=2E

Graham
 ----------
From: WHenry@pec=2Ecom
To: Graham Bland
Subject: RE: Standards for Digitally Signed Docum
Date: Wednesday, 06 May, 1998 6:09PM

 Graham,

 What's an IDUP-GSS mechanism??

> -----Original Message-----
> From:   Graham Bland [SMTP:gbland@zergo=2Ecom]
> Sent:   Wednesday, May 06, 1998 11:38 AM
> To:     ietf-pkix@imc=2Eorg
> Subject:     RE: Standards for Digitally Signed Docum
>
> This could be considered within the context of an IDUP-GSS mechanism
>
> Graham
>  ----------
> From: samiklo@missi=2Encsc=2Emil
> To: ietf-pkix@imc=2Eorg; WHenry@pec=2Ecom
> Subject: RE: Standards for Digitally Signed Docum
> Date: Wednesday, 06 May, 1998 3:28PM
>
> May I suggest that those interested put together the appropriate request
> for a BOF at the Chicago IETF?
>
> Sandi
>
> >----------
> >From:    WHenry[SMTP:WHenry@pec=2Ecom]
> >Sent:    Tuesday, May 05, 1998 1:43 PM
> >To:      'ietf-pkix@imc=2Eorg'
> >Subject:      Standards for Digitally Signed Documents
> >
> > I hope this isn't out of the context of PKIX, but I'll ask anyway=2E Is
> there
> >an IETF WG or other that is handling standards for digitally signed
> >documents?
> >
> > There is an email/message transfer (i=2Ee=2E S/MIME) standard, but ther=
e
> don't
> >appear to be any similar standards for storage of digitally signed
> >documents=2E
> >
> > I see three options:
> > 1) use a proprietary format (e=2Eg=2E Entrust or Verisign) for storing
> >documents; in which case all who need access to the documents require th=
e
> >same public key infrastructure=2E
> > 2) actually store a signed document in S/MIME format=2E
> > 3) create middleware/proprietary option(s) for appending digital
> signatures
> >to the likes of =2Edoc or =2Eppt documents=2E
> >
> > I'd greatly appreciate any comments or thoughts on the above=2E
> >
> > Bill Henry
> > Performance Engineering Corporation
> > 3949 Pender Drive
> > Farifax, VA  22030
> > whenry@pec=2Ecom
> >
> >
> >
> >> -----Original Message-----
> >> From:  Miklos, Sue A=2E [SMTP:samiklo@missi=2Encsc=2Emil]
> >> Sent:  Tuesday, May 05, 1998 9:30 AM
> >> To:    'Blake Ramsdell'; 'Denis=2EPinkas@bull=2Enet'
> >> Cc:    'ietf-pkix@imc=2Eorg'
> >> Subject:    RE: Role names in certificates
> >>
> >> I'm somewhat confused=2E  I had thought that certificates and roles co=
uld
> >> be used in a variety of contexts (applications) for, among other
> things,
> >> access control=2E  Therefore this would appear to extend beyond just t=
he
> >> S/MIME messaging context=2E  Is this of interest to the LDAP access
> >> controls?  Is this useful for the web-based document retrieval
> >> environments?
> >>
> >> Sandi Miklos
> >>
> >>
> >> >----------
> >> >From:      Denis Pinkas[SMTP:Denis=2EPinkas@bull=2Enet]
> >> >Sent:      Tuesday, May 05, 1998 5:49 PM
> >> >To:   Blake Ramsdell
> >> >Cc:   'ietf-pkix@imc=2Eorg'
> >> >Subject:   Re: Role names in certificates
> >> >
> >> >> I have written a draft that I have submitted as an individual (not
> >> under
> >> >> IETF-PKIX)=2E  It describes a concept of using "role" names in
> >> >> certificates for several purposes that are not covered with
> >> conventional
> >> >> PKIX certificates=2E
> >> >
> >> >I am not sure that this thread is relevant to the PKIX WG=2E It might=
 be
> >> >more relevant to the S/MIME WG=2E
> >> >
> >> >> I have currently profiled the rfc822Name choice, but
> >> >> I have heard that there is interesting in profiling the dNSName
> choice
> >> >> also=2E  Cutting and pasting a little bit from the document, roles=20=
are
> >> >> defined for:
> >> >>
> >> >> * The need to sign messages on behalf of people at a domain that ma=
y
>
> or
> >> >> may not have signature services available at the desktop=2E An
> outbound
> >> >> message from a domain may be sent that is signed at the domain mail
> >> >> server=2E
> >> >
> >> >A requirement would be the need to sign a message as the Sales
> Director
> >> >of the Delta Company, who may happen to be John Walker=2E However Joh=
n
> >> >Walker may not have a private key of its own=2E
> >> >
> >> >> * The need to encrypt messages for people at a domain that may not
> have
> >> >> encryption services available at the desktop=2E A message may be
> >> encrypted
> >> >> for the domain mail server using a domain encrypting certificate,
> and
> >> >> that message will be decrypted before local delivery=2E
> >> >
> >> >For the other following cases related to encryption, I wonder why a
> role
> >> >is needed=2E
> >> >
> >> >> * The need to encrypt messages between two mail transfer agents
> (MTAs)=2E
> >> >> This is different than a domain encrypting certificate, in that the
> >> >> message is never encrypted or decrypted at the mail user agent (MUA=
)
> >> >> level=2E
> >> >>
> >> >> * The need to encrypt messages for a keypair that is controlled by
> the
> >> >> domain administrator for the purposes of plaintext access=2E A mess=
age
> >> may
> >> >> be encrypted for the domain mail server using a domain message
> recovery
> >> >> encryption certificate for the purpose of selective plaintext
> recovery
> >> >> by the domain administrator=2E This differs from a domain encryptin=
g
> >> >> certificate in that the message is not necessarily decrypted before
> >> >> local delivery=2E
> >> >>
> >> >> I know that the last one is going to be controversial, and this is
> not
> >> >> an all-or-nothing proposal (you can simply not implement it)=2E
> Please
> >> >> don't flame me for daring to speak its evil name, but keep an open
> mind
> >> >> for the other uses I have listed=2E
> >> >
> >> >> This is meant to get the ball rolling in a direction where we think
> >> >> about PKIX representing entities that are not necessarily a specifi=
c
> >> >> end-entity, but an end-entity with a particular role or
> responsibility=2E
> >> >
> >> >This is the point=2E
> >> >
> >> >> Any insight welcome as to how to address these issues in an
> alternative
> >> >> way=2E
> >> >
> >> >> http://www=2Edeming=2Ecom/users/blaker/draft-ramsdell-role-names is
> always
> >> >> the latest version
> >> >> http://www=2Eietf=2Eorg/internet-drafts/draft-ramsdell-role-names-0=
0=2Etxt
>
> is
> >> >> the current draft at the IETF=2E
> >> >>
> >> >> Now where's my suit=2E=2E=2E
> >> >
> >> >There are several ways to address this issue=2E Among them:
> >> >
> >> >1) a signature server (from a company) is able to sign documents on
> >> >behalf of an employee with its own key and indicate the appropriate
> role
> >> >used by the employee=2E The employee may authenticate to that signatu=
re
> >> >server by whatever means=2E In that case the signer is the company wh=
ich
> >> >indicates the role of the employee=2E
> >> >
> >> >2) a temporary certificate issued by a server of a company includes a
> >> >role and a temporary public key=2E The employee is given back the
> >> >temporary private key so that it can sign documens directly using tha=
t
> >> >private key=2E
> >> >
> >> >If we would like to support such scheme(s), some arrangements would
> need
> >> >to be done to the S/MIME specifications, so I would propose to shift
> >> >this thread to the S/MIME WG=2E
> >> >
> >> >Denis
> >> >
> >> >> Blake
> >> >> --
> >> >> Blake C=2E Ramsdell
> >> >> Worldtalk Corporation
> >> >> For current info, check http://www=2Edeming=2Ecom/users/blaker
> >> >> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
> >> >
> >> >--
> >> >      Denis Pinkas     Bull S=2EA=2E          mailto:Denis=2EPinkas@b=
ull=2Enet
> >> >      Rue Jean Jaures  B=2EP=2E 68            Phone : 33 - 1 30 80 34=
 87
> >> >      78340 Les Clayes sous Bois=2E FRANCE   Fax  : 33 - 1 30 80 33 2=
1
> >> >
> >
>
> --
> Zergo Limited, The Square, Basing View, Basingstoke, Hants=2E RG21 4EG, U=
K
> Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
> Website:  http://www=2Ezergo=2Ecom

--
Zergo Limited, The Square, Basing View, Basingstoke, Hants=2E RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www=2Ezergo=2Ecom

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: SHA-1 and RSA for signing certificates
Date: Thu, 7 May 1998 14:09:03 -0700
Sender: [email-masked]

> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, May 07, 1998 9:26 AM
> To: Blake Ramsdell
> Cc: [email-masked]'
> Subject: Re: SHA-1 and RSA for signing certificates
> 
> 
> Blake:
> 
> This is fixed in a draft that will be posted this week.

Thanks to everyone who pointed out that I was a moron and missed the
conversation from last month regarding this (under the subject
"[IETF-PKIX] PKIX1 inconsistent with PKCS1") that dealt with my exact
issue.  We now return you to static-free programming.

I did find out something interesting about the OIW padding, however.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Thu, 07 May 1998 12:13:27 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternate name semantics and usage
Sender: [email-masked]

"Never overlook the bandwidth of a station wagon full of tapes."

Particularly since the means of distributing certificates still seems=20
somewhat problematic.

More seriously, though, where would the user get the logo in the first
place, from which to derive the hash in order to begin the search?

Or were you only addressing the qeustion of how to file a certificate=20
you already had in hand?

bob

>>> Tony Bartoletti <[email-masked]> 05/07 11:43 AM >>>
At 09:19 AM 5/7/98 -0600, you wrote, in part:

>It has even been suggested that we should take advantage of the "other
name" form, and allow a JPEG logo to be included in subjectAltName, and
presumably issuerAltName as well. I think that is a very reasonable
suggestion, as the logo is more likely to be recognized internationally
than the name, whether translated or not. but obviously I don't expect to
do a name search against a logo, much less a name subordination constraint.=

Once bandwidth grows to allow JPEG images for _displayable_ names, it may
make sense to provide a means to convey "HashOfJPEGID" in some field that
one _could_ search on.

I believe bandwidth WILL become so available, so one should plan for what
it will allow.

my two cents.

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Thu, 07 May 1998 10:43:17 -0700
To: "Bob Jueneman" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: Alternate name semantics and usage
Cc: [email-masked]
Sender: [email-masked]

At 09:19 AM 5/7/98 -0600, you wrote, in part:

>It has even been suggested that we should take advantage of the "other
name" form, and allow a JPEG logo to be included in subjectAltName, and
presumably issuerAltName as well. I think that is a very reasonable
suggestion, as the logo is more likely to be recognized internationally
than the name, whether translated or not. but obviously I don't expect to
do a name search against a logo, much less a name subordination constraint.

Once bandwidth grows to allow JPEG images for _displayable_ names, it may
make sense to provide a means to convey "HashOfJPEGID" in some field that
one _could_ search on.

I believe bandwidth WILL become so available, so one should plan for what
it will allow.

my two cents.

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Thu, 07 May 1998 12:36:36 -0400
To: Nada Kapidzic Cicovic <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Usage of Diffe-Hellman keys
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

You interpret by position correctly.  Diffie-Hellman keys and ElGamal keys
shoudl have different AlgorithmIdentifiers.

Russ

At 01:38 PM 5/7/98 +0200, Nada Kapidzic Cicovic wrote:
>Peter and Russ,
>
>It seems that you both have the same opinion on ElGamal encryption with
>Diffie-Hellman keys. What you are suggesting is to use separate usage and
>object identifier for ElGamal keys.
>
>To me it seems to be an overkill for users who would like to use ElGamal
>for encryption. They would then need to have three different types of keys:
>
>- a pair of DSA keys for signing (being mandatory in PKIX and S/MIME),
>- a pair of DH keys for Diffie-Hellman key exchange (being mandatory in
>PKIX and S/MIME),
>- a pair of DH keys (or ElGamal keys, but essentially they are the same)
>for ElGamal encryption,
>
>in spite the fact that the two latter keys are syntactically the same (I am
>not suggesting the usage of ElGamal signature, so the strength of the
>generators is not questionable).
>
>
>
>Regards,
>Nada
>
>
>At 16:20 5/6/98, Peter Gutmann wrote:
>>>Trying to put this into S/MIME context it seems that Diffie-Hellman keys
may
>>>only be used in the way suggested by Russ Housley, i.e. for each
>recipient to
>>>take recipient's Diffie-Hellman certificate (key agreement certificate),
get
>>>the public key from there, generate a shared key (Russ suggested 3DES)
>and use
>>>it to encrypt the content-encryption key.
>>>
>>>However, another possibility is to use El-Gamal algorithm with
>Diffie-Hellman
>>>keys and encrypt the content-encryption key directly with recipients
>>>Diffie-Hellman public key. This would be a very similar operation as if the
>>>recipient had RSA keys and keyEnchipherment certificate. This seems to be a
>>>much better way of using Diffie-Hellman keys, similar to the way RSA keys
>are
>>>used for keys encryption (unless I have missed some point here).
>> 
>>If you use the key this way then it's no longer DH but Elgamal, with its
own 
>>algorithm/object identifiers and usage requirements.  For example some 
>>generators which are OK for Elgamal encryption aren't secure for Elgamal 
>>signatures, so if you've got DH-pretending-to-be-Elgamal (which PGP does,
>for 
>>example) you can't just use it as if it were Elgamal.  If you want to use a 
>>key for Elgamal encryption/signatures, you should really call it Elgamal,
>and 
>>not take a DH key and use it for something it was never designed for.
>> 
>>(If you want to get really nitpicky, there are actually three different 
>> algorithms which use keys which look more or less the same: DH (key 
>> exchange), Elgamal encryption == DH-Vernam encryption (encryption), and 
>> Elgamal signatures (signature).  It'd be nicer to actually call it Elgamal
>> rather than overload DH further and further)
>> 
>>Peter.
>> 
>>
>>
> 

Date: Thu, 07 May 1998 12:26:17 -0400
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SHA-1 and RSA for signing certificates
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Blake:

This is fixed in a draft that will be posted this week.

Russ

At 12:08 AM 5/7/98 -0700, Blake Ramsdell wrote:
>Section 7.2 of PKIX part 1 documents that the object identifier that
>shall be used to identify certificates signed using SHA-1 with the RSA
>algorithm will be:
>
>        sha1WithRSASignature OBJECT IDENTIFIER  ::=  {
>            iso(1) identified-organization(3) oiw(14)
>            secsig(3) algorithm(2) 29  }
>
>In the S/MIME -msg draft, section A.4:
>
>sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
>   {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}
>
>Who's gonna fix their stuff?
>
>I believe that the interpretation of the value represented by both of
>these OIDs is exactly the same, only there are two different OIDs (only
>two?!?).
>
>In practice, I have not seen any certificates signed using the
>sha1WithRSASignature OID.  I have, however, seen certificates signed
>with sha-1WithRSAEncryption.
>
>I apologize if this has been brought up before -- I found a thread from
>'97 that documents confusion surrounding "sha1WithRSAEncryption" using
>the OIW OID, and the change to make it "sha1WithRSASignature".
>
>For compatibility, it seems that sha-1WithRSAEncryption (the rsadsi
>version) should be recognized on receipt, but that new certificates must
>use sha1WithRSASignature (the OIW version).
>
>Perhaps some of the well-rounded cert people can speak up about what is
>currently out there (Peter from That Country Without Electricity?)
>
>I apologize if this has already come up in the past.  I checked the
>subjects in the (newly available!) '97 archive and didn't find anything.
>
>Blake
> 

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: "'Tim Polk'" <[email-masked]>
Subject: RE: SHA-1 and RSA for signing certificates
Date: Thu, 7 May 1998 12:15:19 -0400 
Sender: [email-masked]

There was an earlier discussion of this OID. I believe that as a result of
that, Tim Polk was going to change it in the PKIX profile to use the RSA
defined OID 1 2 840 113549 1 1 5 (sha1WithRSAEncryption). Tim, I assume your
updated document will contain this fix?

> ----------
> From: 	Blake Ramsdell[SMTP:[email-masked]]
> Sent: 	May 7, 1998 3:08 AM
> To: 	[email-masked]'
> Subject: 	SHA-1 and RSA for signing certificates
> 
> Section 7.2 of PKIX part 1 documents that the object identifier that
> shall be used to identify certificates signed using SHA-1 with the RSA
> algorithm will be:
> 
>         sha1WithRSASignature OBJECT IDENTIFIER  ::=  {
>             iso(1) identified-organization(3) oiw(14)
>             secsig(3) algorithm(2) 29  }
> 
> In the S/MIME -msg draft, section A.4:
> 
> sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
>    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}
> 
> Who's gonna fix their stuff?
> 
> I believe that the interpretation of the value represented by both of
> these OIDs is exactly the same, only there are two different OIDs (only
> two?!?).
> 
> In practice, I have not seen any certificates signed using the
> sha1WithRSASignature OID.  I have, however, seen certificates signed
> with sha-1WithRSAEncryption.
> 
> I apologize if this has been brought up before -- I found a thread from
> '97 that documents confusion surrounding "sha1WithRSAEncryption" using
> the OIW OID, and the change to make it "sha1WithRSASignature".
> 
> For compatibility, it seems that sha-1WithRSAEncryption (the rsadsi
> version) should be recognized on receipt, but that new certificates must
> use sha1WithRSASignature (the OIW version).
> 
> Perhaps some of the well-rounded cert people can speak up about what is
> currently out there (Peter from That Country Without Electricity?)
> 
> I apologize if this has already come up in the past.  I checked the
> subjects in the (newly available!) '97 archive and didn't find anything.
> 
> Blake
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: SHA-1 and RSA for signing certificates
Cc: [email-masked]
Reply-To: [email-masked]
Date: Fri, 8 May 1998 03:35:04 (NZST)
Sender: [email-masked]

>Section 7.2 of PKIX part 1 documents that the object identifier that shall be
>used to identify certificates signed using SHA-1 with the RSA algorithm will
>be:
>
>        sha1WithRSASignature OBJECT IDENTIFIER  ::=  {
>            iso(1) identified-organization(3) oiw(14)
>            secsig(3) algorithm(2) 29  }
>
>In the S/MIME -msg draft, section A.4:
>
>sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
>   {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}
>
>Who's gonna fix their stuff?
>
>I believe that the interpretation of the value represented by both of these
>OIDs is exactly the same, only there are two different OIDs (only two?!?).
 
There are more than a dozen OID's covering SHA and DSA, but only two that I
know of for SHA and RSA.  The correct ones (well, the OIDs du jour anyway) are:
 
  SHA-1: sha1 (1 3 14 3 2 26)
  DSA: dsa (1 2 840 10040 4 1)
  SHA-1 and DSA: dsaWithSha1 (1 2 840 10040 4 3)
  SHA-1 and RSA: sha-1WithRSAEncryption (1 2 840 113549 1 1 5)
 
The SHA-1 OID is from the mostly-deprecated OIW arc, FIPS 180 never defined an
OID for it but presumably once SHA-1 appears in other standards (eg ISO
10118-3) it'll get a different OID.
 
Peter.

Date: Thu, 07 May 1998 09:19:16 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Alternate name semantics and usage
Sender: [email-masked]

John, Steve, et al,

My very strong preference is to mandate the use of DNs in certificates, =
both for end-entities and especially for CAs.  And the schema for these =
DNs ought to be drawn from a rather limited set of the allegedly "useful =
attributes" defined in X.520, unless or until PKIX gets around (after five =
years and counting) to defining an acceptable schema.

Given such a restriction, I can at least be guaranteed a way of finding =
and/or revoking a certificate, although adding the hash of the public key =
would be better yet.

I really can't take seriously any proposal to apply name subordination =
constraints, etc., on subjectAltNames when the intent was to be rather =
loose about what those names were intended to contain.

The question of who "owns" or registers name in the DN space is not only =
ludicrous, but moot.  CAs are going to define them, and directory service =
providers are going to decide whether or not that schema is acceptable for =
their directory, and everything else will spill on the floor.

The thread that John was discussing may or may not have been the one on =
cert-talk where I was discussing what to do about multilingual countries, =
but there is clearly a need to define at least "roughly equivalent" names =
that are either official or unofficial translations or transliterations of =
the presumably "official" primary DN.

I won't attempt to type it in in Cryllic, but if Russian newspaper xxx =
xxxxxx is transliterated to "Krasynia Isvestia" or translated to "Red =
Star", then assuming that the publisher of that newpaper has some reason =
to have his organization's certificates be reasonably meaningful or =
comprehensible to non-Russian speakers, he needs to be able to publish =
those alternatives somewhere.  The obvious (and perhaps only) choice at =
present is subjectAltNames.

In addition to transliterating the official name into the latin alphabet =
and perhaps trnaslating it into English, a savvy Russian marketeer (no =
longer an oxymoron!) might well want to include Japanese (Kanji and/or =
katakana), Chinese, Arabic, Hebrew, Bengali, Urdu, etc., in addition to =
the more popular European languages (French, German, etc.)

I believe that it is reasonable to require the CA do perform its due =
diligence on the DN, maybe even vouching for the organization's right to =
use.  However, I very much doubt that most CAs would step up to a due =
diligence verification of  all of the possible alternative spellings and =
translations. Nor should they have to, especially if such constructs are =
presented as alternate names.

Of course, having to select one and only one name for inclusion in the DN =
may cause political incorrectness in some countries that are aggressively =
bilingual, e.g. Canada. In that case I would suggest that two certificates,=
 one with the DN in lanuguage A and the other with the DN in language B =
may be appropriate. They might or might not have the same public key.

It has even been suggested that we should take advantage of the "other =
name" form, and allow a JPEG logo to be included in subjectAltName, and =
presumably issuerAltName as well. I think that is a very reasonable =
suggestion, as the logo is more likely to be recognized internationally =
than the name, whether translated or not. but obviously I don't expect to =
do a name search against a logo, much less a name subordination constraint.=

Although it is (normally) perfectly feasible for a directory provider to =
map the alternate names to directory aliases, this isn't a universal =
requirement. the relying party can either do it or not, as he sees fit.

So my bottom line is that the alternate names should be primarily intended =
for use as a human-readable confirmation of the subscriber's identity, but =
not necessarily for use as a means of searching for that name.

If someone requires that an RFC822 name or a DNS name be included, I would =
think that in most cases it would suffice to include it in the alternate =
name form, and comparisons at the application level can be done against =
that name. If it is absolutely essential to include such a construct in =
the DN, we ought to define an attribute and assign it a suitable OID.  I =
would hate to see the semantics of commonName being debased more and more, =
just because implementors (or standards groups) are too lazy to define =
something more precisely.

<rant off>

Bob

>>> <[email-masked]> 05/07 6:13 AM >>>
Stephen Kent <[email-masked]> writes:

>
>Also, in practice, folks have used a wide variety of DNs in certs, in =
part
>because we have no formal, binding schema, as I noted previously.  Still,
I
>could interpret your suggestion to be that if a DN consisted of all DC
>attributes (and matching values), then there would be no ambiguity and =
one
>could establish a convention in the IETF sphere of influence to consider
>such DNs as equivalent to an AltName of the DNS form, right?
>
>Well, I guess one might pursue that path.  Is the major benefit of having
>these DNS names in sheeps (I mean DN) clothing, to facilitate lookup in
>LDAP servers?  Given the availability of AltNames, we don't want to
>encourage this hack as an alternative to use of those constructs.  Also,
we
>will now find ourselves with two supposedly equivalent ways of
representing
>the same name, which would further complicate the matching problems we've
>already been discussing just due to the various string representations in
>DNs.  Also, this approach doesn't address what I assume is the major
legacy
>problem we are facing now.  Many of the legacy examples we see are hybrid
>names that look like DNs, but just happen to end with a CN that is a DNS
>name (c.f. ALL SSL server certificate Subject names).
>
>So, before considering your suggestionn further, I'd like to see a more
>complete analysis of what problems we are solving and what new problems =
we
>are creating, to better understand the tradeoffs.

The most basic problem is: what combinations of names and set of naming
syntaxes have to be understood (i.e. have code specially written for them)
by an end-system or CA or OCSP responder or other infrastructure component
that wants to claim PKIX compliance (and implied interoperability with
other end-systems that make the same claim).  The more choice there is in
naming certificate issuers, the larger this required task becomes, and the
more potential for ambiguity is introduced into the spec.  This has =
effects
throughout the system, some of which are:

i) Chain processing, certificate retrieval: Given a certificate, I need to
be able to find certificates for the issuer.  To do this, I need some
mapping that takes me from the set of names in the certificate's Issuer =
and
IssuerAltName fields to a query I can pass to whatever certificate store
I'm using.  As an implementor, faced with the choice between a single
syntax (DN) and a plethora of syntaxes (DN, rfc822Name, dNSName,
x400Address, DN(again), EDIPartyName, URI, ipAddress, registeredID and
"otherName") with the possibility of more than one name using these
syntaxes, I know which choice makes my life easiest.

ii) Chain processing, path validity checking: There was a thread back in
January that discussed the meaning of a certificate that contained =
multiple
subject names (either in the Subject or SubjectAltName fields, or in the
combination of these), and whether the certificate bound each name
individually or the combination of all names to the key.  This discussion
petered out without real resolution, and only addressed end-entity certs.
The problem is greatly magnified with CA-certs.  If I have a trusted
CA-cert that contains multiple subject names, can it be used to verify
another cert whose issuer field contains a subset of those names, a
superset, or do the sets have to exactly match?  How about if there's just
a non-empty intersection?  How about if there's only one name in each =
cert,
and it's the same DN, but in one cert it's expressed as the Subject, while
in the other it's expressed as the directoryName choice in the
IssuerAltName?  How is any of this affected by the setting of the critical
bit in the IssuerAltName or SubjectAltName fields of the two certificates
(PKIX-1 makes setting this bit mandatory if the corresponding "non-Alt"
name is empty, but is silent if there is a non-Alt name)?  PKIX-1, section
6 states that the Issuer and Subject fields shall be used to chain, unless
they're empty, in which case the Alt fields should be used, but I'm not
sure this is correct, particularly if there's a critical Alt field _and_ a
corresponding non-empty non-Alt field.  On the other hand, the presence of
the critical bit isn't supposed to change the semantics implied by an
extension, it's merely supposed to indicate whether the certificate may be
processed by an end-system that doesn't understand the extension, so it
would be wrong to overload this bit to change the semantics of trust-chain
processing by end-systems that fully understand the extension.

iii) Chain processing, name constraints: Subtree constraints are defined
for DNs, rfc822, dNSName, uri names and (possibly) x400Address.  No =
mention
of EDIPartyName, ipAddress, registeredID or "otherName".  Is a
PKIX-compliant end-system expected to be able to apply name-constraints =
for
all these name types?  Do subtree constraints have to be satisfied on all
name-types, or just one name-type (the answer to this may be determined by
the answer to (ii) above).

iv) OCSP (the subject of this thread):  I need to be able to unambiguously
identify a certificate when querying its status.  If a certificate's =
issuer
is identified by a single IssuerAltName, then I need a way in the OCSP
protocol to send that along instead of a DN, and if the certificate has
multiple IssuerAltNames or both a Issuer and IssuerAltName(s), then I
presumably need to be able to send multiple names to the responder.  Does
is matter whether the IssuerAltName(s) are marked critical?  Presumably it
does, since an end-system ought to be able to ignore any non-critical
extension it doesn't understand, so an end system that doesn't understand
the IssuerAltName extension ought to be able to make an OCSP query without
including anything from that extension in the query, without causing a
security problem.

Requiring the use of the Issuer field (combined with a prohibition on
setting the critical bit on the IssuerAltName extension) in all PKIX
certificates greatly simplifies these issues.  Alternatively, we need to
fully address all the ambiguities that the use of "distinguished-AltNames"
introduces.  Unless this can be done very quickly, we should go with just
DNs, as it's imperative that we advance the spec ASAP.  We can always add
back other issuer name types when we properly define the semantics of
certificates that use them.

John

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Thu, 7 May 1998 10:21:36 -0400
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

>> iii) Chain processing, name constraints: Subtree constraints are defined
>> for DNs, rfc822, dNSName, uri names and (possibly) x400Address.  No
mention
>> of EDIPartyName, ipAddress, registeredID or "otherName".  Is a
>> PKIX-compliant end-system expected to be able to apply name-constraints
for
>> all these name types?  Do subtree constraints have to be satisfied on
all
>> name-types, or just one name-type (the answer to this may be determined
by
>> the answer to (ii) above).
>
>This is the most important issue. If we can solve the case of name
>constraints with DNs, I see no reason why we could not solve it for
>rfc822 and dNSName. This would at least allow an issuer name to be
>either a DN or an rfc822 or a dNSName.

"Either" is the key qualifier.  Today, the PKIX-1 spec allows a certificate
to carry an Issuer name and a number of IssuerAltNames, and this is the
source of many of the problems I referred to in my earlier post.  If we
were to constrain PKIX CAs to identify themselves in certificates using
only a single name (i.e. either a DN which would go in the issuer field of
certificates they cut, or a single rfc822 or dNSName which would be placed
in the IssuerAltName extension of their certificates), that would go a long
way towards simplifying the problem.  Subtree constraints are already
defined for both of these AltName types.

The issue still remains of what do constraints mean in a certificate chain
that crosses over between name-spaces. Suppose I have a certificate chain
that starts in the DN namespace, and in which subtree constraints are
applied by some early certificate.  Can a later CA-certificate (with an
issuer DN permitted by the subtree constraints) contain a subject field
expressed using the dNSName syntax?  How about if the DN-namespace
constraints permit the use of names below the /DC=xxx root that matches the
first domain component in the dNSName of the certificate in question?  This
problem is one argument for preferring the use of RFC2247-format DNs names
over dNSNames when trying to put a DNS name into a certificate.

>> iv) OCSP (the subject of this thread):  I need to be able to
unambiguously
>> identify a certificate when querying its status.  If a certificate's
issuer
>> is identified by a single IssuerAltName, then I need a way in the OCSP
>> protocol to send that along instead of a DN, and if the certificate has
>> multiple IssuerAltNames or both a Issuer and IssuerAltName(s), then I
>> presumably need to be able to send multiple names to the responder.
Does
>> is matter whether the IssuerAltName(s) are marked critical?  Presumably
it
>> does, since an end-system ought to be able to ignore any non-critical
>> extension it doesn't understand, so an end system that doesn't
understand
>> the IssuerAltName extension ought to be able to make an OCSP query
without
>> including anything from that extension in the query, without causing a
>> security problem.
>
>I believe that the answer has already be given on this topic. Option 3,
>as originally proposed by Ambarish, is the preferred option. We could
>use either the DN or the Alternate name (in addition to the certificate
>serial and a hash of the CA public key).

That's fine, provided we insist that there may be only a single issue name
in every PKIX certificate (although the OCSP syntax will have to allow for
the name type to be conveyed in the protocol when IssuerAltName is used).

John

Date: Thu, 07 May 1998 15:38:29 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: [email-masked]
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

John,

Thank you for joinging us on this thread.

> Stephen Kent <[email-masked]> writes:

> >Also, in practice, folks have used a wide variety of DNs in certs, in part
> >because we have no formal, binding schema, as I noted previously.  Still,
> >I could interpret your suggestion to be that if a DN consisted of all DC
> >attributes (and matching values), then there would be no ambiguity and one
> >could establish a convention in the IETF sphere of influence to consider
> >such DNs as equivalent to an AltName of the DNS form, right?
> >
> >Well, I guess one might pursue that path.  Is the major benefit of having
> >these DNS names in sheeps (I mean DN) clothing, to facilitate lookup in
> >LDAP servers?  Given the availability of AltNames, we don't want to
> >encourage this hack as an alternative to use of those constructs.  Also,
> >we will now find ourselves with two supposedly equivalent ways of
> >representing the same name, which would further complicate the 
> >matching problems we've already been discussing just due to the 
> >various string representations in DNs.  Also, this approach doesn't 
> >address what I assume is the major legacy problem we are facing now.  
> >Many of the legacy examples we see are hybrid names that look like DNs,
> >but just happen to end with a CN that is a DNS name (c.f. ALL SSL 
> >server certificate Subject names).
> >
> >So, before considering your suggestion further, I'd like to see a more
> >complete analysis of what problems we are solving and what new problems we
> >are creating, to better understand the tradeoffs.
> 
> The most basic problem is: what combinations of names and set of naming
> syntaxes have to be understood (i.e. have code specially written for them)
> by an end-system or CA or OCSP responder or other infrastructure component
> that wants to claim PKIX compliance (and implied interoperability with
> other end-systems that make the same claim).  The more choice there is in
> naming certificate issuers, the larger this required task becomes, and the
> more potential for ambiguity is introduced into the spec.  This has effects
> throughout the system, some of which are:
> 
> i) Chain processing, certificate retrieval: Given a certificate, I need to
> be able to find certificates for the issuer.  To do this, I need some
> mapping that takes me from the set of names in the certificate's Issuer and
> IssuerAltName fields to a query I can pass to whatever certificate store
> I'm using.  As an implementor, faced with the choice between a single
> syntax (DN) and a plethora of syntaxes (DN, rfc822Name, dNSName,
> x400Address, DN(again), EDIPartyName, URI, ipAddress, registeredID and
> "otherName") with the possibility of more than one name using these
> syntaxes, I know which choice makes my life easiest.
> 
> ii) Chain processing, path validity checking: There was a thread back in
> January that discussed the meaning of a certificate that contained multiple
> subject names (either in the Subject or SubjectAltName fields, or in the
> combination of these), and whether the certificate bound each name
> individually or the combination of all names to the key.  This discussion
> petered out without real resolution, and only addressed end-entity certs.
> The problem is greatly magnified with CA-certs.  If I have a trusted
> CA-cert that contains multiple subject names, can it be used to verify
> another cert whose issuer field contains a subset of those names, a
> superset, or do the sets have to exactly match?  How about if there's just
> a non-empty intersection?  How about if there's only one name in each cert,
> and it's the same DN, but in one cert it's expressed as the Subject, while
> in the other it's expressed as the directoryName choice in the
> IssuerAltName?  How is any of this affected by the setting of the critical
> bit in the IssuerAltName or SubjectAltName fields of the two certificates
> (PKIX-1 makes setting this bit mandatory if the corresponding "non-Alt"
> name is empty, but is silent if there is a non-Alt name)?  PKIX-1, section
> 6 states that the Issuer and Subject fields shall be used to chain, unless
> they're empty, in which case the Alt fields should be used, but I'm not
> sure this is correct, particularly if there's a critical Alt field _and_ a
> corresponding non-empty non-Alt field.  On the other hand, the presence of
> the critical bit isn't supposed to change the semantics implied by an
> extension, it's merely supposed to indicate whether the certificate may be
> processed by an end-system that doesn't understand the extension, so it
> would be wrong to overload this bit to change the semantics of trust-chain
> processing by end-systems that fully understand the extension.
> 
> iii) Chain processing, name constraints: Subtree constraints are defined
> for DNs, rfc822, dNSName, uri names and (possibly) x400Address.  No mention
> of EDIPartyName, ipAddress, registeredID or "otherName".  Is a
> PKIX-compliant end-system expected to be able to apply name-constraints for
> all these name types?  Do subtree constraints have to be satisfied on all
> name-types, or just one name-type (the answer to this may be determined by
> the answer to (ii) above).

This is the most important issue. If we can solve the case of name
constraints with DNs, I see no reason why we could not solve it for
rfc822 and dNSName. This would at least allow an issuer name to be
either a DN or an rfc822 or a dNSName.

> iv) OCSP (the subject of this thread):  I need to be able to unambiguously
> identify a certificate when querying its status.  If a certificate's issuer
> is identified by a single IssuerAltName, then I need a way in the OCSP
> protocol to send that along instead of a DN, and if the certificate has
> multiple IssuerAltNames or both a Issuer and IssuerAltName(s), then I
> presumably need to be able to send multiple names to the responder.  Does
> is matter whether the IssuerAltName(s) are marked critical?  Presumably it
> does, since an end-system ought to be able to ignore any non-critical
> extension it doesn't understand, so an end system that doesn't understand
> the IssuerAltName extension ought to be able to make an OCSP query without
> including anything from that extension in the query, without causing a
> security problem.

I believe that the answer has already be given on this topic. Option 3,
as originally proposed by Ambarish, is the preferred option. We could
use either the DN or the Alternate name (in addition to the certificate
serial and a hash of the CA public key).
 
> Requiring the use of the Issuer field (combined with a prohibition on
> setting the critical bit on the IssuerAltName extension) in all PKIX
> certificates greatly simplifies these issues.  Alternatively, we need to
> fully address all the ambiguities that the use of "distinguished-AltNames"
> introduces.  Unless this can be done very quickly, we should go with just
> DNs, as it's imperative that we advance the spec ASAP.  We can always add
> back other issuer name types when we properly define the semantics of
> certificates that use them.

I would agree with you that we need a quick solution. However, if some
one has some time available to transpose what is applicable to DNs to
the two other naming formats, then we could progress. This seems to be a
manageable work. Any candidate ?

Denis 

> John

-- 
      Denis Pinkas     Bull S.A.          mailto:[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

From: [email-masked]
To: Stephen Kent <[email-masked]>
cc: [email-masked]
Date: Thu, 7 May 1998 08:13:02 -0400
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>
>Also, in practice, folks have used a wide variety of DNs in certs, in part
>because we have no formal, binding schema, as I noted previously.  Still,
I
>could interpret your suggestion to be that if a DN consisted of all DC
>attributes (and matching values), then there would be no ambiguity and one
>could establish a convention in the IETF sphere of influence to consider
>such DNs as equivalent to an AltName of the DNS form, right?
>
>Well, I guess one might pursue that path.  Is the major benefit of having
>these DNS names in sheeps (I mean DN) clothing, to facilitate lookup in
>LDAP servers?  Given the availability of AltNames, we don't want to
>encourage this hack as an alternative to use of those constructs.  Also,
we
>will now find ourselves with two supposedly equivalent ways of
representing
>the same name, which would further complicate the matching problems we've
>already been discussing just due to the various string representations in
>DNs.  Also, this approach doesn't address what I assume is the major
legacy
>problem we are facing now.  Many of the legacy examples we see are hybrid
>names that look like DNs, but just happen to end with a CN that is a DNS
>name (c.f. ALL SSL server certificate Subject names).
>
>So, before considering your suggestionn further, I'd like to see a more
>complete analysis of what problems we are solving and what new problems we
>are creating, to better understand the tradeoffs.

The most basic problem is: what combinations of names and set of naming
syntaxes have to be understood (i.e. have code specially written for them)
by an end-system or CA or OCSP responder or other infrastructure component
that wants to claim PKIX compliance (and implied interoperability with
other end-systems that make the same claim).  The more choice there is in
naming certificate issuers, the larger this required task becomes, and the
more potential for ambiguity is introduced into the spec.  This has effects
throughout the system, some of which are:

i) Chain processing, certificate retrieval: Given a certificate, I need to
be able to find certificates for the issuer.  To do this, I need some
mapping that takes me from the set of names in the certificate's Issuer and
IssuerAltName fields to a query I can pass to whatever certificate store
I'm using.  As an implementor, faced with the choice between a single
syntax (DN) and a plethora of syntaxes (DN, rfc822Name, dNSName,
x400Address, DN(again), EDIPartyName, URI, ipAddress, registeredID and
"otherName") with the possibility of more than one name using these
syntaxes, I know which choice makes my life easiest.

ii) Chain processing, path validity checking: There was a thread back in
January that discussed the meaning of a certificate that contained multiple
subject names (either in the Subject or SubjectAltName fields, or in the
combination of these), and whether the certificate bound each name
individually or the combination of all names to the key.  This discussion
petered out without real resolution, and only addressed end-entity certs.
The problem is greatly magnified with CA-certs.  If I have a trusted
CA-cert that contains multiple subject names, can it be used to verify
another cert whose issuer field contains a subset of those names, a
superset, or do the sets have to exactly match?  How about if there's just
a non-empty intersection?  How about if there's only one name in each cert,
and it's the same DN, but in one cert it's expressed as the Subject, while
in the other it's expressed as the directoryName choice in the
IssuerAltName?  How is any of this affected by the setting of the critical
bit in the IssuerAltName or SubjectAltName fields of the two certificates
(PKIX-1 makes setting this bit mandatory if the corresponding "non-Alt"
name is empty, but is silent if there is a non-Alt name)?  PKIX-1, section
6 states that the Issuer and Subject fields shall be used to chain, unless
they're empty, in which case the Alt fields should be used, but I'm not
sure this is correct, particularly if there's a critical Alt field _and_ a
corresponding non-empty non-Alt field.  On the other hand, the presence of
the critical bit isn't supposed to change the semantics implied by an
extension, it's merely supposed to indicate whether the certificate may be
processed by an end-system that doesn't understand the extension, so it
would be wrong to overload this bit to change the semantics of trust-chain
processing by end-systems that fully understand the extension.

iii) Chain processing, name constraints: Subtree constraints are defined
for DNs, rfc822, dNSName, uri names and (possibly) x400Address.  No mention
of EDIPartyName, ipAddress, registeredID or "otherName".  Is a
PKIX-compliant end-system expected to be able to apply name-constraints for
all these name types?  Do subtree constraints have to be satisfied on all
name-types, or just one name-type (the answer to this may be determined by
the answer to (ii) above).

iv) OCSP (the subject of this thread):  I need to be able to unambiguously
identify a certificate when querying its status.  If a certificate's issuer
is identified by a single IssuerAltName, then I need a way in the OCSP
protocol to send that along instead of a DN, and if the certificate has
multiple IssuerAltNames or both a Issuer and IssuerAltName(s), then I
presumably need to be able to send multiple names to the responder.  Does
is matter whether the IssuerAltName(s) are marked critical?  Presumably it
does, since an end-system ought to be able to ignore any non-critical
extension it doesn't understand, so an end system that doesn't understand
the IssuerAltName extension ought to be able to make an OCSP query without
including anything from that extension in the query, without causing a
security problem.

Requiring the use of the Issuer field (combined with a prohibition on
setting the critical bit on the IssuerAltName extension) in all PKIX
certificates greatly simplifies these issues.  Alternatively, we need to
fully address all the ambiguities that the use of "distinguished-AltNames"
introduces.  Unless this can be done very quickly, we should go with just
DNs, as it's imperative that we advance the spec ASAP.  We can always add
back other issuer name types when we properly define the semantics of
certificates that use them.

John

Date: Thu, 07 May 1998 13:38:42 +0200
To: [email-masked], [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: Re: Usage of Diffe-Hellman keys
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter and Russ,

It seems that you both have the same opinion on ElGamal encryption with
Diffie-Hellman keys. What you are suggesting is to use separate usage and
object identifier for ElGamal keys.

To me it seems to be an overkill for users who would like to use ElGamal
for encryption. They would then need to have three different types of keys:

- a pair of DSA keys for signing (being mandatory in PKIX and S/MIME),
- a pair of DH keys for Diffie-Hellman key exchange (being mandatory in
PKIX and S/MIME),
- a pair of DH keys (or ElGamal keys, but essentially they are the same)
for ElGamal encryption,

in spite the fact that the two latter keys are syntactically the same (I am
not suggesting the usage of ElGamal signature, so the strength of the
generators is not questionable).

Regards,
Nada

At 16:20 5/6/98, Peter Gutmann wrote:
>>Trying to put this into S/MIME context it seems that Diffie-Hellman keys may
>>only be used in the way suggested by Russ Housley, i.e. for each
recipient to
>>take recipient's Diffie-Hellman certificate (key agreement certificate), get
>>the public key from there, generate a shared key (Russ suggested 3DES)
and use
>>it to encrypt the content-encryption key.
>>
>>However, another possibility is to use El-Gamal algorithm with
Diffie-Hellman
>>keys and encrypt the content-encryption key directly with recipients
>>Diffie-Hellman public key. This would be a very similar operation as if the
>>recipient had RSA keys and keyEnchipherment certificate. This seems to be a
>>much better way of using Diffie-Hellman keys, similar to the way RSA keys
are
>>used for keys encryption (unless I have missed some point here).
> 
>If you use the key this way then it's no longer DH but Elgamal, with its own 
>algorithm/object identifiers and usage requirements.  For example some 
>generators which are OK for Elgamal encryption aren't secure for Elgamal 
>signatures, so if you've got DH-pretending-to-be-Elgamal (which PGP does,
for 
>example) you can't just use it as if it were Elgamal.  If you want to use a 
>key for Elgamal encryption/signatures, you should really call it Elgamal,
and 
>not take a DH key and use it for something it was never designed for.
> 
>(If you want to get really nitpicky, there are actually three different 
> algorithms which use keys which look more or less the same: DH (key 
> exchange), Elgamal encryption == DH-Vernam encryption (encryption), and 
> Elgamal signatures (signature).  It'd be nicer to actually call it Elgamal
> rather than overload DH further and further)
> 
>Peter.
> 
>
>

From: "Rich Ankney" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: SHA-1 and RSA for signing certificates
Date: Thu, 7 May 1998 07:37:40 -0400
Sender: [email-masked]

I used to run the OIW registry, although I'm not responsible
for the one below.  We never registered PKCS #1 OIDs
(just documented them).  RSASignature indicates the use
of ISO 9796-style padding.  I assume that sha1WithRSA-
Signature follows the same approach.  So PKIX-1 is wrong
and S/MIME is right.  (We went through this exercise for
SET, as well).

Regards,
Rich

----------
> From: Blake Ramsdell <[email-masked]>
> To: [email-masked]'
> Subject: SHA-1 and RSA for signing certificates
> Date: Thursday, May 07, 1998 3:08 AM
> 
> Section 7.2 of PKIX part 1 documents that the object identifier that
> shall be used to identify certificates signed using SHA-1 with the RSA
> algorithm will be:
> 
>         sha1WithRSASignature OBJECT IDENTIFIER  ::=  {
>             iso(1) identified-organization(3) oiw(14)
>             secsig(3) algorithm(2) 29  }
> 
> In the S/MIME -msg draft, section A.4:
> 
> sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
>    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}
> 
> Who's gonna fix their stuff?
> 
> I believe that the interpretation of the value represented by both of
> these OIDs is exactly the same, only there are two different OIDs (only
> two?!?).
> 
> In practice, I have not seen any certificates signed using the
> sha1WithRSASignature OID.  I have, however, seen certificates signed
> with sha-1WithRSAEncryption.
> 
> I apologize if this has been brought up before -- I found a thread from
> '97 that documents confusion surrounding "sha1WithRSAEncryption" using
> the OIW OID, and the change to make it "sha1WithRSASignature".
> 
> For compatibility, it seems that sha-1WithRSAEncryption (the rsadsi
> version) should be recognized on receipt, but that new certificates must
> use sha1WithRSASignature (the OIW version).
> 
> Perhaps some of the well-rounded cert people can speak up about what is
> currently out there (Peter from That Country Without Electricity?)
> 
> I apologize if this has already come up in the past.  I checked the
> subjects in the (newly available!) '97 archive and didn't find anything.
> 
> Blake

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: SHA-1 and RSA for signing certificates
Date: Thu, 7 May 1998 00:08:24 -0700
Sender: [email-masked]

Section 7.2 of PKIX part 1 documents that the object identifier that
shall be used to identify certificates signed using SHA-1 with the RSA
algorithm will be:

        sha1WithRSASignature OBJECT IDENTIFIER  ::=  {
            iso(1) identified-organization(3) oiw(14)
            secsig(3) algorithm(2) 29  }

In the S/MIME -msg draft, section A.4:

sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
   {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

Who's gonna fix their stuff?

I believe that the interpretation of the value represented by both of
these OIDs is exactly the same, only there are two different OIDs (only
two?!?).

In practice, I have not seen any certificates signed using the
sha1WithRSASignature OID.  I have, however, seen certificates signed
with sha-1WithRSAEncryption.

I apologize if this has been brought up before -- I found a thread from
'97 that documents confusion surrounding "sha1WithRSAEncryption" using
the OIW OID, and the change to make it "sha1WithRSASignature".

For compatibility, it seems that sha-1WithRSAEncryption (the rsadsi
version) should be recognized on receipt, but that new certificates must
use sha1WithRSASignature (the OIW version).

Perhaps some of the well-rounded cert people can speak up about what is
currently out there (Peter from That Country Without Electricity?)

I apologize if this has already come up in the past.  I checked the
subjects in the (newly available!) '97 archive and didn't find anything.

Blake

Date: Wed, 6 May 1998 20:49:33 -0400
To: Trevor Freeman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: [IETF-PKIX] OCSP: Method of Identifying Certificates
Cc: [email-masked]
Sender: [email-masked]

Trevor,

The question of who "owns" a name space is important to the question of
whether ones must "trust" a CA, or whether the CA is authoritative for the
name space in which it certifies (and thus "trust" is mostly an irrelevant
concept).  Certainly a (the?) traditional X.500 view holds that CAs are
just TTPs, and other folks are the authoritative sources of names.
However, in practice, this leads to complex certification systems that are
hard to manage, hard to understand, and possibly subject to legal liability
claims.

On a different level, though, the question still remains whether we ought
to encourage people to encode Internet identifiers as DNs when we have
well-defined name forms for doing just that.

Yes, some folks have expressed support for this position on the list, but
only recently.  An approximately equal number have expressed opposition,
and most members have been silent.  We'll see how this progresses.

Steve

From: "Blake Ramsdell" <[email-masked]>
To: "'John Lowry'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Role names in certificates
Date: Wed, 6 May 1998 14:58:15 -0700
Sender: [email-masked]

> From: John Lowry [mailto:[email-masked]]
> Sent: Tuesday, May 05, 1998 8:18 AM
> To: Blake Ramsdell; [email-masked]'
> Subject: Re: Role names in certificates
> 
> 	Including a domain controller (either human or agent) is an old
> 	established concept (1988 ?) and it has value at 
> several points in 
> 	the network.  One of the most interesting is at a 
> firewall or other
> 	domain controller where one wants to control the inflow
> 	(and outflow !) of things like viruses and other nasties.
> 	Further, the entire intrusion detection community needs
> 	to consider this technique because the widespread use of IPSEC
> 	will effectively remove their ability to deploy sensors.  I know
> 	that this can imply the development of "multicast 
> IPSEC", one key for the
> 	destination host and one for the FW, but that shouldn't stop
> 	PKIX from considering role-based certificates.

I would love to hear some specifics about these concepts.  Right now I
have been thinking about the specific case where an entity is identified
by an rfc822Name.  I fully agree that communicating that "this signed
thing was signed by an entity whose job in life is to make sure there
aren't any viruses in it", etc.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: Role names in certificates
Date: Wed, 6 May 1998 14:53:11 -0700
Sender: [email-masked]

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, May 05, 1998 2:50 PM
> To: Blake Ramsdell
> Cc: [email-masked]'
> Subject: Re: Role names in certificates
> 
> 
> > I have written a draft that I have submitted as an 
> individual (not under
> > IETF-PKIX).  It describes a concept of using "role" names in
> > certificates for several purposes that are not covered with 
> conventional
> > PKIX certificates.  
> 
> I am not sure that this thread is relevant to the PKIX WG. It might be
> more relevant to the S/MIME WG.

It may end up this way -- the original intent was to profile roles for
other name types besides rfc822Name (specifically, dNSName).  If we end
up just doing rfc822Name, it might end up in S/MIME, but roles in
rfc822Name may be applicable to other profiles that use email addresses
for end-entities.  We'll see how it hammers out, and where we end up.
 
> A requirement would be the need to sign a message as the 
> Sales Director
> of the Delta Company, who may happen to be John Walker. However John
> Walker may not have a private key of its own.

I think that this may be another use of role that has different
semantics -- in my case the role was "This certificate belongs to an
entity that is signing messages on behalf of individuals at this
organization", vs. your valid example of "This certificate belongs to
the Sales Director of the Delta Company".  This may be an additional
role that we can consider.

> For the other following cases related to encryption, I wonder 
> why a role
> is needed.

They may not be.  In the event that the sending agent is an MTA and it
wants to encrypt messages to another particular MTA, I didn't know if a
special semantic should be communicated so that there was no confusion
during configuration that the certificate was suitable for MTA-to-MTA
encryption.  It may not be.

The plaintext recovery role seems useful so that the sending agent can
provide user feedback to the effect of "You are encrypting for a
certificate that is being used for message recovery.  Is that cool?"

> 1) a signature server (from a company) is able to sign documents on
> behalf of an employee with its own key and indicate the appropriate
role
> used by the employee. The employee may authenticate to that signature
> server by whatever means. In that case the signer is the company which
> indicates the role of the employee.

I think that the server vouching for the role of the employee is a
separate problem.  The first point that I was hoping to get to was an
automated agent signing all messages leaving the organization, and then
associating semantics with that.

As a separate problem, the company gateway placing a signature on the
message based on his assessment that this individual is indeed the
"CFO", "CEO", or whatever, may be interesting.

> 2) a temporary certificate issued by a server of a company includes a
> role and a temporary public key. The employee is given back the
> temporary private key so that it can sign documens directly using that
> private key.

In the particular usage that I have in mind (signing at the MTA), this
would be self-defeating -- you still have to distribute keys, educate
users, and enforce policy at the individual level.

Thanks for the comments...

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Wed, 06 May 1998 17:51:08 -0400
To: [email-masked]
From: Alan Kotok <[email-masked]>
Subject: W3C DSig plans
Cc: "Phillip M. Hallam-Baker" <[email-masked]>
Sender: [email-masked]

A recent posting to this list of Phill's was forwarded to me, with the
suggestion that I might want to comment.  Phill said:

>...
>There are alternative porposals on the table, notably the FSTC 'SDML'
>proposal and W3C's DigSig project. I suspect however that it is easier
>to promote PKCS#7/CMS since the tools already exist and the PKIX
>integration has been considered to some extent already.
>
>It is not just the question of duplicating code. The W3C plan had the
>curious idea that building on the PICS censorware base made more
>sense than building on ASN.1. this would be fine if there was not a
>large quantity of extant ASN.1 OIDS to which semantics are already
>bound.
>

The present DSig 1.0 Proposed Recommendation from W3C does, indeed, only
apply to PICS.  However we view this as just a first step to developing a
more general "signed assertion" system.  Our plan is to move on to a system
based on XML and RDF (our XML-based metadata framework).  In the Web, XML
is the syntax of choice for most all new applications.  We plan to propose
such a project in the near future.

Alan
(Acting Leader, W3C Technology and Society Domain)

___________________________________________________________________________
Alan Kotok, Associate Chairman                          mailto:[email-masked]
World Wide Web Consortium                                 http://www.w3.org
MIT Laboratory for Computer Science,  545 Technology Square,  Room NE43-409
Cambridge, MA 02139, USA     Voice: +1-617-258-5728    Fax: +1-617-258-5999

Date: Wed, 06 May 1998 11:13:25 -0700
From: Slava Galperin <[email-masked]>
Organization: Teknowledge Corporation
To: [email-masked]
CC: [email-masked]
Subject: Re: OCSP status tally
Sender: [email-masked]

Denis Pinkas wrote:
> 
> Slava,
> 
> It may happen that an OCSP responder is in charge of multiple CAs.

Proposed scheme does not preclude supporting this case.

> Without that name, you would *mandate* the use an internal index that
> will have to be the hash of the issuer public key.

Agreed. Note however, that *with the name* we will *mandate* using the
name as an internal index ;-)

> 
> This would work fine, but would mandate an implementation design. Is it
> really needed to save a few bits and thus to omit to advertise the name
> of the issuer ?

My intent was not to save on the size(although if it is possible to fit
OCSP request(and response) for the *entire* certificate chain inside a
single packet it would be real help in reducing network overhead
considering high expected number of OCSP transactions. If one dealing
with relatively long cert chains (4-5)(e.g. in cross-certification
scenarios) then using names can really reach packet fragmentation
threshold (e.g. Verisign uses about 80 bytes for the issuer name, Thawte
is about 130)). My intent was to point out that
1. instead of identifying CA by a SET of names with relatively complex
matching rules and theoretical possibility of (malitiously created ?)
name clashes we may be better off with identifying CA by a SET of public
keys with straightforward matching rule and negligible chance of
collision

2. Name part in the cert id triple (Name,KeyHash,SerialNumber) (which
most of people agree with) is somewhat redundant.

> 
> I would prefer to let the choice of the implememtation to the
> implementors.
> 

Totally agree.

Let the group collective wisdom be the judge of what works best. I was
just trying to make sure that we evaluated all the possibilities and
implications carefully.

--
Slava

From: WHenry <[email-masked]>
To: "'Todd S. Glassey'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Standards for Digitally Signed Documents - This is where time stamping shines!
Date: Wed, 6 May 1998 13:08:51 -0400 
Sender: [email-masked]

 Todd,

 Agreed! This is a big issue, especially if one were going to use digitally
signed documents in a court of law.  I can see the O.J. DNA defusion defense
at work, unless a trusted time stamp is part of the document signing
process.

 Bill Henry
 Performance Engineering Corporation
 3949 Pender Drive
 Fairfax, VA  22030
 http://www.pec.com

> -----Original Message-----
> From:	Todd S. Glassey [SMTP:[email-masked]]
> Sent:	Wednesday, May 06, 1998 12:51 PM
> To:	[email-masked]
> Cc:	Rich Ankney; WHenry
> Subject:	Re: Standards for Digitally Signed Documents - This is where
> timestamping shines!
> 
> There is a bigger picture at work here and its about making digital
> documents as robust as paper based ones. This is composed of critical
> issues
> like storage live - validity life - and non-repudiated state management of
> the documents in question. When these questions are answered we can then
> resolve the legal issues and get on with document based EC systems.
> 
> With that in mind - IMHO - the key to this process is certifiable time and
> credible time data being inextricable bound into the process and context
> models that represent the methodologies. This, the inclusion of
> certifiable
> time data, is especially critical since today NO digital instrument can be
> built that claims to be the "one and only original instance" of a digital
> instrument. Unlike the paper based process where you have a Notary Seal
> embossing the paper to create the "instrument' there is no way to tell
> which
> copy of the certificate or the record structure was actually created
> first.
> 
> Simply put, until we can do electron spin and backspin mapping for a
> signature or some other physical method of finding which instance is which
> we, will have to settle for strong authentication, policy control,  and
> notary/document storage systems.
> 
> With this in mind the current document systems are really just built
> around
> authentication of the participants and the hash created. This in and of
> itself is a important step but without the context of certified time, it
> makes the document floating in a policy context anchored to little proofs.
> Bluntly,  without Certified Time it makes the the documents of limited use
> in the commercial world.
> 
> As to the S/MIME extensions in CMS and how they relate to the document
> management features, they like virtually all the standards that have been
> proffered to date do not take into account where the time data actually
> comes from and I think that as a group we need to address this.
> 
> 
> Todd
> 
> 
> -----Original Message-----
> From: Rich Ankney <[email-masked]>
> To: WHenry <[email-masked]>; [email-masked]' <[email-masked]>
> Date: Tuesday, May 05, 1998 12:19 PM
> Subject: Re: Standards for Digitally Signed Documents
> 
> 
> >I've also been fond of PKCS #7 (IETF CMS) to store signed documents.
> >This is basically S/MIME without the MIME headers and (possibly)
> >base64 encoding.  Note that CMS allows one to store the signature
> >structure (SignedData) separately from the content.
> >
> >I know of a couple of medical records standards that use this approach.
> >
> >Regards,
> >Rich
> >----------
> >> From: WHenry <[email-masked]>
> >> To: [email-masked]'
> >> Subject: Standards for Digitally Signed Documents
> >> Date: Tuesday, May 05, 1998 1:43 PM
> >>
> >>  I hope this isn't out of the context of PKIX, but I'll ask anyway. Is
> >there
> >> an IETF WG or other that is handling standards for digitally signed
> >> documents?
> >>
> >>  There is an email/message transfer (i.e. S/MIME) standard, but there
> >don't
> >> appear to be any similar standards for storage of digitally signed
> >> documents.
> >>
> >>  I see three options:
> >>  1) use a proprietary format (e.g. Entrust or Verisign) for storing
> >> documents; in which case all who need access to the documents require
> the
> >> same public key infrastructure.
> >>  2) actually store a signed document in S/MIME format.
> >>  3) create middleware/proprietary option(s) for appending digital
> >signatures
> >> to the likes of .doc or .ppt documents.
> >>
> >>  I'd greatly appreciate any comments or thoughts on the above.
> >>
> >>  Bill Henry
> >>  Performance Engineering Corporation
> >>  3949 Pender Drive
> >>  Farifax, VA  22030
> >>  [email-masked]
> >>
> >
> >

From: "Todd S. Glassey" <[email-masked]>
To: <[email-masked]>
Cc: "Rich Ankney" <[email-masked]>, "WHenry" <[email-masked]>
Subject: Re: Standards for Digitally Signed Documents - This is where timestamping shines!
Date: Wed, 6 May 1998 09:51:00 -0700
Sender: [email-masked]

There is a bigger picture at work here and its about making digital
documents as robust as paper based ones. This is composed of critical issues
like storage live - validity life - and non-repudiated state management of
the documents in question. When these questions are answered we can then
resolve the legal issues and get on with document based EC systems.

With that in mind - IMHO - the key to this process is certifiable time and
credible time data being inextricable bound into the process and context
models that represent the methodologies. This, the inclusion of certifiable
time data, is especially critical since today NO digital instrument can be
built that claims to be the "one and only original instance" of a digital
instrument. Unlike the paper based process where you have a Notary Seal
embossing the paper to create the "instrument' there is no way to tell which
copy of the certificate or the record structure was actually created first.

Simply put, until we can do electron spin and backspin mapping for a
signature or some other physical method of finding which instance is which
we, will have to settle for strong authentication, policy control,  and
notary/document storage systems.

With this in mind the current document systems are really just built around
authentication of the participants and the hash created. This in and of
itself is a important step but without the context of certified time, it
makes the document floating in a policy context anchored to little proofs.
Bluntly,  without Certified Time it makes the the documents of limited use
in the commercial world.

As to the S/MIME extensions in CMS and how they relate to the document
management features, they like virtually all the standards that have been
proffered to date do not take into account where the time data actually
comes from and I think that as a group we need to address this.

Todd

-----Original Message-----
From: Rich Ankney <[email-masked]>
To: WHenry <[email-masked]>; [email-masked]' <[email-masked]>
Date: Tuesday, May 05, 1998 12:19 PM
Subject: Re: Standards for Digitally Signed Documents

>I've also been fond of PKCS #7 (IETF CMS) to store signed documents.
>This is basically S/MIME without the MIME headers and (possibly)
>base64 encoding.  Note that CMS allows one to store the signature
>structure (SignedData) separately from the content.
>
>I know of a couple of medical records standards that use this approach.
>
>Regards,
>Rich
>----------
>> From: WHenry <[email-masked]>
>> To: [email-masked]'
>> Subject: Standards for Digitally Signed Documents
>> Date: Tuesday, May 05, 1998 1:43 PM
>>
>>  I hope this isn't out of the context of PKIX, but I'll ask anyway. Is
>there
>> an IETF WG or other that is handling standards for digitally signed
>> documents?
>>
>>  There is an email/message transfer (i.e. S/MIME) standard, but there
>don't
>> appear to be any similar standards for storage of digitally signed
>> documents.
>>
>>  I see three options:
>>  1) use a proprietary format (e.g. Entrust or Verisign) for storing
>> documents; in which case all who need access to the documents require the
>> same public key infrastructure.
>>  2) actually store a signed document in S/MIME format.
>>  3) create middleware/proprietary option(s) for appending digital
>signatures
>> to the likes of .doc or .ppt documents.
>>
>>  I'd greatly appreciate any comments or thoughts on the above.
>>
>>  Bill Henry
>>  Performance Engineering Corporation
>>  3949 Pender Drive
>>  Farifax, VA  22030
>>  [email-masked]
>>
>
>

From: "Phillip M. Hallam-Baker" <[email-masked]>
To: "Miklos, Sue A." <[email-masked]>, <[email-masked]>, "'WHenry'" <[email-masked]>
Subject: Re: Standards for Digitally Signed Documents
Date: Wed, 6 May 1998 11:51:40 -0400
Sender: [email-masked]

>May I suggest that those interested put together the appropriate request
>for a BOF at the Chicago IETF?

I would see the first step to be setting up a mailing list. The purpose of
a BOF is mainly to devise a group charter and define some schedule
for deliverables with a view to being approved by the IESG.

While I see PKCS#7 aka CMS as being the principle vehicle the IETF
should consider as a basis for this work  there are certainly issues that
have to be considered.

There are alternative porposals on the table, notably the FSTC 'SDML'
proposal and W3C's DigSig project. I suspect however that it is easier
to promote PKCS#7/CMS since the tools already exist and the PKIX
integration has been considered to some extent already.

It is not just the question of duplicating code. The W3C plan had the
curious idea that building on the PICS censorware base made more
sense than building on ASN.1. this would be fine if there was not a
large quantity of extant ASN.1 OIDS to which semantics are already
bound.

Perhaps another useful work item for such a group would be defining
a URI form of an ASN.1 OID. e.g. OID label followed by the attribute
in Base64 - ASN1:1.23.345.23:;l2i3u490ur9340u34==

Such an OID form would provide a powerful means of importing
semantics attached to ASN.1 OIDs into HTML and XML documents.
It would also be useful to define an OID to import URI semantics.

I would see XML inside CMS as being a key technology to be addressed.
What separation of concerns is appropriate? What information should
be in the object sighed, what information should be in the signature
wrapper.

Also to be addressed are issues such as the semantics of such signatures.
If messages are to be passed from computer to computer it is important
that a signing unit be protected from being fooled into signing something
that has a different meaning in another context.

It would also be appropriate for such a group to look at the question of
revocation of document signatures. This is no less necessary than
the revocation of compromised key certificates. For example a company
might announce a tender in a document, once a bidder was approved
however it could well be convenient to revoke the tender document.
Similarly a company might well want the ability to recall documents which
were fradulently obtained.

A better example might be a bank which would want to revoke a
letter of credit because the party that requested it is bankrupt.

In summary I think there is plenty of usefull work such a group could
do which would build on the PKIX base and further refine the notions
of what it means to sign documents with public keys. While the
technology approach is at this stage relatively straightforward
there are a lot of details to work out.

Whether such a group could make a worthwhile contribution would
of course depend on its ability to obtain industry buy in.

            Phill

From: Graham Bland <[email-masked]>
Date: Wed, 6 May 1998 15:38:26 +0000
To: [email-masked]
Subject: RE: Standards for Digitally Signed Docum
Sender: [email-masked]

This could be considered within the context of an IDUP-GSS mechanism

Graham
 ----------
From: samiklo@missi=2Encsc=2Emil
To: ietf-pkix@imc=2Eorg; WHenry@pec=2Ecom
Subject: RE: Standards for Digitally Signed Docum
Date: Wednesday, 06 May, 1998 3:28PM

May I suggest that those interested put together the appropriate request
for a BOF at the Chicago IETF?

Sandi

>----------
>From:    WHenry[SMTP:WHenry@pec=2Ecom]
>Sent:    Tuesday, May 05, 1998 1:43 PM
>To:      'ietf-pkix@imc=2Eorg'
>Subject:      Standards for Digitally Signed Documents
>
> I hope this isn't out of the context of PKIX, but I'll ask anyway=2E Is=20
there
>an IETF WG or other that is handling standards for digitally signed
>documents?
>
> There is an email/message transfer (i=2Ee=2E S/MIME) standard, but there=20=
don't
>appear to be any similar standards for storage of digitally signed
>documents=2E
>
> I see three options:
> 1) use a proprietary format (e=2Eg=2E Entrust or Verisign) for storing
>documents; in which case all who need access to the documents require the
>same public key infrastructure=2E
> 2) actually store a signed document in S/MIME format=2E
> 3) create middleware/proprietary option(s) for appending digital=20
signatures
>to the likes of =2Edoc or =2Eppt documents=2E
>
> I'd greatly appreciate any comments or thoughts on the above=2E
>
> Bill Henry
> Performance Engineering Corporation
> 3949 Pender Drive
> Farifax, VA  22030
> whenry@pec=2Ecom
>
>
>
>> -----Original Message-----
>> From:  Miklos, Sue A=2E [SMTP:samiklo@missi=2Encsc=2Emil]
>> Sent:  Tuesday, May 05, 1998 9:30 AM
>> To:    'Blake Ramsdell'; 'Denis=2EPinkas@bull=2Enet'
>> Cc:    'ietf-pkix@imc=2Eorg'
>> Subject:    RE: Role names in certificates
>>
>> I'm somewhat confused=2E  I had thought that certificates and roles coul=
d
>> be used in a variety of contexts (applications) for, among other things,
>> access control=2E  Therefore this would appear to extend beyond just the
>> S/MIME messaging context=2E  Is this of interest to the LDAP access
>> controls?  Is this useful for the web-based document retrieval
>> environments?
>>
>> Sandi Miklos
>>
>>
>> >----------
>> >From:      Denis Pinkas[SMTP:Denis=2EPinkas@bull=2Enet]
>> >Sent:      Tuesday, May 05, 1998 5:49 PM
>> >To:   Blake Ramsdell
>> >Cc:   'ietf-pkix@imc=2Eorg'
>> >Subject:   Re: Role names in certificates
>> >
>> >> I have written a draft that I have submitted as an individual (not
>> under
>> >> IETF-PKIX)=2E  It describes a concept of using "role" names in
>> >> certificates for several purposes that are not covered with
>> conventional
>> >> PKIX certificates=2E
>> >
>> >I am not sure that this thread is relevant to the PKIX WG=2E It might b=
e
>> >more relevant to the S/MIME WG=2E
>> >
>> >> I have currently profiled the rfc822Name choice, but
>> >> I have heard that there is interesting in profiling the dNSName choic=
e
>> >> also=2E  Cutting and pasting a little bit from the document, roles ar=
e
>> >> defined for:
>> >>
>> >> * The need to sign messages on behalf of people at a domain that may=20
or
>> >> may not have signature services available at the desktop=2E An outbou=
nd
>> >> message from a domain may be sent that is signed at the domain mail
>> >> server=2E
>> >
>> >A requirement would be the need to sign a message as the Sales Director
>> >of the Delta Company, who may happen to be John Walker=2E However John
>> >Walker may not have a private key of its own=2E
>> >
>> >> * The need to encrypt messages for people at a domain that may not=20
have
>> >> encryption services available at the desktop=2E A message may be
>> encrypted
>> >> for the domain mail server using a domain encrypting certificate, and
>> >> that message will be decrypted before local delivery=2E
>> >
>> >For the other following cases related to encryption, I wonder why a rol=
e
>> >is needed=2E
>> >
>> >> * The need to encrypt messages between two mail transfer agents=20
(MTAs)=2E
>> >> This is different than a domain encrypting certificate, in that the
>> >> message is never encrypted or decrypted at the mail user agent (MUA)
>> >> level=2E
>> >>
>> >> * The need to encrypt messages for a keypair that is controlled by th=
e
>> >> domain administrator for the purposes of plaintext access=2E A messag=
e
>> may
>> >> be encrypted for the domain mail server using a domain message=20
recovery
>> >> encryption certificate for the purpose of selective plaintext recover=
y
>> >> by the domain administrator=2E This differs from a domain encrypting
>> >> certificate in that the message is not necessarily decrypted before
>> >> local delivery=2E
>> >>
>> >> I know that the last one is going to be controversial, and this is no=
t
>> >> an all-or-nothing proposal (you can simply not implement it)=2E  Plea=
se
>> >> don't flame me for daring to speak its evil name, but keep an open=20
mind
>> >> for the other uses I have listed=2E
>> >
>> >> This is meant to get the ball rolling in a direction where we think
>> >> about PKIX representing entities that are not necessarily a specific
>> >> end-entity, but an end-entity with a particular role or=20
responsibility=2E
>> >
>> >This is the point=2E
>> >
>> >> Any insight welcome as to how to address these issues in an=20
alternative
>> >> way=2E
>> >
>> >> http://www=2Edeming=2Ecom/users/blaker/draft-ramsdell-role-names is a=
lways
>> >> the latest version
>> >> http://www=2Eietf=2Eorg/internet-drafts/draft-ramsdell-role-names-00=2E=
txt=20
is
>> >> the current draft at the IETF=2E
>> >>
>> >> Now where's my suit=2E=2E=2E
>> >
>> >There are several ways to address this issue=2E Among them:
>> >
>> >1) a signature server (from a company) is able to sign documents on
>> >behalf of an employee with its own key and indicate the appropriate rol=
e
>> >used by the employee=2E The employee may authenticate to that signature
>> >server by whatever means=2E In that case the signer is the company whic=
h
>> >indicates the role of the employee=2E
>> >
>> >2) a temporary certificate issued by a server of a company includes a
>> >role and a temporary public key=2E The employee is given back the
>> >temporary private key so that it can sign documens directly using that
>> >private key=2E
>> >
>> >If we would like to support such scheme(s), some arrangements would nee=
d
>> >to be done to the S/MIME specifications, so I would propose to shift
>> >this thread to the S/MIME WG=2E
>> >
>> >Denis
>> >
>> >> Blake
>> >> --
>> >> Blake C=2E Ramsdell
>> >> Worldtalk Corporation
>> >> For current info, check http://www=2Edeming=2Ecom/users/blaker
>> >> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>> >
>> >--
>> >      Denis Pinkas     Bull S=2EA=2E          mailto:Denis=2EPinkas@bul=
l=2Enet
>> >      Rue Jean Jaures  B=2EP=2E 68            Phone : 33 - 1 30 80 34 8=
7
>> >      78340 Les Clayes sous Bois=2E FRANCE   Fax  : 33 - 1 30 80 33 21
>> >
>

--
Zergo Limited, The Square, Basing View, Basingstoke, Hants=2E RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www=2Ezergo=2Ecom

Date: Tue, 05 May 1998 11:18:03 -0400
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: John Lowry <[email-masked]>
Subject: Re: Role names in certificates
Sender: [email-masked]

Blake,

	Including a domain controller (either human or agent) is an old
	established concept (1988 ?) and it has value at several points in 
	the network.  One of the most interesting is at a firewall or other
	domain controller where one wants to control the inflow
	(and outflow !) of things like viruses and other nasties.
	Further, the entire intrusion detection community needs
	to consider this technique because the widespread use of IPSEC
	will effectively remove their ability to deploy sensors.  I know
	that this can imply the development of "multicast IPSEC", one key for the
	destination host and one for the FW, but that shouldn't stop
	PKIX from considering role-based certificates.

	Consequently, I encourage you to expand your concept to
	domain controllers at any layer, not just email or messaging.

Regards,

John

At 02:23 PM 5/4/98 -0700, Blake Ramsdell wrote:
>I have written a draft that I have submitted as an individual (not under
>IETF-PKIX).  It describes a concept of using "role" names in
>certificates for several purposes that are not covered with conventional
>PKIX certificates.  I have currently profiled the rfc822Name choice, but
>I have heard that there is interesting in profiling the dNSName choice
>also.  Cutting and pasting a little bit from the document, roles are
>defined for:
>
>* The need to sign messages on behalf of people at a domain that may or
>may not have signature services available at the desktop. An outbound
>message from a domain may be sent that is signed at the domain mail
>server.
>
>* The need to encrypt messages for people at a domain that may not have
>encryption services available at the desktop. A message may be encrypted
>for the domain mail server using a domain encrypting certificate, and
>that message will be decrypted before local delivery.
>
>* The need to encrypt messages between two mail transfer agents (MTAs).
>This is different than a domain encrypting certificate, in that the
>message is never encrypted or decrypted at the mail user agent (MUA)
>level.
>
>* The need to encrypt messages for a keypair that is controlled by the
>domain administrator for the purposes of plaintext access. A message may
>be encrypted for the domain mail server using a domain message recovery
>encryption certificate for the purpose of selective plaintext recovery
>by the domain administrator. This differs from a domain encrypting
>certificate in that the message is not necessarily decrypted before
>local delivery.
>
>I know that the last one is going to be controversial, and this is not
>an all-or-nothing proposal (you can simply not implement it).  Please
>don't flame me for daring to speak its evil name, but keep an open mind
>for the other uses I have listed.
>
>This is meant to get the ball rolling in a direction where we think
>about PKIX representing entities that are not necessarily a specific
>end-entity, but an end-entity with a particular role or responsibility.
>Any insight welcome as to how to address these issues in an alternative
>way.
>
>http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
>the latest version
>http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
>the current draft at the IETF.
>
>Now where's my suit...
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

From: "Miklos, Sue A." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'WHenry'" <[email-masked]>
Subject: RE: Standards for Digitally Signed Documents
Date: Wed, 6 May 1998 08:39:58 -0400
Sender: [email-masked]

May I suggest that those interested put together the appropriate request
for a BOF at the Chicago IETF?  

Sandi

>----------
>From: 	WHenry[SMTP:[email-masked]]
>Sent: 	Tuesday, May 05, 1998 1:43 PM
>To: 	[email-masked]'
>Subject: 	Standards for Digitally Signed Documents
>
> I hope this isn't out of the context of PKIX, but I'll ask anyway. Is there
>an IETF WG or other that is handling standards for digitally signed
>documents?
>
> There is an email/message transfer (i.e. S/MIME) standard, but there don't
>appear to be any similar standards for storage of digitally signed
>documents.
>
> I see three options:
> 1) use a proprietary format (e.g. Entrust or Verisign) for storing
>documents; in which case all who need access to the documents require the
>same public key infrastructure.
> 2) actually store a signed document in S/MIME format.
> 3) create middleware/proprietary option(s) for appending digital signatures
>to the likes of .doc or .ppt documents.
>
> I'd greatly appreciate any comments or thoughts on the above.
>
> Bill Henry
> Performance Engineering Corporation
> 3949 Pender Drive
> Farifax, VA  22030
> [email-masked]
>
> 
>
>> -----Original Message-----
>> From:	Miklos, Sue A. [SMTP:[email-masked]]
>> Sent:	Tuesday, May 05, 1998 9:30 AM
>> To:	'Blake Ramsdell'; [email-masked]'
>> Cc:	[email-masked]'
>> Subject:	RE: Role names in certificates
>> 
>> I'm somewhat confused.  I had thought that certificates and roles could
>> be used in a variety of contexts (applications) for, among other things,
>> access control.  Therefore this would appear to extend beyond just the
>> S/MIME messaging context.  Is this of interest to the LDAP access
>> controls?  Is this useful for the web-based document retrieval
>> environments?  
>> 
>> Sandi Miklos
>> 
>> 
>> >----------
>> >From: 	Denis Pinkas[SMTP:[email-masked]]
>> >Sent: 	Tuesday, May 05, 1998 5:49 PM
>> >To: 	Blake Ramsdell
>> >Cc: 	[email-masked]'
>> >Subject: 	Re: Role names in certificates
>> >
>> >> I have written a draft that I have submitted as an individual (not
>> under
>> >> IETF-PKIX).  It describes a concept of using "role" names in
>> >> certificates for several purposes that are not covered with
>> conventional
>> >> PKIX certificates.  
>> >
>> >I am not sure that this thread is relevant to the PKIX WG. It might be
>> >more relevant to the S/MIME WG.
>> >
>> >> I have currently profiled the rfc822Name choice, but
>> >> I have heard that there is interesting in profiling the dNSName choice
>> >> also.  Cutting and pasting a little bit from the document, roles are
>> >> defined for:
>> >> 
>> >> * The need to sign messages on behalf of people at a domain that may or
>> >> may not have signature services available at the desktop. An outbound
>> >> message from a domain may be sent that is signed at the domain mail
>> >> server.
>> >
>> >A requirement would be the need to sign a message as the Sales Director
>> >of the Delta Company, who may happen to be John Walker. However John
>> >Walker may not have a private key of its own.
>> > 
>> >> * The need to encrypt messages for people at a domain that may not have
>> >> encryption services available at the desktop. A message may be
>> encrypted
>> >> for the domain mail server using a domain encrypting certificate, and
>> >> that message will be decrypted before local delivery.
>> >
>> >For the other following cases related to encryption, I wonder why a role
>> >is needed.
>> > 
>> >> * The need to encrypt messages between two mail transfer agents (MTAs).
>> >> This is different than a domain encrypting certificate, in that the
>> >> message is never encrypted or decrypted at the mail user agent (MUA)
>> >> level.
>> >> 
>> >> * The need to encrypt messages for a keypair that is controlled by the
>> >> domain administrator for the purposes of plaintext access. A message
>> may
>> >> be encrypted for the domain mail server using a domain message recovery
>> >> encryption certificate for the purpose of selective plaintext recovery
>> >> by the domain administrator. This differs from a domain encrypting
>> >> certificate in that the message is not necessarily decrypted before
>> >> local delivery.
>> >> 
>> >> I know that the last one is going to be controversial, and this is not
>> >> an all-or-nothing proposal (you can simply not implement it).  Please
>> >> don't flame me for daring to speak its evil name, but keep an open mind
>> >> for the other uses I have listed.
>> >
>> >> This is meant to get the ball rolling in a direction where we think
>> >> about PKIX representing entities that are not necessarily a specific
>> >> end-entity, but an end-entity with a particular role or responsibility.
>> >
>> >This is the point.
>> >
>> >> Any insight welcome as to how to address these issues in an alternative
>> >> way.
>> > 
>> >> http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
>> >> the latest version
>> >> http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
>> >> the current draft at the IETF.
>> >> 
>> >> Now where's my suit...
>> >
>> >There are several ways to address this issue. Among them: 
>> >
>> >1) a signature server (from a company) is able to sign documents on
>> >behalf of an employee with its own key and indicate the appropriate role
>> >used by the employee. The employee may authenticate to that signature
>> >server by whatever means. In that case the signer is the company which
>> >indicates the role of the employee.
>> >
>> >2) a temporary certificate issued by a server of a company includes a
>> >role and a temporary public key. The employee is given back the
>> >temporary private key so that it can sign documens directly using that
>> >private key.
>> >
>> >If we would like to support such scheme(s), some arrangements would need
>> >to be done to the S/MIME specifications, so I would propose to shift
>> >this thread to the S/MIME WG.
>> >
>> >Denis
>> > 
>> >> Blake
>> >> --
>> >> Blake C. Ramsdell
>> >> Worldtalk Corporation
>> >> For current info, check http://www.deming.com/users/blaker
>> >> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>> >
>> >-- 
>> >      Denis Pinkas     Bull S.A.          mailto:[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: Mon, 4 May 1998 18:28:39 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Cc: [email-masked]
Sender: [email-masked]

Peter,

>Subject field should contain anything you want. It is questionable
>whether one should impose any restriction on subjects. The CA
>(or the associated RA or naming authority) publishes its naming
>plan anyway (or should plan it), otherwise it would be somewhat
>difficult to interprete the content of the subject naming fields.
>All X.509v3 should be allowed (not necessarily new extensions
>with almost private oids)
>
>A CA can decide to use DN or other naming extension
>in whatever weird way as long as internal the names are ok and
>permit (to them) to find the individual etc, and to issue new
>certs for the same individual.
>
>Restrictions of issuer names and subject names may be the only
>way to organise a conspiracy of cooperating CAs, in whatever
>cross-certification environment you might imagine. Are we (who
>ever this might be?) in this context?

We want interoperability in general, although closed PKIs certainly shoulkd
be accommodated too.  We have a variety of name forms defined and certs
have to match one of those, so it's not a completely general space we're
dealing with.  My comments focus on representing names that already exist
in the Internet. Names for which we have authorutative registrars, and for
which we have a defined, native representation in X.509v3.  Yes,
cross-certification is a motivation for adopting appropriate conventions
for name use.

>The problem is not really the naming in the certs,
>the problem are applications (IMHO). It seems that one tries
>to solve a hen and egg problem by first creating a global
>unique naming structure for everything and everybody (big brother,
>please leave me alone that), and then of course this automagically
>solves many addressing and naming problems in applications,
>finding CAs, subjects and so on.

For the names in question, e.g., DNS names and IP addresses, we already DO
have global, unique name structures and folks who administer them.

>Reality might be different: the banking environment gives me a cert,
>THEY choose their naming convention, the administration who wants
>me to sign tax declarations will give me a cert. THEY choose THEIR
>naming convention, my electronic passport cert (bar or ocr coded
>on a real passport :-) ) again has its own naming conventions.

The SET standards already define conevntions for the X.509 certs issued to
credit card folks, and for U.S. taxpayers, the social security numbner
(combined with a CN) is the name form.  So, we already have answers for two
examples you cite.  I bet someone, somewhere in the EC is working on the
passport issue as we speak ;-)!

Steve

Date: Mon, 4 May 1998 18:20:33 -0400
To: [email-masked] (David P. Kemp)
From: Stephen Kent <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Cc: [email-masked]
Sender: [email-masked]

David,

>
>The question in my mind remains "can X.509 be used outside the context
>of the X.500 directory?".  Or, does the IETF, which defines the syntax
>of Name, RDNSequence, and RelativeDistinguishedName in PKIX Part 1,
>somehow have a sub-rosa importation of the semantics of Directory
>(or Distinguished) Names from X.500, including a requirement to use
>the ITU as a registrar?
>
>Note that Part 1 defines DistinguishedName ::= RDNSequence,
>but DistinguishedName is *never* used.  The subject and issuer
>fields of Certificate are Name, not DistinguishedName.  The syntax
>is the same, but the argument can be made that the IETF has the right
>to define its own attributes which may appear in RDNSequence, and
>to serve as the registrar for it's own namespaces.

For backward compatibility with v1 and v2 certs, Name is a DN, imported
from X.500 (even if we don't say so explicitly in the text).  Otherwise we
would substitute GeneralName and not have AltNames.  Since ITU is not
acting as a registrar, your comment above does not seem germane to our
discussion.

>I would put forth the claim that a Name which began with "C=" would be
>registered under the ITU, a Name which began with "DC=" would be
>registered under the IETF, and a Name which began with a private
>attribute "FOO=" would be registered under the organization which owns
>the attribute's OID.

Well, it's not that easy, though I appreciate your point.  A name that
begins with O (organizatoion) is also consistent with the X.500 DIT model,
e.g., for the United Nations, the ICRC, etc.  The notion that the first RDN
defines a name space is definately not consistent with the X.500 model,
although I appreciate the apparent attraction.  After all, ifthey
envisioned that approach, why define AltNames?

Also, in practice, folks have used a wide variety of DNs in certs, in part
because we have no formal, binding schema, as I noted previously.  Still, I
could interpret your suggestion to be that if a DN consisted of all DC
attributes (and matching values), then there would be no ambiguity and one
could establish a convention in the IETF sphere of influence to consider
such DNs as equivalent to an AltName of the DNS form, right?

Well, I guess one might pursue that path.  Is the major benefit of having
these DNS names in sheeps (I mean DN) clothing, to facilitate lookup in
LDAP servers?  Given the availability of AltNames, we don't want to
encourage this hack as an alternative to use of those constructs.  Also, we
will now find ourselves with two supposedly equivalent ways of representing
the same name, which would further complicate the matching problems we've
already been discussing just due to the various string representations in
DNs.  Also, this approach doesn't address what I assume is the major legacy
problem we are facing now.  Many of the legacy examples we see are hybrid
names that look like DNs, but just happen to end with a CN that is a DNS
name (c.f. ALL SSL server certificate Subject names).

So, before considering your suggestionn further, I'd like to see a more
complete analysis of what problems we are solving and what new problems we
are creating, to better understand the tradeoffs.

Steve

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Usage of Diffe-Hellman keys
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Date: Wed, 6 May 1998 16:20:37 (NZST)
Sender: [email-masked]

>Trying to put this into S/MIME context it seems that Diffie-Hellman keys may
>only be used in the way suggested by Russ Housley, i.e. for each recipient to
>take recipient's Diffie-Hellman certificate (key agreement certificate), get
>the public key from there, generate a shared key (Russ suggested 3DES) and use
>it to encrypt the content-encryption key.
>
>However, another possibility is to use El-Gamal algorithm with Diffie-Hellman
>keys and encrypt the content-encryption key directly with recipients
>Diffie-Hellman public key. This would be a very similar operation as if the
>recipient had RSA keys and keyEnchipherment certificate. This seems to be a
>much better way of using Diffie-Hellman keys, similar to the way RSA keys are
>used for keys encryption (unless I have missed some point here).
 
If you use the key this way then it's no longer DH but Elgamal, with its own 
algorithm/object identifiers and usage requirements.  For example some 
generators which are OK for Elgamal encryption aren't secure for Elgamal 
signatures, so if you've got DH-pretending-to-be-Elgamal (which PGP does, for 
example) you can't just use it as if it were Elgamal.  If you want to use a 
key for Elgamal encryption/signatures, you should really call it Elgamal, and 
not take a DH key and use it for something it was never designed for.
 
(If you want to get really nitpicky, there are actually three different 
 algorithms which use keys which look more or less the same: DH (key 
 exchange), Elgamal encryption == DH-Vernam encryption (encryption), and 
 Elgamal signatures (signature).  It'd be nicer to actually call it Elgamal
 rather than overload DH further and further)
 
Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Cc: [email-masked]
Reply-To: [email-masked]
Date: Wed, 6 May 1998 16:12:53 (NZST)
Sender: [email-masked]

>RFC2247 names are perfectly valid X.500 names, and as there are no 
>restrictions on the attribute types used within Name objects in the PKIX-1 
>spec, there should be no problem with putting them into the Subject or Issuer 
>fields of PKIX certificates.  But I agree that it would be good if the PKIX 
>documents were to explicitly recommend the use of the RFC2247 'DC' attribute 
>type to represent names from the DNS namespace, for situations where a key is 
>owned by some entity identified by a DNS name.  This might prevent someone 
>from inventing a different way to represent DNS names.
 
As several others have already pointed out, there's already a perfectly valid 
way of specifying a DNS name to identify a certificate, namely the dNSName 
component of the altName.  Why the insistence on stuffing DNS names into 
something which was never intended for this purpose?  There's no need to 
invent anything new, or misuse an existing mechanism, because DNS names are 
already handled.
 
Peter.

From: Trevor Freeman <[email-masked]>
To: [email-masked]
Subject: RE: [IETF-PKIX] OCSP: Method of Identifying Certificates
Date: Tue, 5 May 1998 17:23:02 -0700 
Sender: [email-masked]

Steve,
I see little to justify exclusion of RFC2247 names in your comments. This is
not a turf war of who's name space is it. What does it matter who "owns" the
name space. What matters is do we want to use RFC2247 to generate RDN's for
pkix. It sound to me if a number of people see value in doing so.
Trevor

From: =?ISO-8859-1?Q?H=E4ger=F6=2C_Per?= <[email-masked]>
To: "'WHenry'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: SV: Standards for Digitally Signed Documents
Date: Tue, 5 May 1998 23:28:42 +0200 
Sender: [email-masked]

Hi !

I=B4d say that PKCS7 is what your looking for.

-------------------------------------------
Med V=E4nlig H=E4lsning / Best Regards
Per H=E4ger=F6
Senior Consultant & Product Manager
WM-data
Tel +46 8 7758204 | Fax +46 8 7758322=20
E-post: [email-masked]
------------------------------------------------------------------------=
----
---

> -----Ursprungligt meddelande-----
> Fr=E5n:	WHenry [SMTP:[email-masked]]
> Skickat:	 den 5 maj 1998 19:44
> Till:	[email-masked]'
> =C4mne:	Standards for Digitally Signed Documents
>=20
>  I hope this isn't out of the context of PKIX, but I'll ask anyway. =
Is
> there
> an IETF WG or other that is handling standards for digitally signed
> documents?
>=20
>  There is an email/message transfer (i.e. S/MIME) standard, but there
> don't
> appear to be any similar standards for storage of digitally signed
> documents.
>=20
>  I see three options:
>  1) use a proprietary format (e.g. Entrust or Verisign) for storing
> documents; in which case all who need access to the documents require =
the
> same public key infrastructure.
>  2) actually store a signed document in S/MIME format.
>  3) create middleware/proprietary option(s) for appending digital
> signatures
> to the likes of .doc or .ppt documents.
>=20
>  I'd greatly appreciate any comments or thoughts on the above.
>=20
>  Bill Henry
>  Performance Engineering Corporation
>  3949 Pender Drive
>  Farifax, VA  22030
>  [email-masked]
>=20
> =20
>=20
> > -----Original Message-----
> > From:	Miklos, Sue A. [SMTP:[email-masked]]
> > Sent:	Tuesday, May 05, 1998 9:30 AM
> > To:	'Blake Ramsdell'; [email-masked]'
> > Cc:	[email-masked]'
> > Subject:	RE: Role names in certificates
> >=20
> > I'm somewhat confused.  I had thought that certificates and roles =
could
> > be used in a variety of contexts (applications) for, among other =
things,
> > access control.  Therefore this would appear to extend beyond just =
the
> > S/MIME messaging context.  Is this of interest to the LDAP access
> > controls?  Is this useful for the web-based document retrieval
> > environments? =20
> >=20
> > Sandi Miklos
> >=20
> >=20
> > >----------
> > >From: 	Denis Pinkas[SMTP:[email-masked]]
> > >Sent: 	Tuesday, May 05, 1998 5:49 PM
> > >To: 	Blake Ramsdell
> > >Cc: 	[email-masked]'
> > >Subject: 	Re: Role names in certificates
> > >
> > >> I have written a draft that I have submitted as an individual =
(not
> > under
> > >> IETF-PKIX).  It describes a concept of using "role" names in
> > >> certificates for several purposes that are not covered with
> > conventional
> > >> PKIX certificates. =20
> > >
> > >I am not sure that this thread is relevant to the PKIX WG. It =
might be
> > >more relevant to the S/MIME WG.
> > >
> > >> I have currently profiled the rfc822Name choice, but
> > >> I have heard that there is interesting in profiling the dNSName
> choice
> > >> also.  Cutting and pasting a little bit from the document, roles =
are
> > >> defined for:
> > >>=20
> > >> * The need to sign messages on behalf of people at a domain that =
may
> or
> > >> may not have signature services available at the desktop. An =
outbound
> > >> message from a domain may be sent that is signed at the domain =
mail
> > >> server.
> > >
> > >A requirement would be the need to sign a message as the Sales =
Director
> > >of the Delta Company, who may happen to be John Walker. However =
John
> > >Walker may not have a private key of its own.
> > >=20
> > >> * The need to encrypt messages for people at a domain that may =
not
> have
> > >> encryption services available at the desktop. A message may be
> > encrypted
> > >> for the domain mail server using a domain encrypting =
certificate, and
> > >> that message will be decrypted before local delivery.
> > >
> > >For the other following cases related to encryption, I wonder why =
a
> role
> > >is needed.
> > >=20
> > >> * The need to encrypt messages between two mail transfer agents
> (MTAs).
> > >> This is different than a domain encrypting certificate, in that =
the
> > >> message is never encrypted or decrypted at the mail user agent =
(MUA)
> > >> level.
> > >>=20
> > >> * The need to encrypt messages for a keypair that is controlled =
by
> the
> > >> domain administrator for the purposes of plaintext access. A =
message
> > may
> > >> be encrypted for the domain mail server using a domain message
> recovery
> > >> encryption certificate for the purpose of selective plaintext
> recovery
> > >> by the domain administrator. This differs from a domain =
encrypting
> > >> certificate in that the message is not necessarily decrypted =
before
> > >> local delivery.
> > >>=20
> > >> I know that the last one is going to be controversial, and this =
is
> not
> > >> an all-or-nothing proposal (you can simply not implement it).  =
Please
> > >> don't flame me for daring to speak its evil name, but keep an =
open
> mind
> > >> for the other uses I have listed.
> > >
> > >> This is meant to get the ball rolling in a direction where we =
think
> > >> about PKIX representing entities that are not necessarily a =
specific
> > >> end-entity, but an end-entity with a particular role or
> responsibility.
> > >
> > >This is the point.
> > >
> > >> Any insight welcome as to how to address these issues in an
> alternative
> > >> way.
> > >=20
> > >> http://www.deming.com/users/blaker/draft-ramsdell-role-names is
> always
> > >> the latest version
> > >> =
http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt
> is
> > >> the current draft at the IETF.
> > >>=20
> > >> Now where's my suit...
> > >
> > >There are several ways to address this issue. Among them:=20
> > >
> > >1) a signature server (from a company) is able to sign documents =
on
> > >behalf of an employee with its own key and indicate the =
appropriate
> role
> > >used by the employee. The employee may authenticate to that =
signature
> > >server by whatever means. In that case the signer is the company =
which
> > >indicates the role of the employee.
> > >
> > >2) a temporary certificate issued by a server of a company =
includes a
> > >role and a temporary public key. The employee is given back the
> > >temporary private key so that it can sign documens directly using =
that
> > >private key.
> > >
> > >If we would like to support such scheme(s), some arrangements =
would
> need
> > >to be done to the S/MIME specifications, so I would propose to =
shift
> > >this thread to the S/MIME WG.
> > >
> > >Denis
> > >=20
> > >> Blake
> > >> --
> > >> Blake C. Ramsdell
> > >> Worldtalk Corporation
> > >> For current info, check http://www.deming.com/users/blaker
> > >> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
> > >
> > >--=20
> > >      Denis Pinkas     Bull S.A.          =
mailto:[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
> > >

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "WHenry" <[email-masked]>, <[email-masked]>
Subject: Re: Standards for Digitally Signed Documents
Date: Tue, 5 May 1998 16:48:57 -0400
Sender: [email-masked]

> I see three options:
> 1) use a proprietary format (e.g. Entrust or Verisign) for storing
>documents; in which case all who need access to the documents require the
>same public key infrastructure.

I'm not aware of any proprietary VeriSign document storage format.
I strongly approve of the idea of using PKCS#7 aka CMS for this
purpose however.

The detached signature block technique is particularly powerful
in combination with S/MIME. An S/MIME message might be
placed in a document repository with the content placed in one
vault and the signature in another. If necessary the S/MIME 
message can always be reassembled.

        Phill

Date: Tue, 05 May 1998 22:22:12 +0200
To: WHenry <[email-masked]>, "[email-masked]'" <[email-masked]>
From: "Patrik Nilsson" <[email-masked]>
Subject: Re: Standards for Digitally Signed Documents
Sender: [email-masked]

At 01:43 PM 98-05-05 -0400, WHenry wrote:
> I hope this isn't out of the context of PKIX, but I'll ask anyway. Is there
>an IETF WG or other that is handling standards for digitally signed
>documents?
>
> There is an email/message transfer (i.e. S/MIME) standard, but there don't
>appear to be any similar standards for storage of digitally signed
>documents.
>
> I see three options:
> 1) use a proprietary format (e.g. Entrust or Verisign) for storing
>documents; in which case all who need access to the documents require the
>same public key infrastructure.
> 2) actually store a signed document in S/MIME format.
> 3) create middleware/proprietary option(s) for appending digital signatures
>to the likes of .doc or .ppt documents.
>
> I'd greatly appreciate any comments or thoughts on the above.

I think that separating Cryptographic Message Syntax (CMS) into a separate
document, independent of the email specific parts of the S/MIME standards,
was an effort to address these kind of needs.

>From ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-04.txt
- - - - - - - - - - - - 
1  Introduction

   This document describes the Cryptographic Message Syntax.  This
   syntax is used to digitally sign or encrypt arbitrary messages.

   The Cryptographic Message Syntax describes an encapsulation syntax
   for data protection.  It supports digital signatures and encryption.
   The syntax allows multiple encapsulation, so one encapsulation
   envelope can be nested inside another.  Likewise, one party can
   digitally sign some previously encapsulated data.  It also allows
   arbitrary attributes, such as signing time, to be authenticated along
   with the message content, and provides for other attributes such as
   countersignatures to be associated with a signature.

   The Cryptographic Message Syntax can support a variety of
   architectures for certificate-based key management, such as the one
   defined by the PKIX working group.
- - - - - - - - - - - - 

Patrik
---------------------------------------------------------------------
Patrik Nilsson     |    [email-masked]    |     +46 (0)708 452 859
---------------------------------------------------------------------

From: "Rich Ankney" <[email-masked]>
To: "WHenry" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Standards for Digitally Signed Documents
Date: Tue, 5 May 1998 15:25:24 -0400
Sender: [email-masked]

I've also been fond of PKCS #7 (IETF CMS) to store signed documents.
This is basically S/MIME without the MIME headers and (possibly)
base64 encoding.  Note that CMS allows one to store the signature
structure (SignedData) separately from the content.

I know of a couple of medical records standards that use this approach.

Regards,
Rich
----------
> From: WHenry <[email-masked]>
> To: [email-masked]'
> Subject: Standards for Digitally Signed Documents
> Date: Tuesday, May 05, 1998 1:43 PM
> 
>  I hope this isn't out of the context of PKIX, but I'll ask anyway. Is
there
> an IETF WG or other that is handling standards for digitally signed
> documents?
> 
>  There is an email/message transfer (i.e. S/MIME) standard, but there
don't
> appear to be any similar standards for storage of digitally signed
> documents.
> 
>  I see three options:
>  1) use a proprietary format (e.g. Entrust or Verisign) for storing
> documents; in which case all who need access to the documents require the
> same public key infrastructure.
>  2) actually store a signed document in S/MIME format.
>  3) create middleware/proprietary option(s) for appending digital
signatures
> to the likes of .doc or .ppt documents.
> 
>  I'd greatly appreciate any comments or thoughts on the above.
> 
>  Bill Henry
>  Performance Engineering Corporation
>  3949 Pender Drive
>  Farifax, VA  22030
>  [email-masked]
> 

From: WHenry <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Standards for Digitally Signed Documents
Date: Tue, 5 May 1998 13:43:32 -0400 
Sender: [email-masked]

 I hope this isn't out of the context of PKIX, but I'll ask anyway. Is there
an IETF WG or other that is handling standards for digitally signed
documents?

 There is an email/message transfer (i.e. S/MIME) standard, but there don't
appear to be any similar standards for storage of digitally signed
documents.

 I see three options:
 1) use a proprietary format (e.g. Entrust or Verisign) for storing
documents; in which case all who need access to the documents require the
same public key infrastructure.
 2) actually store a signed document in S/MIME format.
 3) create middleware/proprietary option(s) for appending digital signatures
to the likes of .doc or .ppt documents.

 I'd greatly appreciate any comments or thoughts on the above.

 Bill Henry
 Performance Engineering Corporation
 3949 Pender Drive
 Farifax, VA  22030
 [email-masked]

> -----Original Message-----
> From:	Miklos, Sue A. [SMTP:[email-masked]]
> Sent:	Tuesday, May 05, 1998 9:30 AM
> To:	'Blake Ramsdell'; [email-masked]'
> Cc:	[email-masked]'
> Subject:	RE: Role names in certificates
> 
> I'm somewhat confused.  I had thought that certificates and roles could
> be used in a variety of contexts (applications) for, among other things,
> access control.  Therefore this would appear to extend beyond just the
> S/MIME messaging context.  Is this of interest to the LDAP access
> controls?  Is this useful for the web-based document retrieval
> environments?  
> 
> Sandi Miklos
> 
> 
> >----------
> >From: 	Denis Pinkas[SMTP:[email-masked]]
> >Sent: 	Tuesday, May 05, 1998 5:49 PM
> >To: 	Blake Ramsdell
> >Cc: 	[email-masked]'
> >Subject: 	Re: Role names in certificates
> >
> >> I have written a draft that I have submitted as an individual (not
> under
> >> IETF-PKIX).  It describes a concept of using "role" names in
> >> certificates for several purposes that are not covered with
> conventional
> >> PKIX certificates.  
> >
> >I am not sure that this thread is relevant to the PKIX WG. It might be
> >more relevant to the S/MIME WG.
> >
> >> I have currently profiled the rfc822Name choice, but
> >> I have heard that there is interesting in profiling the dNSName choice
> >> also.  Cutting and pasting a little bit from the document, roles are
> >> defined for:
> >> 
> >> * The need to sign messages on behalf of people at a domain that may or
> >> may not have signature services available at the desktop. An outbound
> >> message from a domain may be sent that is signed at the domain mail
> >> server.
> >
> >A requirement would be the need to sign a message as the Sales Director
> >of the Delta Company, who may happen to be John Walker. However John
> >Walker may not have a private key of its own.
> > 
> >> * The need to encrypt messages for people at a domain that may not have
> >> encryption services available at the desktop. A message may be
> encrypted
> >> for the domain mail server using a domain encrypting certificate, and
> >> that message will be decrypted before local delivery.
> >
> >For the other following cases related to encryption, I wonder why a role
> >is needed.
> > 
> >> * The need to encrypt messages between two mail transfer agents (MTAs).
> >> This is different than a domain encrypting certificate, in that the
> >> message is never encrypted or decrypted at the mail user agent (MUA)
> >> level.
> >> 
> >> * The need to encrypt messages for a keypair that is controlled by the
> >> domain administrator for the purposes of plaintext access. A message
> may
> >> be encrypted for the domain mail server using a domain message recovery
> >> encryption certificate for the purpose of selective plaintext recovery
> >> by the domain administrator. This differs from a domain encrypting
> >> certificate in that the message is not necessarily decrypted before
> >> local delivery.
> >> 
> >> I know that the last one is going to be controversial, and this is not
> >> an all-or-nothing proposal (you can simply not implement it).  Please
> >> don't flame me for daring to speak its evil name, but keep an open mind
> >> for the other uses I have listed.
> >
> >> This is meant to get the ball rolling in a direction where we think
> >> about PKIX representing entities that are not necessarily a specific
> >> end-entity, but an end-entity with a particular role or responsibility.
> >
> >This is the point.
> >
> >> Any insight welcome as to how to address these issues in an alternative
> >> way.
> > 
> >> http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
> >> the latest version
> >> http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
> >> the current draft at the IETF.
> >> 
> >> Now where's my suit...
> >
> >There are several ways to address this issue. Among them: 
> >
> >1) a signature server (from a company) is able to sign documents on
> >behalf of an employee with its own key and indicate the appropriate role
> >used by the employee. The employee may authenticate to that signature
> >server by whatever means. In that case the signer is the company which
> >indicates the role of the employee.
> >
> >2) a temporary certificate issued by a server of a company includes a
> >role and a temporary public key. The employee is given back the
> >temporary private key so that it can sign documens directly using that
> >private key.
> >
> >If we would like to support such scheme(s), some arrangements would need
> >to be done to the S/MIME specifications, so I would propose to shift
> >this thread to the S/MIME WG.
> >
> >Denis
> > 
> >> Blake
> >> --
> >> Blake C. Ramsdell
> >> Worldtalk Corporation
> >> For current info, check http://www.deming.com/users/blaker
> >> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
> >
> >-- 
> >      Denis Pinkas     Bull S.A.          mailto:[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: Tue, 05 May 1998 11:11:43 -0400
To: Nada Kapidzic Cicovic <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Usage of Diffe-Hellman keys
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 11:00 AM 5/5/98 +0200, Nada Kapidzic Cicovic wrote:
>Hi all,

Hi.

>Sorry for cross-posting this letter to PKIX and S/MIME lists, but it seems
>to me that this topic belongs to both of them. I was wondering about the
>usage of Diffie-Hellman keys and the suggested values of keyUsage extension. 
>
>PKIX part1 section 7.3.2 suggests three possible values for keyUsage
>extension in a certificate containing Diffie-Hellman public key:
>keyAgreement, enchipherOnly and dechiperOnly.
>
>Trying to put this into S/MIME context it seems that Diffie-Hellman keys
>may only be used in the way suggested by Russ Housley, i.e. for each
>recipient to take recipient's Diffie-Hellman certificate (key agreement
>certificate), get the public key from there, generate a shared key (Russ
>suggested 3DES) and use it to encrypt the content-encryption key.

Obviously, I support this approach.  I envision the keyAgreement bit set in
the certificate containing the D-H public key.

>However, another possibility is to use El-Gamal algorithm with
>Diffie-Hellman keys and encrypt the content-encryption key directly with
>recipients Diffie-Hellman public key. This would be a very similar
>operation as if the recipient had RSA keys and keyEnchipherment
>certificate. This seems to be a much better way of using Diffie-Hellman
>keys, similar to the way RSA keys are used for keys encryption (unless I
>have missed some point here).

As you describe the process, it is not key agreement.  Rather it is
keyEnchipherment.  Althought the process for key generation is the same, I
would not coniser it a Diffie-Hellman key.  Similalry, a DSA key can
mathematically be used for key agreement (in either Diffie-Hellman or KEA),
yet I do not consider a DSA key to be a key agreement key.

>In order to use El-Gamal in the described way, keyUsage extension in
>certificates containing Diffie-Hellman keys would need to have
>keyEnchipherment bit set. Therefore, if I am not mistaking in my above
>decryption, I suggest the following changes in PKIX part1:
>
>- Changing the name of section 7.3.2 from "Diffie-Hellman Key Exchange Key"
>into "Diffie-Hellman Keys" (in accordance with 7.3.1 RSA Keys).
>
>- Adding keyEnchipherment as a possible value of the keyUsage extension.
>
>- Adding the following decryption at the end of the section: When
>keyEnchipherment bit is set in keyUsage extension, the public key may be
>used for encrypting session keys by using El-Gamal algorithm.
>
>
>In order to use El-Gamal for encrypting content-encryption keys in S/MIME,
>an object identifier would need to be assigned for El-Gamal algorithm (I
>have failed to find an existing one; does anybody have some info about
>it?). I suppose this would be a task of S/MIME group, and contained in one
>of the S/MIME drafts.
>
>
>Again, if I am not mistaking here, I would suggest this changes to be made
>in both drafts, since this would aid a lot in usage of Diffie-Hellman keys.
>
>
>I am looking forward to hearing your opinions.
>
>Regards,
>
>Nada
>______________________________________________________________
>
>Nada Kapidzic Cicovic
>COST - Computer Security Technologies CST AB 
>(subsidiary of Entegrity Solutions Corporation)
>office:   + 46 (0)8 477 77 37
>mobile:   + 46 (0)70 495 09 03
>fax:      + 46 (0)8 477 77 31
>e-mail:   [email-masked] or [email-masked]
>address:  Finlandsgatan 60, 164 74 Kista, Sweden
> 

Date: Tue, 05 May 1998 17:23:42 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Miklos, Sue A." <[email-masked]>
CC: "'Blake Ramsdell'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Role names in certificates
Sender: [email-masked]

Miklos, Sue A. wrote:
 
> I'm somewhat confused.  I had thought that certificates and roles could
> be used in a variety of contexts (applications) for, among other things,
> access control.  Therefore this would appear to extend beyond just the
> S/MIME messaging context.  

Your are right. Role-based access control for "real-time" transactions
(as opposed to store and forward schemes) is another area where the
solutions may be different. Examples of such solutions are DCE and
SESAME where in both cases PAC "Privilege Attribute Certificates" are
used. 

> Is this of interest to the LDAP access controls?  
> Is this useful for the web-based document retrieval environments?

This could be. 

Denis

> Sandi Miklos
> 
> >----------
> >From:  Denis Pinkas[SMTP:[email-masked]]
> >Sent:  Tuesday, May 05, 1998 5:49 PM
> >To:    Blake Ramsdell
> >Cc:    [email-masked]'
> >Subject:       Re: Role names in certificates
> >
> >> I have written a draft that I have submitted as an individual (not under
> >> IETF-PKIX).  It describes a concept of using "role" names in
> >> certificates for several purposes that are not covered with conventional
> >> PKIX certificates.
> >
> >I am not sure that this thread is relevant to the PKIX WG. It might be
> >more relevant to the S/MIME WG.
> >
> >> I have currently profiled the rfc822Name choice, but
> >> I have heard that there is interesting in profiling the dNSName choice
> >> also.  Cutting and pasting a little bit from the document, roles are
> >> defined for:
> >>
> >> * The need to sign messages on behalf of people at a domain that may or
> >> may not have signature services available at the desktop. An outbound
> >> message from a domain may be sent that is signed at the domain mail
> >> server.
> >
> >A requirement would be the need to sign a message as the Sales Director
> >of the Delta Company, who may happen to be John Walker. However John
> >Walker may not have a private key of its own.
> >
> >> * The need to encrypt messages for people at a domain that may not have
> >> encryption services available at the desktop. A message may be encrypted
> >> for the domain mail server using a domain encrypting certificate, and
> >> that message will be decrypted before local delivery.
> >
> >For the other following cases related to encryption, I wonder why a role
> >is needed.
> >
> >> * The need to encrypt messages between two mail transfer agents (MTAs).
> >> This is different than a domain encrypting certificate, in that the
> >> message is never encrypted or decrypted at the mail user agent (MUA)
> >> level.
> >>
> >> * The need to encrypt messages for a keypair that is controlled by the
> >> domain administrator for the purposes of plaintext access. A message may
> >> be encrypted for the domain mail server using a domain message recovery
> >> encryption certificate for the purpose of selective plaintext recovery
> >> by the domain administrator. This differs from a domain encrypting
> >> certificate in that the message is not necessarily decrypted before
> >> local delivery.
> >>
> >> I know that the last one is going to be controversial, and this is not
> >> an all-or-nothing proposal (you can simply not implement it).  Please
> >> don't flame me for daring to speak its evil name, but keep an open mind
> >> for the other uses I have listed.
> >
> >> This is meant to get the ball rolling in a direction where we think
> >> about PKIX representing entities that are not necessarily a specific
> >> end-entity, but an end-entity with a particular role or responsibility.
> >
> >This is the point.
> >
> >> Any insight welcome as to how to address these issues in an alternative
> >> way.
> >
> >> http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
> >> the latest version
> >> http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
> >> the current draft at the IETF.
> >>
> >> Now where's my suit...
> >
> >There are several ways to address this issue. Among them:
> >
> >1) a signature server (from a company) is able to sign documents on
> >behalf of an employee with its own key and indicate the appropriate role
> >used by the employee. The employee may authenticate to that signature
> >server by whatever means. In that case the signer is the company which
> >indicates the role of the employee.
> >
> >2) a temporary certificate issued by a server of a company includes a
> >role and a temporary public key. The employee is given back the
> >temporary private key so that it can sign documens directly using that
> >private key.
> >
> >If we would like to support such scheme(s), some arrangements would need
> >to be done to the S/MIME specifications, so I would propose to shift
> >this thread to the S/MIME WG.
> >
> >Denis
> >
> >> Blake
> >> --
> >> Blake C. Ramsdell
> >> Worldtalk Corporation
> >> For current info, check http://www.deming.com/users/blaker
> >> Voice +1 425 882 8861 x103  Fax +1 425 882 8060

-- 
      Denis Pinkas     Bull S.A.          mailto:[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

From: "Scott, Greg" <[email-masked]>
To: [email-masked]
Subject: Question re ipki2opp-07
Date: Tue, 5 May 1998 09:53:00 -0400 
Sender: [email-masked]

   This is probably painfully obvious to most, but I'm just asking to be 
   sure.
   
   In section 6.2.1 the filter is defined as:
   
           Filter ::=
             CHOICE {
                     present       [7] AttributeType, -- "objectclass" only
                    }
   
   In 7.2.1 the text states that an element added to this service is:
   
     "- Enhanced filter capability"
   
   but there is no ASN.1 code redefining Filter.  
   
   Does this mean that the full range of filter conditions defined in RFC 
   1777 section 4.3 is now available?
   
   Thanks,
   
   Greg
   
   PS. Spelling and grammar nits:
      
       Section 6.2.2, I believe that "The application/relying party may 
       ..." should read "The application/replying party may ..."
       
       Section 7, "To search ,using ..." should read "To search, using ..."

From: "Miklos, Sue A." <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Role names in certificates
Date: Tue, 5 May 1998 09:29:38 -0400
Sender: [email-masked]

I'm somewhat confused.  I had thought that certificates and roles could
be used in a variety of contexts (applications) for, among other things,
access control.  Therefore this would appear to extend beyond just the
S/MIME messaging context.  Is this of interest to the LDAP access
controls?  Is this useful for the web-based document retrieval
environments?  

Sandi Miklos

>----------
>From: 	Denis Pinkas[SMTP:[email-masked]]
>Sent: 	Tuesday, May 05, 1998 5:49 PM
>To: 	Blake Ramsdell
>Cc: 	[email-masked]'
>Subject: 	Re: Role names in certificates
>
>> I have written a draft that I have submitted as an individual (not under
>> IETF-PKIX).  It describes a concept of using "role" names in
>> certificates for several purposes that are not covered with conventional
>> PKIX certificates.  
>
>I am not sure that this thread is relevant to the PKIX WG. It might be
>more relevant to the S/MIME WG.
>
>> I have currently profiled the rfc822Name choice, but
>> I have heard that there is interesting in profiling the dNSName choice
>> also.  Cutting and pasting a little bit from the document, roles are
>> defined for:
>> 
>> * The need to sign messages on behalf of people at a domain that may or
>> may not have signature services available at the desktop. An outbound
>> message from a domain may be sent that is signed at the domain mail
>> server.
>
>A requirement would be the need to sign a message as the Sales Director
>of the Delta Company, who may happen to be John Walker. However John
>Walker may not have a private key of its own.
> 
>> * The need to encrypt messages for people at a domain that may not have
>> encryption services available at the desktop. A message may be encrypted
>> for the domain mail server using a domain encrypting certificate, and
>> that message will be decrypted before local delivery.
>
>For the other following cases related to encryption, I wonder why a role
>is needed.
> 
>> * The need to encrypt messages between two mail transfer agents (MTAs).
>> This is different than a domain encrypting certificate, in that the
>> message is never encrypted or decrypted at the mail user agent (MUA)
>> level.
>> 
>> * The need to encrypt messages for a keypair that is controlled by the
>> domain administrator for the purposes of plaintext access. A message may
>> be encrypted for the domain mail server using a domain message recovery
>> encryption certificate for the purpose of selective plaintext recovery
>> by the domain administrator. This differs from a domain encrypting
>> certificate in that the message is not necessarily decrypted before
>> local delivery.
>> 
>> I know that the last one is going to be controversial, and this is not
>> an all-or-nothing proposal (you can simply not implement it).  Please
>> don't flame me for daring to speak its evil name, but keep an open mind
>> for the other uses I have listed.
>
>> This is meant to get the ball rolling in a direction where we think
>> about PKIX representing entities that are not necessarily a specific
>> end-entity, but an end-entity with a particular role or responsibility.
>
>This is the point.
>
>> Any insight welcome as to how to address these issues in an alternative
>> way.
> 
>> http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
>> the latest version
>> http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
>> the current draft at the IETF.
>> 
>> Now where's my suit...
>
>There are several ways to address this issue. Among them: 
>
>1) a signature server (from a company) is able to sign documents on
>behalf of an employee with its own key and indicate the appropriate role
>used by the employee. The employee may authenticate to that signature
>server by whatever means. In that case the signer is the company which
>indicates the role of the employee.
>
>2) a temporary certificate issued by a server of a company includes a
>role and a temporary public key. The employee is given back the
>temporary private key so that it can sign documens directly using that
>private key.
>
>If we would like to support such scheme(s), some arrangements would need
>to be done to the S/MIME specifications, so I would propose to shift
>this thread to the S/MIME WG.
>
>Denis
> 
>> Blake
>> --
>> Blake C. Ramsdell
>> Worldtalk Corporation
>> For current info, check http://www.deming.com/users/blaker
>> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>-- 
>      Denis Pinkas     Bull S.A.          mailto:[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
>

From: [email-masked]
To: Anne Anderson - Sun Microsystems <[email-masked]>
cc: [email-masked]
Date: Tue, 5 May 1998 08:51:28 -0400
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Anne Anderson <[email-masked]> writes:

>There currently is no way to encode DNS and other alternative
>names as RDNs that is supported by PKIX.  If there were, then
>I agree completely with Dave's argument.
>
>The DC= format is in RFC2247, and this has not been incorporated
>into either X.501/X.509 or PKIX.

RFC2247 names are perfectly valid X.500 names, and as there are no
restrictions on the attribute types used within Name objects in the PKIX-1
spec, there should be no problem with putting them into the Subject or
Issuer fields of PKIX certificates.  But I agree that it would be good if
the PKIX documents were to explicitly recommend the use of the RFC2247 'DC'
attribute type to represent names from the DNS namespace, for situations
where a key is owned by some entity identified by a DNS name.  This might
prevent someone from inventing a different way to represent DNS names.

Other messages have interpreted the use of X.500 names as implying some
sort of control by the ITU.  I don't see where this comes from at all.
X.500 RDNs are typed, those types being specified using OIDs which are
expressly designed to support federated allocation and control.  "Control"
of any particular subtree within the X.500 namespace belongs to whatever
body is responsible for the OID of the top-level RDN of that subtree.  For
RFC2247 names, the 'DC' OID has been specified by its owner as representing
DNS components, and therefore such names are "controlled" by the DNS.

If I wanted to invent my own attribute-type for use in names I generate, I
could do so, and I would retain control of all such names.  I wouldn't have
to register this attribute type with the ITU or anyone else (assuming I
already have an OID register).  I can think of two reasons for not doing so
(or at least for not putting such names in PKIX certificates), neither of
which has anything to do with control of a portion of the namespace, but
instead have to do with interoperability:

i) PKIX implementations won't know what matching rules to apply to
attribute types they don't recognize.  The proposed new PKIX-1 text
specifies some universal matching rules, regardless of what might be
specified in my attribute definition, which would eliminate this problem,
although I'd prefer to see the new rules specified only as a fallback
mechanism, to be used when the "real" matching rules aren't known to the
implementation.

ii) Broken PKIX implementations might reject names that use attributes they
don't recognize.  Can some text be added to PKIX-1 to alert implementors to
the fact that names can use varied name forms and attribute types, and that
names shouldn't be rejected simply because they use unfamiliar attributes?

John

Date: Tue, 05 May 1998 14:49:30 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Blake Ramsdell <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Role names in certificates
Sender: [email-masked]

> I have written a draft that I have submitted as an individual (not under
> IETF-PKIX).  It describes a concept of using "role" names in
> certificates for several purposes that are not covered with conventional
> PKIX certificates.  

I am not sure that this thread is relevant to the PKIX WG. It might be
more relevant to the S/MIME WG.

> I have currently profiled the rfc822Name choice, but
> I have heard that there is interesting in profiling the dNSName choice
> also.  Cutting and pasting a little bit from the document, roles are
> defined for:
> 
> * The need to sign messages on behalf of people at a domain that may or
> may not have signature services available at the desktop. An outbound
> message from a domain may be sent that is signed at the domain mail
> server.

A requirement would be the need to sign a message as the Sales Director
of the Delta Company, who may happen to be John Walker. However John
Walker may not have a private key of its own.
 
> * The need to encrypt messages for people at a domain that may not have
> encryption services available at the desktop. A message may be encrypted
> for the domain mail server using a domain encrypting certificate, and
> that message will be decrypted before local delivery.

For the other following cases related to encryption, I wonder why a role
is needed.
 
> * The need to encrypt messages between two mail transfer agents (MTAs).
> This is different than a domain encrypting certificate, in that the
> message is never encrypted or decrypted at the mail user agent (MUA)
> level.
> 
> * The need to encrypt messages for a keypair that is controlled by the
> domain administrator for the purposes of plaintext access. A message may
> be encrypted for the domain mail server using a domain message recovery
> encryption certificate for the purpose of selective plaintext recovery
> by the domain administrator. This differs from a domain encrypting
> certificate in that the message is not necessarily decrypted before
> local delivery.
> 
> I know that the last one is going to be controversial, and this is not
> an all-or-nothing proposal (you can simply not implement it).  Please
> don't flame me for daring to speak its evil name, but keep an open mind
> for the other uses I have listed.

> This is meant to get the ball rolling in a direction where we think
> about PKIX representing entities that are not necessarily a specific
> end-entity, but an end-entity with a particular role or responsibility.

This is the point.

> Any insight welcome as to how to address these issues in an alternative
> way.
 
> http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
> the latest version
> http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
> the current draft at the IETF.
> 
> Now where's my suit...

There are several ways to address this issue. Among them: 

1) a signature server (from a company) is able to sign documents on
behalf of an employee with its own key and indicate the appropriate role
used by the employee. The employee may authenticate to that signature
server by whatever means. In that case the signer is the company which
indicates the role of the employee.

2) a temporary certificate issued by a server of a company includes a
role and a temporary public key. The employee is given back the
temporary private key so that it can sign documens directly using that
private key.

If we would like to support such scheme(s), some arrangements would need
to be done to the S/MIME specifications, so I would propose to shift
this thread to the S/MIME WG.

Denis
 
> Blake
> --
> Blake C. Ramsdell
> Worldtalk Corporation
> For current info, check http://www.deming.com/users/blaker
> Voice +1 425 882 8861 x103  Fax +1 425 882 8060

-- 
      Denis Pinkas     Bull S.A.          mailto:[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: Tue, 05 May 1998 13:56:45 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Slava Galperin <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP status tally
Sender: [email-masked]

Slava,

It may happen that an OCSP responder is in charge of multiple CAs.
Without that name, you would *mandate* the use an internal index that
will have to be the hash of the issuer public key.

This would work fine, but would mandate an implementation design. Is it
really needed to save a few bits and thus to omit to advertise the name
of the issuer ?

I would prefer to let the choice of the implememtation to the
implementors.

Denis

> Michael Myers wrote:
> >
> > Marc, All:
> >
> > I would like to propose we move forward with the following simplified
> > construction:
> >
> > CertStatusType ::= ENUMERATED {
> >     notRevoked     (0),
> >     revoked        (1),
> >     onHold         (2),
> >     unknownCA      (3),
> >     unknownCert    (4) }
> >
> > In the unknownCA case, a repository may not have acquired information
> > necessary to produce any other assertion.  The unknownCert value addresses
> > all other states not explicitly address by notRevoked or revoked.  In
> > particular, it may be the case that a certain repositories can be proven to
> > have only received a subset of a CA's information via mechanisms such as
> > CRL Distribution Points, CRLList or other means of delegating authority.
> >
> 
> I think it might be reasonable to include revocation reason or
> revocation date when sending "revoked" status (and in this case it may
> be combined with "onHold" case).
> Also various "do not know"s can be folded into single "unknown" response
> since it seems unlikely that OCSP requester cares about the difference.
> 
> May I reintroduce my original suggestion to have the following
> RevocationStauts definition with small variations (hoping that after
> numerous discussions we had the intent here will be a little clearer
> this time):
> 
> RevocationStatus ::= CHOICE {
>         unknown      [0] IMPLICIT UnknownInfo,
>         notRevoked   [1] IMPLICIT NULL,
>         revoked      [2] IMPLICIT RevokedInfo,
> 
> }
> 
> UnknownInfo ::= NULL -- this can be replaced with an enumeration
>                      -- for various specific reasons such as
> doNotKnowAboutCA etc.
> 
> RevokedInfo ::= SEQUENCE {
>         revocationTime GeneralizedTime,
>         revocationReason RevocationReason OPTIONAL -- this could include
> "onHold"
> }
> 
> I would like to stress that if OCSP requester does not care about the
> details attached to specific status it can stop after parsing the CHOICE
> tag and is not required to parse CHOICE inner content. Therefore for
> less sophisticated OCSP requresters this definitions is just as simple
> as ENUMERATED whereas more sophisticated ones can take advantage of the
> information associated with a particular status code.
> 
> --
> 
> Slava

-- 
      Denis Pinkas     Bull S.A.          mailto:[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: Tue, 05 May 1998 11:00:34 +0200
To: [email-masked], [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: Usage of Diffe-Hellman keys
Sender: [email-masked]

Hi all,

Sorry for cross-posting this letter to PKIX and S/MIME lists, but it seems
to me that this topic belongs to both of them. I was wondering about the
usage of Diffie-Hellman keys and the suggested values of keyUsage extension. 

PKIX part1 section 7.3.2 suggests three possible values for keyUsage
extension in a certificate containing Diffie-Hellman public key:
keyAgreement, enchipherOnly and dechiperOnly.

Trying to put this into S/MIME context it seems that Diffie-Hellman keys
may only be used in the way suggested by Russ Housley, i.e. for each
recipient to take recipient's Diffie-Hellman certificate (key agreement
certificate), get the public key from there, generate a shared key (Russ
suggested 3DES) and use it to encrypt the content-encryption key.

However, another possibility is to use El-Gamal algorithm with
Diffie-Hellman keys and encrypt the content-encryption key directly with
recipients Diffie-Hellman public key. This would be a very similar
operation as if the recipient had RSA keys and keyEnchipherment
certificate. This seems to be a much better way of using Diffie-Hellman
keys, similar to the way RSA keys are used for keys encryption (unless I
have missed some point here).

In order to use El-Gamal in the described way, keyUsage extension in
certificates containing Diffie-Hellman keys would need to have
keyEnchipherment bit set. Therefore, if I am not mistaking in my above
decryption, I suggest the following changes in PKIX part1:

- Changing the name of section 7.3.2 from "Diffie-Hellman Key Exchange Key"
into "Diffie-Hellman Keys" (in accordance with 7.3.1 RSA Keys).

- Adding keyEnchipherment as a possible value of the keyUsage extension.

- Adding the following decryption at the end of the section: When
keyEnchipherment bit is set in keyUsage extension, the public key may be
used for encrypting session keys by using El-Gamal algorithm.

In order to use El-Gamal for encrypting content-encryption keys in S/MIME,
an object identifier would need to be assigned for El-Gamal algorithm (I
have failed to find an existing one; does anybody have some info about
it?). I suppose this would be a task of S/MIME group, and contained in one
of the S/MIME drafts.

Again, if I am not mistaking here, I would suggest this changes to be made
in both drafts, since this would aid a lot in usage of Diffie-Hellman keys.

I am looking forward to hearing your opinions.

Regards,

Nada
______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB 
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Date: Mon, 04 May 1998 18:54:29 -0700
From: Slava Galperin <[email-masked]>
Organization: Teknowledge Corporation
To: Ambarish Malpani <[email-masked]>
CC: IETF PKIX <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------D1F529F87476838B12F5530C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

Most of the people who responded to this message agree that only option
3 (IssuerDN, Hash(IssuerPublicKey) and CertSerialNumber) is usable.
However there is still an unsettled issue of whether to mandate use of
issuer DN for EE cert and subject DNs for CA cert or relax it to use
respective AltName extensions. 

I have suggested earlier that <em> in the context of OCSP </em> we may
get away from using names altogether (and thus avoid name-related
arguments). At that time the proposal did not have much support. I would
like to revisit it again and analyze scenarios and arguments. To restore
context I quoted my original message as well as some relevant responses
from Dave Kemp and Stephen Kent. My analysis and summary is at the end
of this message.

Slava Galperin wrote:

> 
> Technically I am proposing to use either
> 
> CertID                  ::=     SEQUENCE {
>          issuerKeyHash            Hash,
>          serialNumber                    CertificateSerialNumber,
> }
> 
> where issuerKeyHash is a hash of subjectPublicKeyInfo field from the
> corresponding CA certificate, or
> 
> CertID                  ::=     SEQUENCE {
>          issuerKey          SubjectPublicKeyInfo,
>          serialNumber                    CertificateSerialNumber,
> }
> 
> in case we are afraid of the hash collisions and are willing to
> sacrifice some bandwidth for some peace of mind.
> 
> Note however, that both in the original RCSP spec and in my proposed
> scheme above there is another interesting open problem of dealing with
> the CA
> key change-over, i.e. when various subsets of the set of all issued
> certificates (and CRLs !) are signed by different signing keys
> 

Stephen Kent ([email-masked]) wrote:

> Slava,
> 
> While the hash of a CA's key would likely be unique, it also is a terrible
> search key in many instances. One has to be careful about the context in
> which a pointer to a CA cert is being used. In a cert, having a CA "key ID"
> that is based on the hash of the CA is fine, because we already have the CA
> name, and maybe even a locator.  In other protocol context we should have a
> similar level of naming for search purposes, and rely on something like a
> key hash just for disambiguation among multiple possible keys associated
> with the same CA.

David P. Kemp ([email-masked]) wrote:

> 
> This is a reasonable approach if you ignore the cert retrieval and
> multiple-key issues, however you still need to specify the hash
> algorithm since it's inappropriate to hard code a single algorithm
> into the standard:
> 
>    CertID ::= SEQUENCE {
>       issuerKeyID       KeyID,
>       serialNumber      CertificateSerialNumber }
> 
>    KeyID  ::= CHOICE {
>       publicKey         [0] SubjectPublicKeyInfo,
>       sha1KeyHash       [1] OCTET STRING,     -- SHA1 of SubjectPublicKeyInfo
>       ripemd160KeyHash  [2] OCTET STRING,
>        ...       }
> 
> 
> All in all, it gets pretty ugly if you want to make it work in all cases.
> It may be easier just to use the existing authority and subject key
> identifier extensions instead of trying to design something new.
> 

I would like to start analyzing possible contexts for certificate
identification in OCSP. 

OCSP client (I am assuming fat OCSP client that has already verified
signatures, validity and other extension-constrained semantics on the
certificate chain and only needs to check revocation status of ALL the
certificates in the chain) knows the public key of CA used to sign any
certificate in the chain. It must already know this because this is how
it verifies signatures in the chain (it will be using some sort of
chaining algorithm based on a combination of issuer primary/alternative
name and key identifier which I leave for PKIX 1 to define, the bottom
line is : for every certificate in the chain CA's public key is
inambiguosly known to the OCSP client).

On the other side, OCSP responder needs to map cert identification
information from the OCSP request onto some certificate status record.
It achieves it by converting cert id into query which can produce none,
one or multiple results. Cert id chosen for OCSP should satisfy two
goals: to be unique and to provide OCSP responder implementations with
basis for efficient indexing. Steve in his response makes a very valid
point that public key hash may be a lousy index. I guess our recent
discussion shows that issuer name could be even more lousy one. Aside
from canonicalization, two main disadvantages are: multiple name forms
(needed by different people and different applications) and absence of
the reliable infrastructure that guarantees uniqueness of the name (is
not it this very point that brings Hash(IssuerPublicKey) into all of the
certificate identification schemes proposed by Ambarish ?). 

If we do agree to include Hash(IssuerPublicKey) in the cert ID to
disambiguate potential issuer name collisions, then OCSP responder must
be prepared to use it (otherwise it serves no purpose) and thus deal
with issues like CA using multiple signing keys over time. This means
that it needs to have information on all public keys (past and present)
used by a CA to sign certificates. For OCSP responder implementation
closely integrated with a CA having access to this info should not be a
problem. For an OCSP responder working off CRL it needs CA
certificates/keys anyway to verify signature on CRLs (assuming that the
same key used for certifcates and CRL). At any rate I do not see
maintaining a list of past and present CA public keys in  OCSP responder
configuration to be a serious implementation constraint and in most
cases it will be available there for other reasons. Also CA key
change-over is not likely to be a very frequent event so number of the
CA certificates(or public keys) OCSP responder implementation needs to
remember is not an issue.

Having said all of that I would like to repropose using just a pair
(Hash(IssuerPublicKey),CertSerialNumber) as cert id in OCSP. It is
unique (by definition), free from multiple name form/canonicalization
problems and does allow efficient indexing on OCSP responder side
(provided CA public key history is maintained).

If it does get accepted we can work out ASN.1 syntax details
(incorporating open set of hash algorithms etc.)

HTH
--
Slava
--------------D1F529F87476838B12F5530C
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Slava Galperin
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Slava Galperin
n:              Galperin;Slava
org:            Teknowledge Corporation
adr:            1810 Embarcadero Road;;;Palo Alto;CA;94303;USA
email;internet: [email-masked]
title:          Senior Scientist
tel;work:       (650)242-0500x519
tel;fax:        (650)493-2645
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

--------------D1F529F87476838B12F5530C--

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "pkix" <[email-masked]>
Subject: OCDP and Smartcards and progressing to proposed standard
Date: Mon, 4 May 1998 17:51:35 -0400
Sender: [email-masked]

Last week I attended the CardTech/SecureTech conference in Washington DC.

This set me thinking about the practicallity of acheiving OFFLINE
authorisation using a smartcard to store a private key, certificate and
associated authorisation and validity information.

Offline authorisation is interesting for two reasons:

First, it is not always possible to ensure that a terminal is connected to
the Internet. Consider that it is relatively cheap to add a smartcard reader
and solenoid to a door (order $100) but running a wire to the door can be
very expensive indeed (Installation cost typically $10-$50/meter).

Second, it is not always possible to guarantee network availability. The
question of how a system reacts when temporarily disconnected must therefore
be considered. I call this situation 'quasi-offline', the key point is to
avoid denial of service attacks in which loss of connection to head office
stops all local access.

The use of smartcards introduces a major space constraint, The private key,
certificate and validity information must certainly occupy no more than 8Kb
and preferably occupies very much less. Conventional CRLs which might grow
to millions of certificates are clearly unacceptable. Indeed the practical
limit on a CRL to fit on a smartcard is probably no more than 25 entries.

Static Certificate Distribution Points (ie those which may or may not be in
PKIX part 1) aford a brute force solution of the problem, albeit one
unlikely to be very acceptable. Simply divide the certificate population
into partitions of 35 certificates and issue a CRL for each.

The scoping part of OCDP allows the CRL partitions to be much larger.
Because partitions may be defined at the time of issue the limit of
partition size is the number of certificates actually revoked rather than a
particular number of certificates. Thus is 10% of certificates are revoked
the average partition will consist of 350 certificates (35 of which are
revoked) and the CA does 10% of the work which would be required with static
 partitions. If the proportion of revoked certificates is smaller the work
factor reduces even further!

Observe that a CA issuing such CRLs on a daily basis would on average spend
roughly an equal amount of time signing CRLs and actual certificates.
(Assume certificates are valid for a year). A scoped CRL may thus constitute
a sufficient solution to the offline revocation/statement of validity
problem.

[BTW a smartcard may aquire its CRL partition whenever it is used in an
online transaction. The smartcard having the ability to check the CRL
signature for validity and also check that it is more recent than its
current CRL partition]

CRLList allows the effort required by the CA to be reduced still further
however. Using CRLList the CA does not need to re-sign each CRL partition
each day. Only those partitions which have changed need to be re-signed.

While it may not be practical to place the CRLList on the smartcard at
present there are many 'quasi-offline' cases in which it is possible to
assume the party needing to validate a certificate has access to the CRLList
even though it is not practical to assume that they have access to
individual CRL partitions. Consider the case in which a remote office
downloads the CRLList at the start of each business day but does not have
adequate bandwidth to perform on-demand downloading of CRLs.

In summary I believe that OCDP is a very useful tool which solves a set of
important problems which are not addressed by static CDPs, OCSP, revocation
trees etc. That is not to say that these do not also have a place.

OCDP is certainly far more than a 'work arround' the Entrust patent. While
the case for OCDP becomes hard to argue against if the licensing terms
themselves prove unacceptable (at present we have only statements concerning
what those terms would be which is not the same thing), the case is still
strong if an acceptable covenant is offered and made.

The question is then how to go forward with OCDP within the IETF. I
certainly do not want to derail the PKIX part 1 standards track process, on
the other hand OCDP is quite logically a part of the PKIX CRL profile. What
I propose is that we progress the current draft towards Proposed Standard as
a separate RFC. We then have the option of 'docking' OCDP with the main
standards document as we go through the process of progressing that to Draft
Standard. Alternatively the docking maneuver could take place much later on
as part of PKIXv2.

        Phill

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "pkix" <[email-masked]>
Subject: OCDP and Smartcards and progressing to proposed standard
Date: Mon, 4 May 1998 17:51:35 -0400
Sender: [email-masked]

Last week I attended the CardTech/SecureTech conference in Washington DC.

This set me thinking about the practicallity of acheiving OFFLINE
authorisation using a smartcard to store a private key, certificate and
associated authorisation and validity information.

Offline authorisation is interesting for two reasons:

First, it is not always possible to ensure that a terminal is connected to
the Internet. Consider that it is relatively cheap to add a smartcard reader
and solenoid to a door (order $100) but running a wire to the door can be
very expensive indeed (Installation cost typically $10-$50/meter).

Second, it is not always possible to guarantee network availability. The
question of how a system reacts when temporarily disconnected must therefore
be considered. I call this situation 'quasi-offline', the key point is to
avoid denial of service attacks in which loss of connection to head office
stops all local access.

The use of smartcards introduces a major space constraint, The private key,
certificate and validity information must certainly occupy no more than 8Kb
and preferably occupies very much less. Conventional CRLs which might grow
to millions of certificates are clearly unacceptable. Indeed the practical
limit on a CRL to fit on a smartcard is probably no more than 25 entries.

Static Certificate Distribution Points (ie those which may or may not be in
PKIX part 1) aford a brute force solution of the problem, albeit one
unlikely to be very acceptable. Simply divide the certificate population
into partitions of 35 certificates and issue a CRL for each.

The scoping part of OCDP allows the CRL partitions to be much larger.
Because partitions may be defined at the time of issue the limit of
partition size is the number of certificates actually revoked rather than a
particular number of certificates. Thus is 10% of certificates are revoked
the average partition will consist of 350 certificates (35 of which are
revoked) and the CA does 10% of the work which would be required with static
 partitions. If the proportion of revoked certificates is smaller the work
factor reduces even further!

Observe that a CA issuing such CRLs on a daily basis would on average spend
roughly an equal amount of time signing CRLs and actual certificates.
(Assume certificates are valid for a year). A scoped CRL may thus constitute
a sufficient solution to the offline revocation/statement of validity
problem.

[BTW a smartcard may aquire its CRL partition whenever it is used in an
online transaction. The smartcard having the ability to check the CRL
signature for validity and also check that it is more recent than its
current CRL partition]

CRLList allows the effort required by the CA to be reduced still further
however. Using CRLList the CA does not need to re-sign each CRL partition
each day. Only those partitions which have changed need to be re-signed.

While it may not be practical to place the CRLList on the smartcard at
present there are many 'quasi-offline' cases in which it is possible to
assume the party needing to validate a certificate has access to the CRLList
even though it is not practical to assume that they have access to
individual CRL partitions. Consider the case in which a remote office
downloads the CRLList at the start of each business day but does not have
adequate bandwidth to perform on-demand downloading of CRLs.

In summary I believe that OCDP is a very useful tool which solves a set of
important problems which are not addressed by static CDPs, OCSP, revocation
trees etc. That is not to say that these do not also have a place.

OCDP is certainly far more than a 'work arround' the Entrust patent. While
the case for OCDP becomes hard to argue against if the licensing terms
themselves prove unacceptable (at present we have only statements concerning
what those terms would be which is not the same thing), the case is still
strong if an acceptable covenant is offered and made.

The question is then how to go forward with OCDP within the IETF. I
certainly do not want to derail the PKIX part 1 standards track process, on
the other hand OCDP is quite logically a part of the PKIX CRL profile. What
I propose is that we progress the current draft towards Proposed Standard as
a separate RFC. We then have the option of 'docking' OCDP with the main
standards document as we go through the process of progressing that to Draft
Standard. Alternatively the docking maneuver could take place much later on
as part of PKIXv2.

        Phill

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Role names in certificates
Date: Mon, 4 May 1998 14:23:29 -0700
Sender: [email-masked]

I have written a draft that I have submitted as an individual (not under
IETF-PKIX).  It describes a concept of using "role" names in
certificates for several purposes that are not covered with conventional
PKIX certificates.  I have currently profiled the rfc822Name choice, but
I have heard that there is interesting in profiling the dNSName choice
also.  Cutting and pasting a little bit from the document, roles are
defined for:

* The need to sign messages on behalf of people at a domain that may or
may not have signature services available at the desktop. An outbound
message from a domain may be sent that is signed at the domain mail
server.

* The need to encrypt messages for people at a domain that may not have
encryption services available at the desktop. A message may be encrypted
for the domain mail server using a domain encrypting certificate, and
that message will be decrypted before local delivery.

* The need to encrypt messages between two mail transfer agents (MTAs).
This is different than a domain encrypting certificate, in that the
message is never encrypted or decrypted at the mail user agent (MUA)
level.

* The need to encrypt messages for a keypair that is controlled by the
domain administrator for the purposes of plaintext access. A message may
be encrypted for the domain mail server using a domain message recovery
encryption certificate for the purpose of selective plaintext recovery
by the domain administrator. This differs from a domain encrypting
certificate in that the message is not necessarily decrypted before
local delivery.

I know that the last one is going to be controversial, and this is not
an all-or-nothing proposal (you can simply not implement it).  Please
don't flame me for daring to speak its evil name, but keep an open mind
for the other uses I have listed.

This is meant to get the ball rolling in a direction where we think
about PKIX representing entities that are not necessarily a specific
end-entity, but an end-entity with a particular role or responsibility.
Any insight welcome as to how to address these issues in an alternative
way.

http://www.deming.com/users/blaker/draft-ramsdell-role-names is always
the latest version
http://www.ietf.org/internet-drafts/draft-ramsdell-role-names-00.txt is
the current draft at the IETF.

Now where's my suit...

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Mon, 04 May 1998 18:29:30 -0300
From: Rodrigo Botafogo <[email-masked]>
Organization: Certisign
To: ietf <[email-masked]>
Subject: X.509 definition
Sender: [email-masked]

I'm new to this list, so I'm sorry if this is not the right place for
this kind of question.

I'm trying to compile the X.509 Certificate and CRL Profile as defined
in the March 25, 1998 document.  I have a couple of questions about this
definition:

===========
1) In this document a certificate is defined as:

Certificate ::=  EXPLICIT  SIGNED { SEQUENCE {
             version       [0] Version DEFAULT v1,
             serialNumber  CertificateSerialNumber,
             signature  AlgorithmIdentifier,
            .
            .
            . }

I did ask some ASN.1 specialists and I was told that the keyword
EXPLICIT in this position is not a legal ASN.1 construct.  What does it
mean here?

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

2)  The following is never used in the definition:

supportedAlgorithms ATTRIBUTE ::= {
        WITH SYNTAX SupportedAlgorithm
        EQUALITY MATCHING RULE algorithmIdentifierMatch
        ID { id-at 52 } }

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

3) Would it be possible to give me some hints on how to construct the
EXTENSION table and the ALGORITHM table.

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

Thanks for any help,

Rodrigo Botafogo

Date: Mon, 4 May 1998 15:10:36 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

 >> From: Stephen Kent <[email-masked]>
 >> 
 >> When we encode anything as a DN it becomes part of the DN space,
 >> for which ITU claims responsibility, but for which we lack an
 >> authoritative registrar.

 David> ...
 David> Note that Part 1 defines DistinguishedName ::= RDNSequence,
 David> but DistinguishedName is *never* used.  The subject and issuer
 David> fields of Certificate are Name, not DistinguishedName.  The
 David> syntax is the same, but the argument can be made that the IETF
 David> has the right to define its own attributes which may appear in
 David> RDNSequence, and to serve as the registrar for it's own
 David> namespaces.

If that's valid, it certainly is not intuitive.  Applying the duck
test ("if it walks like a duck...") on the subject name would
certainly lead many people to believe that those things are
distinguished names controlled by ITU.

If that assumption is true only for some subject names and not others
(i.e., we're applying the ITUish syntax withouth also applying its
semantics) then this deserves to be pointed out very clearly.  In
particular, it becomes critical to spell out which portion of the name 
space is controlled by which registrar (real or hypothetical).

DNS names have the nice property that "everyone knows" where they come 
from.  When I see "X=foo, Y=bar" I immediately think "ITU X.mumble"
with all that seems to imply.

	paul

From: Peter Sylvester <[email-masked]>
Date: Mon, 4 May 1998 19:34:37 +0200
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

I have written this comment without reading the thread title.
having done so and assuming that the text contains some
not completely unuseful information, I send the message anyway.

> 
> I am requesting that RFC2247 names (or a functional equivalent)
> be explicitly allowed as Distinguished Names in the "subject"
> and "issuer" name fields.
> 
Subject field should contain anything you want. It is questionable
whether one should impose any restriction on subjects. The CA
(or the associated RA or naming authority) publishes its naming
plan anyway (or should plan it), otherwise it would be somewhat
difficult to interprete the content of the subject naming fields.
All X.509v3 should be allowed (not necessarily new extensions
with almost private oids)

A CA can decide to use DN or other naming extension
in whatever weird way as long as internal the names are ok and
permit (to them) to find the individual etc, and to issue new
certs for the same individual. 

Restrictions of issuer names and subject names may be the only
way to organise a conspiracy of cooperating CAs, in whatever
cross-certification environment you might imagine. Are we (who 
ever this might be?) in this context?

The problem is not really the naming in the certs,
the problem are applications (IMHO). It seems that one tries
to solve a hen and egg problem by first creating a global
unique naming structure for everything and everybody (big brother,
please leave me alone that), and then of course this automagically
solves many addressing and naming problems in applications,
finding CAs, subjects and so on. 

Reality might be different: the banking environment gives me a cert,
THEY choose their naming convention, the administration who wants
me to sign tax declarations will give me a cert. THEY choose THEIR
naming convention, my electronic passport cert (bar or ocr coded 
on a real passport :-) ) again has its own naming conventions. 

Ah, well, I forgot to read the title of the thread: 

I am not sure whether a service to OBTAIN a cert and
its status based on some info other than the cert
itself is really necessary. If an application already
knows the issuer, the subject (how?), wouldn't it be
so unreasonable to assume that it already a cert? 

The counter example is a REAL passport (at least an EU one):
one the passport there is enough information to identify
the subject (in a multinational environment), but there
is of course no cert. 

So be it. Is it necessary to fully specify the required information
in the OCSP protocol: The protocol description could just say
that the requestor gives a list of something like AVAs.
and that these "AVAs" should be sufficient to identify an entity. 
Specifying a concrete set of such "avas" seems too restrictive
to me. Doesn't this belong to a policy statement or cps? 

Peter Sylvester -- EdelWeb France

Date: Mon, 4 May 1998 12:55:06 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

> From: Stephen Kent <[email-masked]>
>
> When we encode anything as a DN it becomes part of the DN space, for which
> ITU claims responsibility, but for which we lack an authoritative
> registrar.

I see.

The question in my mind remains "can X.509 be used outside the context
of the X.500 directory?".  Or, does the IETF, which defines the syntax
of Name, RDNSequence, and RelativeDistinguishedName in PKIX Part 1,
somehow have a sub-rosa importation of the semantics of Directory
(or Distinguished) Names from X.500, including a requirement to use
the ITU as a registrar?

Note that Part 1 defines DistinguishedName ::= RDNSequence,
but DistinguishedName is *never* used.  The subject and issuer
fields of Certificate are Name, not DistinguishedName.  The syntax
is the same, but the argument can be made that the IETF has the right
to define its own attributes which may appear in RDNSequence, and
to serve as the registrar for it's own namespaces.

I would put forth the claim that a Name which began with "C=" would be
registered under the ITU, a Name which began with "DC=" would be
registered under the IETF, and a Name which began with a private
attribute "FOO=" would be registered under the organization which owns
the attribute's OID.

Dave Kemp

Date: Mon, 04 May 1998 11:17:05 -0500
From: Dale Gustafson <[email-masked]>
Organization: Datakey, Inc.
To: Marc Branchaud <[email-masked]>
CC: Ambarish Malpani <[email-masked]>, [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
Sender: [email-masked]

I think I agree with Marc :-)

Also, the standard should not preclude service providers from performing some
type of "synchronous" read of the CA database entry for the certificate in
question before returning the current cert-status within it's response.  It's
probably not a good idea to create a protocol that makes two distinctly different
services appear to be the same:

 1) read current CA cert-status
 2) read CRL(s), copies of CA data, etc.

BTW, are there other documents that present the big picture with respect to how
OCSP will scale over time?  I suspect that no matter how this is implemented
there will be a lot of wasted bandpass if clients always have to poll  for
cert-status.  Most OCSP transactions will result in "dry polls" that return no
new information to the cert user (e.g., cert-status hasn't changed since the last
time it was checked).

Intuitively, for OCSP to scale effectively there also needs to be a way to
proactively deliver cert-status updates to users of all kinds.  Presumably, such
updates would only be created/sent when a cert-status actually changes.  I assume
a push capability for cert-status could be the subject of another document
if/when appropriate.

Regards,

Dale Gustafson
Datakey, Inc.
407 West Travelers Trail
Burnsville, MN 55337
612.808.2360
612.890.2726 fax

------------------------
Marc Branchaud wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
>
> Content-Type: text/plain; charset=us-ascii
>
> Ambarish Malpani <[email-masked]> scrawled:
> >
> > Hi Marc,
> >     I don't agree with your first sentence. A CA might have a policy of
> > only updating its database periodically (for example because it keeps
> > the database itself offline and a read-only copy online). In that case,
> > even a responder that has direct access to the CAs database, might
> > still want to set nextUpdate.
> >
>
> It seems we have a different idea of what "direct access" means.  I won't
> debate that here, but consider that the meaning of nextUpdate in this case is
> different than it is in the CRL world.  In this case, there's no possibility
> of fresh information being available before nextUpdate.  As such, a client
> might get confused and apply CRL-like semantics to the value, and might try
> to query the responder before nextUpdate even though there's no way that any
> new information will be returned.
>
> I'm not saying that this "update period" information is unimportant or
> useless.  But stuffing it into a field that is to be interpreted the same
> way as a CRL's nextUpdate value is wrong.
>
> > In a spec like this, I would rather tell people what it means if they
> > do something rather than dictate policy to them.
> >
>
> I agree completely.  That's why I'm arguing so much about this stuff.
> nextUpdate has to be made clear or it will get misinterpreted and people
> will get burned by it.
>
>                 Marc
>
> +------------------------------------------------------------------------+
>  Marc Branchaud                                  \/
>  Chief PKI Architect                             /\CERT INTERNATIONAL INC.
>  [email-masked]        PKI References page:              www.xcert.com
>  604-640-6227          www.xcert.com/~marcnarc/PKI/
> +------------------------------------------------------------------------+
>   PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQB1AwUBNUpTS1rdFXNdDxPlAQHtwQMAlk3n1JOSr7Qjn/oWHF4ndBPPOcQr/2xn
> boOytgmivp0uoufW9tFS1hWubO8gAD4UJ5EbeZV7qu8Y1uQ4d5Xcl5ulG587v/0K
> fwcrXYR89qZvM9pK9D+WIo2GuVZyXFIa
> =Obaz
> -----END PGP SIGNATURE-----

Date: Mon, 4 May 1998 11:52:32 -0400
To: [email-masked] (David P. Kemp)
From: Stephen Kent <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Cc: [email-masked]
Sender: [email-masked]

Dave

>I would note that this is not an argument for or against the encoding
>of DNS/RFC822/IPAddress names as AltNames.
>
>One of the purposes of the v3 standard extensions is to enable
>separation of the function Naming Authority from the function
>Certification Authority.  In the case of DNS, etc, the existing naming
>mechanisms assign authoritative, unique names.  Those names remain just
>as authoritative and unique when encoded as RDNs
>(e.g. DC=sun, DC=east, DC=bcn, CN=anne) as when encoded as AltNames
>(e.g. DNSName=anne.bcn.east.sun.com).

I disagree, though I understand your point re naming authorities and CAs.
It is a well established distinction in the X.500 arena, but X.500 is not
being widely adopted and we have lost years of possible deployment
opportunities because of the inability of folks to resolve various aspects
of X.500.  Look back at all the traffic re the NADF and ask how we are
better off today as a result.

When we encode anything as a DN it becomes part of the DN space, for which
ITU claims responsibility, but for which we lack an authoritative
registrar.  When the equivalent data is encoded in its appropriate AltName,
it belongs to a space that the ITU acknowledges is managed by another
standards body (IETF for DNS, RFC 822, and IP addresses) and for which we
do have authoritative registrars. Thus it seems both natural and important
that we make use of these name forms.  The mapping to DNs for other name
forms is a hack to accommodate DNS data in X.500 directories.  PKIX
explicitly acknowledges that we are developing certificate standards that
do not rely on the existance of X.500 directories.

Steve

Date: Mon, 4 May 1998 10:56:23 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[email-masked]>
Reply-To: Anne Anderson - Sun Microsystems <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

There currently is no way to encode DNS and other alternative
names as RDNs that is supported by PKIX.  If there were, then
I agree completely with Dave's argument.

The DC= format is in RFC2247, and this has not been incorporated
into either X.501/X.509 or PKIX.

I am requesting that RFC2247 names (or a functional equivalent)
be explicitly allowed as Distinguished Names in the "subject"
and "issuer" name fields.

-Anne Anderson

>>Date: Mon, 4 May 1998 10:11:44 -0400
>>From: [email-masked] (David P. Kemp)
>>To: [email-masked]
>>Subject: Re: [IETF-PKIX] OCSP: Method of Identifying 
Certificates
>>
>>> From: Stephen Kent <[email-masked]>
>>> 
>>> On a separate note: Bob, I observe that we have essentially no
>>> authoritative sorce for DNs, but we do have authoritative 
sources (existing
>>> infrastrustures) for DNS names, RFC822 names, and IP 
addresses.  These have
>>> a much better basis for authoritative, unique names (modulo 
NAT!) than DNs.
>>
>>Steve,
>>
>>I would note that this is not an argument for or against the 
encoding
>>of DNS/RFC822/IPAddress names as AltNames.
>>
>>One of the purposes of the v3 standard extensions is to enable
>>separation of the function Naming Authority from the function
>>Certification Authority.  In the case of DNS, etc, the existing 
naming
>>mechanisms assign authoritative, unique names.  Those names 
remain just
>>as authoritative and unique when encoded as RDNs
>>(e.g. DC=sun, DC=east, DC=bcn, CN=anne) as when encoded as 
AltNames
>>(e.g. DNSName=anne.bcn.east.sun.com).
>>
>>Dave Kemp

Anne Anderson                  Email: [email-masked]
Sun Microsystems Laboratories  Tel: (978) 442-0928
2 Elizabeth Drive, CHL03-205   Fax: (978) 250-5067
Chelmsford, MA 01824 USA

Date: Mon, 4 May 1998 10:11:44 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

> From: Stephen Kent <[email-masked]>
> 
> On a separate note: Bob, I observe that we have essentially no
> authoritative sorce for DNs, but we do have authoritative sources (existing
> infrastrustures) for DNS names, RFC822 names, and IP addresses.  These have
> a much better basis for authoritative, unique names (modulo NAT!) than DNs.

Steve,

I would note that this is not an argument for or against the encoding
of DNS/RFC822/IPAddress names as AltNames.

One of the purposes of the v3 standard extensions is to enable
separation of the function Naming Authority from the function
Certification Authority.  In the case of DNS, etc, the existing naming
mechanisms assign authoritative, unique names.  Those names remain just
as authoritative and unique when encoded as RDNs
(e.g. DC=sun, DC=east, DC=bcn, CN=anne) as when encoded as AltNames
(e.g. DNSName=anne.bcn.east.sun.com).

Dave Kemp

Date: Sat, 02 May 1998 17:38:05 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-ipki-part4-03.txt
Sender: [email-masked]

For the information of the list, this newly-posted I-D is the final version
of the "Part 4" document, for forwarding to the RFC Editor with a request
for publication as an Informational RFC as agreed in Washington.  Changes
since the 02 version are all editorial in nature.

Warwick

At 10:01 AM 4/29/98 -0400, [email-masked] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the Public-Key Infrastructure (X.509) Working
Group of the IETF.
>
>	Title		: Internet X.509 Public Key Infrastructure 
>                          Certificate Policy and Certification Practices
Framework
>	Author(s)	: W. Ford, S. Chokhani
>	Filename	: draft-ietf-pkix-ipki-part4-03.txt
>	Pages		: 45
>	Date		: 28-Apr-98

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Date: Sat, 2 May 1998 11:27:42 -0400
To: Anne Anderson - Sun Microsystems <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Cc: [email-masked]
Sender: [email-masked]

Folks,

I agree with Anne, which is why I am still opposed to mandating use of a DN
in the Issuer field for ALL PKIX compliant certs.  We ought not be putting
DNS names, Ip addresses, and RFC 822 names in DNs after having gone to the
trouble of creating altName construsts to accommoadte them.  DNs are
already mushy enough (see my comment below wrt who is authoritative for
DNs) without further complicating matters.

The primary arguments in favor of this seem to be based on three valid, but
remediable, concerns (although I admit to having been out of touch and
maybe I missed a different class of concern):

	1. we have other protocols (e.g., S/MIME and TLS) that refer only
to DNs (rather than altnames) in several places for processing

	2.  we have repositories (e.f., LDAP) that use DNs as indices

	3. internal to PKIX part 1, we have instances where we assume an
issuer DN (e.g., for one choice of how we do back pointers from a subject
to an issuer cery)

In the case of 1, we can fix this by having the protocols deal with either
the base cert fields or altName fields.  After all, if we don't start doing
this at some time, why bother having altName fields anyway.  For case 2, I
note that LDAP is not the only game in  town.  We have a profile for
storing certs and CRLs in DNS and it knows how to make use of DNS names and
IP addresses as indices.  Thus it seems unduly narrow to mandate use of DNs
for all PKIX certs when there are other, well-established repositories that
are oriented toward other indices.  Finally, we can fix PKIX part 1 to be
more liberal in dealing with issuer name forms.  After all, it's our
standard and we can fix it.

On a separate note: Bob, I observe that we have essentially no
authoritative sorce for DNs, but we do have authoritative sources (existing
infrastrustures) for DNS names, RFC822 names, and IP addresses.  These have
a much better basis for authoritative, unique names (modulo NAT!) than DNs.

Steve

To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt 
Date: Fri, 01 May 1998 15:57:40 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

 <[email-masked]> scrawled:
> 
> I agree with Mike and Paul that the first three sentences (not lines)
> be deleted.  I also believe that the final sentence should go, because
> it is content-free: it doesn't add anything to the specification to
> say clients SHOULD (or MUST) use their own local policies - what else
> would they use?

Just because it's obvious to us technocrats doesn't mean that it shouldn't 
be spelt out in the standard.  We shouldn't assume that everyone reading 
the document will know these things.

> If the implication is that clients SHOULD have a local
> policy of ignoring the contents of nextUpdate, I strongly disagree.
> 

Happily, that isn't what I'm getting at.  Clients can and will have a local 
policy that tells them how to interpret things.  If we're going to allow a
nextUpdate field, we have to be very clear about what it means so that 
clients' policies aren't mislead.

> I believe that nextUpdate should be recommended (SHOULD) rather than
> purely optional (MAY).  Other than that, I agree with the center
> sentence of Marc's proposed text.  Which leaves:
> 
>   The nextUpdate field SHOULD be included in the response.
>   When it is included, the nextUpdate field indicates that fresh
>   revocation information will be available no later than the specified
>   time, and may be available sooner.
> 

Making it a SHOULD will cause interoperability problems.  Implementations 
for which nextUpdate is meaningless will be forced to include a dummy 
nextUpdate value to be compatible with all the clients that think that 
nextUpdate SHOULD be there and so they're not the ones that are broken.

nextUpdate has to be OPTIONAL.  How's about this:

  The nextUpdate field MAY be included if the responder has an accurate
  estimate of the latest time at which it will receive fresh information.
  When it is included, the nextUpdate field indicates that fresh revocation
  information will be available no later than the specified time, and may be
  available sooner.  The value of nextUpdate SHOULD NOT be interpreted to
  imply anything about the duration of a response's validity.  Client
  implementations MUST be able to process responses with or without a
  nextUpdate value.

That last sentence is an implication of the optional nature of the field, but
I think it's important because it emphasizes that client's shouldn't just 
blindly rely on nextUpdate.  That'll be more likely to happen if clients are 
told to expect respopnses that might not have a nextUpdate value.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

To: Ambarish Malpani <[email-masked]>
Cc: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt 
Date: Fri, 01 May 1998 15:57:16 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

Ambarish Malpani <[email-masked]> scrawled:
> 
> Hi Marc,
>     I don't agree with your first sentence. A CA might have a policy of
> only updating its database periodically (for example because it keeps
> the database itself offline and a read-only copy online). In that case,
> even a responder that has direct access to the CAs database, might
> still want to set nextUpdate.
> 

It seems we have a different idea of what "direct access" means.  I won't
debate that here, but consider that the meaning of nextUpdate in this case is
different than it is in the CRL world.  In this case, there's no possibility
of fresh information being available before nextUpdate.  As such, a client
might get confused and apply CRL-like semantics to the value, and might try
to query the responder before nextUpdate even though there's no way that any
new information will be returned.

I'm not saying that this "update period" information is unimportant or 
useless.  But stuffing it into a field that is to be interpreted the same 
way as a CRL's nextUpdate value is wrong.

> In a spec like this, I would rather tell people what it means if they
> do something rather than dictate policy to them.
> 

I agree completely.  That's why I'm arguing so much about this stuff.  
nextUpdate has to be made clear or it will get misinterpreted and people 
will get burned by it.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date: Fri, 01 May 1998 15:14:08 -0700
To: [email-masked] (David P. Kemp), [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate,   producedAt
Sender: [email-masked]

I agree with Dave's proposed text.

Are there any furhter comments out there on Ambarish's positions?  We want
to get these issues off the table for a new draft.

At 01:45 PM 5/1/98 -0400, David P. Kemp wrote:
>> From: Paul Hoffman / IMC <[email-masked]>
>> 
>> At 03:34 PM 4/30/98 -0700, Michael Myers wrote:
>> >For these reasons, I would agree with the proposed text with the first
>> >three lines deleted.  There is no way for anyone to implement a client
that
>> >would enforce them.
>> 
>> I agree with Mike. The source of the data is not important here, and trying
>> to force heuristics on it seems inappropriate.
>
>I agree with Mike and Paul that the first three sentences (not lines)
>be deleted.  I also believe that the final sentence should go, because
>it is content-free: it doesn't add anything to the specification to
>say clients SHOULD (or MUST) use their own local policies - what else
>would they use?  If the implication is that clients SHOULD have a local
>policy of ignoring the contents of nextUpdate, I strongly disagree.
>
>I believe that nextUpdate should be recommended (SHOULD) rather than
>purely optional (MAY).  Other than that, I agree with the center
>sentence of Marc's proposed text.  Which leaves:
>
>  The nextUpdate field SHOULD be included in the response.
>  When it is included, the nextUpdate field indicates that fresh
>  revocation information will be available no later than the specified
>  time, and may be available sooner.
>
>
>This is consistent with PKIX part 1 section 5.1.2.5, which says:
>
>  This field indicates the date by which the next CRL will be issued.
>  The next CRL could be issued before the indicated date, but it will
>  not be issued any later than the indicated date.
>
>
>

From: Stephen Samson <[email-masked]>
To: [email-masked]
Subject: Entrust Technologies Announces License Terms for CRL Distribution Points Patent
Date: Fri, 1 May 1998 15:14:27 -0400 
Sender: [email-masked]

My personal apologies for any difficulty you have encountered accessing the
summary of license terms.

Entrust Technologies previously published the information in PDF file format
on our website. (I personally checked the links over 20 times on our
internal site in order to be convinced there would be no problems when we
published live.) Nevertheless, subsequent to the posting, we have been
informed that some browsers do not support the PDF version we used. To
correct the problem, the summary is now published in HTML so you should be
able to view regardless of the browser being used.

Please follow the link below to our announcement and then follow either
pointer named "view now" or "view". Thank you for your patience and
understanding.

Steve Samson

> ----------
> From: 	Stephen Samson
> Sent: 	30 April, 1998 1:26 PM
> To: 	[email-masked]'
> Cc: 	'Jeff Schiller'; 'Steve Kent'; 'Tim Polk'; 'Warwick Ford'
> Subject: 	Entrust Technologies Announces License Terms for CRL
> Distribution Points Patent
> 
> Members of the IETF Community;
> 
> Entrust Technologies is very pleased to provide details of its previously
> announced royalty-free license for the CRL Distribution Points Patent.
> 
> By following the link:  http://www.entrust.com/products/patent.htm to our
> website, you will be able to read a summary of the license terms. In the
> spirit of open Standards, Entrust has fashioned the license in fair,
> reasonable and equitable terms that should appeal to all interested
> parties.
> 
> A party interested in taking a license should contact the author directly,
> so that appropriate license documentation can be drafted. Please direct
> any questions to:
> 
> Steve Samson
> 
> Entrust Technologies Inc.
> 750 Heron Rd.,  8th Floor
> Ottawa, Ontario, Canada, K1V 1A7
> 
> voice:			613-247-3725
> fax:			613-247-3412
> email:			[email-masked]
> Entrust Validation String:	SCKM-HQDL-X75G
> 

From: Carlisle Adams <[email-masked]>
To: Stephen Samson <[email-masked]>, [email-masked], "'Michael Myers'" <[email-masked]>
Cc: Jeff Schiller <[email-masked]>, Steve Kent <[email-masked]>, Tim Polk <[email-masked]>, Warwick Ford <[email-masked]>
Subject: RE: Entrust Technologies Announces License Terms for CRL Distribu tion Points Patent
Date: Fri, 1 May 1998 14:59:19 -0400 
Sender: [email-masked]

All,

After some frantic searching (and with the kind assistance of some external
interested parties, Paul Hoffman in particular), the problem has been
located.  Last Tuesday we moved our web site from a host that was externally
managed to one that was internally managed.  However, the update to the DNS
mapping tables did not happen correctly and therefore was not being
propagated around the net.  Consequently, when people went to
www.entrust.com they hit the ip address for our old site instead of our new
site.  The result of this was that when we put the patent terms on the site
on Thursday, nobody outside Entrust could see them because they were getting
to our old site (which has not been updated since last Monday because it was
assumed that the DNS servers were mapping people to the new site...).

We've now updated the old site, so everyone should have access to the Ts &
Cs regardless of the site (old or new) to which DNS points you.  We will, of
course, also get the correct update to the mapping tables done ASAP.

We all sincerely apologize for this confusion at such a critical time.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

> ----------
> From: 	Michael Myers[SMTP:[email-masked]]
> Sent: 	Thursday, April 30, 1998 2:14 PM
> To: 	Stephen Samson; [email-masked]
> Cc: 	Jeff Schiller; Steve Kent; Tim Polk; Warwick Ford
> Subject: 	Re: Entrust Technologies Announces License Terms for CRL
> Distribution Points Patent
> 
> Stephen,
> 
> It appears the text is not yet posted at this URL.  On reference, I
> receive
> a page that states:
> 
> "Our Apologies
> 
> This link is either outdated or missing at this time. Please refer
> yourself
> to our homepage or feel free to use the sitemap."
> 
> Mike
> 
> 
> 
> At 01:26 PM 4/30/98 -0400, Stephen Samson wrote:
> >Members of the IETF Community;
> >
> >Entrust Technologies is very pleased to provide details of its previously
> >announced royalty-free license for the CRL Distribution Points Patent.
> >
> >By following the link:  http://www.entrust.com/products/patent.htm to our
> >website, you will be able to read a summary of the license terms. In the
> >spirit of open Standards, Entrust has fashioned the license in fair,
> >reasonable and equitable terms that should appeal to all interested
> parties.
> >
> >A party interested in taking a license should contact the author
> directly,
> >so that appropriate license documentation can be drafted. Please direct
> any
> >questions to:
> >
> >Steve Samson
> >
> >Entrust Technologies Inc.
> >750 Heron Rd.,  8th Floor
> >Ottawa, Ontario, Canada, K1V 1A7
> >
> >voice:			613-247-3725
> >fax:			613-247-3412
> >email:			[email-masked]
> >Entrust Validation String:	SCKM-HQDL-X75G
> >
> >
> 

Date: Fri, 01 May 1998 10:54:18 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
Sender: [email-masked]

Hi Marc,
    I don't agree with your first sentence. A CA might have a policy of
only updating its database periodically (for example because it keeps
the database itself offline and a read-only copy online). In that case,
even a responder that has direct access to the CAs database, might
still want to set nextUpdate.

In a spec like this, I would rather tell people what it means if they
do something rather than dictate policy to them.

Regards,
Ambarish

Marc Branchaud wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Content-Type: text/plain; charset=us-ascii
> 
> Mike, Paul;
> 
> Yer right, specifying just "CRL" is way too restrictive.  Just to make sure
> we agree, the text is the same as before with the first two sentecnes
> removed, i.e.:
> 
>   The nextUpdate field SHOULD NOT be included if the responder has direct
>   access to the CA's revocation database (i.e. it can obtain revocation
>   information in real time).  When it is included, the nextUpdate field
>   SHOULD be interpreted to mean that fresh revocation information should be
>   available no later than nextUpdate's time, and may be available sooner.  In
>   general, nextUpdate is not a guarantee of the lifetime of a response's
>   validity.  Clients SHOULD use their own local policies to determine how
>   long they believe a response to be valid, regardless of the presence of the
>   nextUpdate field in the response.
> 
> S'cool?
> 
>                 Marc
> 
> 
-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Fri, 1 May 1998 13:45:56 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate,  producedAt
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> 
> At 03:34 PM 4/30/98 -0700, Michael Myers wrote:
> >For these reasons, I would agree with the proposed text with the first
> >three lines deleted.  There is no way for anyone to implement a client that
> >would enforce them.
> 
> I agree with Mike. The source of the data is not important here, and trying
> to force heuristics on it seems inappropriate.

I agree with Mike and Paul that the first three sentences (not lines)
be deleted.  I also believe that the final sentence should go, because
it is content-free: it doesn't add anything to the specification to
say clients SHOULD (or MUST) use their own local policies - what else
would they use?  If the implication is that clients SHOULD have a local
policy of ignoring the contents of nextUpdate, I strongly disagree.

I believe that nextUpdate should be recommended (SHOULD) rather than
purely optional (MAY).  Other than that, I agree with the center
sentence of Marc's proposed text.  Which leaves:

  The nextUpdate field SHOULD be included in the response.
  When it is included, the nextUpdate field indicates that fresh
  revocation information will be available no later than the specified
  time, and may be available sooner.

This is consistent with PKIX part 1 section 5.1.2.5, which says:

  This field indicates the date by which the next CRL will be issued.
  The next CRL could be issued before the indicated date, but it will
  not be issued any later than the indicated date.

Date: Fri, 1 May 1998 12:37:33 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[email-masked]>
Reply-To: Anne Anderson - Sun Microsystems <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

I think it is unreasonable to require ALL applications to use
X.501-style names UNLESS there is support for conversion of
alternate names to an X.501 format, such as RFC2247.

Example: Using DNS as my PKI certificate repository

In this case, I am known as "anne.bcn.east.sun.com".  My PKI
hierarchy may look as follows:

  CA "sun.com" issues and stores certificates for
     CA "east.sun.com", which issues and stores certificates for
        "CA bcn.east.sun.com", which issues certificates for
           "anne.bcn.east.sun.com"

The DNS protocols know how to find "anne.bcn.east.sun.com", "bcn.east.sun.com",
"east.sun.com", and "sun.com" from any host that supports DNS.  DNS is a working
global naming hierarchy and repository (sort of what X.500 wanted to be, but 
never became, although more specialized).

If DNS does what I need (and in this case it does), why should I have to
make up a set of X.501 Distinguished Names that have no
function in either locating the certificates that I need or in
reflecting the trust chain?  I would rather leave issuer and subject
empty, and user issuerAltName and subjectAltName with the DNS names
and chain through them.  If I present a server with a DNS name, I
would like the server to be able to locate my certificate using that
name and to verify the certificate chain using that name.

If all names must be expressible in X.501 format, then at least allow
RFC2247 names (e.g. DC=sun, DC=east, DC=bcn, CN=anne) !!!

Anne Anderson                  Email: [email-masked]
Sun Microsystems Laboratories  Tel: (978) 442-0928
2 Elizabeth Drive, CHL03-205   Fax: (978) 250-5067
Chelmsford, MA 01824 USA

To: Michael Myers <[email-masked]>
Cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt 
Date: Fri, 01 May 1998 09:16:02 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

Mike, Paul;

Yer right, specifying just "CRL" is way too restrictive.  Just to make sure
we agree, the text is the same as before with the first two sentecnes
removed, i.e.:

  The nextUpdate field SHOULD NOT be included if the responder has direct
  access to the CA's revocation database (i.e. it can obtain revocation
  information in real time).  When it is included, the nextUpdate field
  SHOULD be interpreted to mean that fresh revocation information should be
  available no later than nextUpdate's time, and may be available sooner.  In
  general, nextUpdate is not a guarantee of the lifetime of a response's
  validity.  Clients SHOULD use their own local policies to determine how
  long they believe a response to be valid, regardless of the presence of the
  nextUpdate field in the response.

S'cool?

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date: Fri, 01 May 1998 09:57:57 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Denis,

I would like to restrict the means of identifying the certificate to the =
Issuer DN,
Hash(IssuerPublicKey) and CertSerialNumber, as opposed to allowing =
either=20
the DN or the altSubjectName.

The reason is that I do not believe that we have a well-understood and
adequate characterization of the semantics of alternate names at present =
to
be sure that they are globally unique, and hence we cannot be sure that=20
they will serve the purpose intended.

I will start another thread on the subject of alternate name semantics to =
avoid
cluttering this one, but I have not seen anyone advance a compelling =
argument
as to why DNs are not sufficient, nor any good reason why a CA would not
always have a DN (as opposed to end entities.)

DNs are sufficient, they are always there, and the use of a single DN=20
for database indexing purposes is much more definitive that having=20
to index all possible alternate names, just in case that's the way the =
certificate=20
is to be identified.

What possible advantage would be gained from using alternate names=20
in this context?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,=20
although a step in the right direction, will not prove=20
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

>>> Denis Pinkas <[email-masked]> 04/30 12:12 PM >>>
Ambarish Malpani wrote:
=20
> Hi All,
>     Would like to get closure on the method of identifying
> certificates. I think nobody has any objections to including the
> issuer's public key in the information that is used to identify the
> issuer. The main point of contention is whether to send the whole
> DN or the hash of the DN.
>=20
> Tim, hopefully your issue with sending over the hash of the DN can
> be addressed by canonicalizing the issuer's DN before hashing it
> (are there any such canonicalization rules)?
>=20
> So, here are the options:
>=20
> 1. Hash(IssuerDN and IssuerPublicKey) and CertSerialNumber
> 2. Hash(IssuerDN), Hash(IssuerPublicKey) and CertSerialNumber
> 3. IssuerDN, Hash(IssuerPublicKey) and CertSerialNumber

>From the option that are proposed, option 3 is the only one that is
working for all environments.=20

The argument is that neither Hash(IssuerDN) nor Hash(IssuerDN and
IssuerPublicKey) can be used to find which CA has issued a certificate
unless you get an hint by some other means.

In the option 3, we should allow either IssuerDN or alternate name to be
used, since I do not think it is appropriate to mandate DNs for CAs (no
argument has been given on the list up to now to explain why DNs would
work better that alternate names as long as the latter are unique).

Regards,

Denis

> What are the opinions of the group? I would like to have a quick
> flurry of opinions before we decide to go one way or the other.
>=20
> Regards,
> Ambarish

--=20
      Denis Pinkas     Bull S.A.          mailto:[email-masked]=20
      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