Subject: Re: Unknown string type (28) and content of private enterprise extensions.
From: [email-masked] (Jeff Weinstein)
To: "Anil R. Gangolli" <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, [email-masked], [email-masked]
Date: Fri, 28 Feb 1997 14:49:34 -0800

Anil R. Gangolli wrote:
> 
> David P. Kemp wrote:
> >   A Verisign cert request included the following OIDs:
> >
> >         2.16.840.1.113730.1.1
> >         2.16.840.1.113730.1.8
> >         2.16.840.1.113730.1.13
> >
> >   RSADSI is 1.2.840.113549, but who is 2.16.840.1.113730, and where are
> >   the OIDs under it defined?
> 
> 2.16.840.1.113730 is Netscape Communications Corp.
> 
> I will ask the keeper of the Netscape registry to make sure the
> definitions are
> available from our web site.

  You can find the definitions for these oids at:

	http://home.netscape.com/eng/security/cert-exts.html

	--Jeff

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

Date: Fri, 28 Feb 1997 17:18 -0500
From: "Simonetti David" <[email-masked]>
To: [email-masked]
Subject: MISSI/FORTEZZA Information

For those of you interested, information related to the DoD MISSI project 
can be found at the following location:

http://www.armadillo.huntsville.al.us/

If you follow the hypertext pointer "Documents", amongst other information 
you will find lists of "SDN" documents.  Appearing under "MISSI v2.0 
Architecture Documents" are SDN.700, which provides the INFOSEC arc object 
registry, and SDN.706, which provides the MISSI V3 X.509 Certificate and V2 
CRL profile.

David Simonetti
Booz-Allen & Hamilton Inc.
900 Elkridge Landing Road
Linthicum, MD 21090

Date: Fri, 28 Feb 1997 13:36:38 -0800
To: [email-masked] (David P. Kemp), [email-masked], [email-masked]
From: Peter Williams <[email-masked]>
Subject: Re: Unknown string type (28) and content of private enterprise extensions.

Folks,

Its very hard to conform to something which is not ratified formally,
even when one wants to, as I do, and have commented here before now
about the lack of formality of the base material. As part 
of I-D requirements, of course we do not claim to
conform to an I-D, such as PKIX; its unethical within the IETF
spirit. I do promote PKIX all over the place, as "the" forum.

I asked the ISO rapporteur for advice about conformance, when he worked at
Nortel/BNR at the time, (a one Warwick Ford, who now runs our formal standards
effort at VeriSign, and who also performs the PKIX co-chair role to our
mutual benefits)
and he advised: use the oids in the then current draft, (known as the final
text) and
move to the standard oids when they become stable/if-they-change and
available in software.
This is why we use the {id-ce 3} oid, and syntax, as defined by ISO (though
I tried very hard
last week to phase this out...in favour of the new definition, but failed
for interworking
reasons). It is non-critical in all public-purpose service offerings; those
who do not know it, can safely ignore it. Those who rely upon it, may do so.

So, for now, we are  using oids for which there is end-user software available
to handle the syntaxes and enforce the semantics. Having openly participated
here in this profiling activity, Im waiting for PKIX-1 (18 months, Im waiting)
before making a move to standardise the public elemnents of cert content for
universal benefit in the internet spirit. I personally cant do as DOD/US
Gov, and
agitate for a concensus standard in public, whilst defining private
material for its
own use for similar general purposes.
 
There is a formal repository available for OIDS; its called ISO,
and ANSI (for US jurisdiction); these are recognised by US govt, formally,
as legitimate international and national organizations. The repositories
are based upon formal registration authority procedures, and perform with
due process,
as outlined in the X/650/660 standards) as regards to publication of
repository material,
and dispute resolution during primitive value assignment. Ive never before
heard of an
attack on the integrity of their processes.

2.16.840.1.113730 is the oid for Netscape,I believe, an organization
authorised to thus act as an oid registry for its private purposes, 
as published by ANSI, and to millions of people on Netscape SSL-related
technology
disclosure pages. As a ssl-talk list recipient, David, you must
have seen this pointer go by several times...

As I remember, { 1 3 6 1 4 1  311 2 1 10} is the Microsoft registered oid used
as part of the enforcement of the semantics of the software publishers trust
domain underpining the Authenticode initiative to provide accountability and
discretionary access control capability against malicious java or other applet
technologies during the download sequence to corporate domains, and/or
workstations. Full details are available on request to Microsoft, when
one applies to join the programme; GTE and VeriSign were the founding
CA parties, FYI. see http://www.microsoft.com/workshop/prog/security/
 
Peter.

At 12:15 PM 2/28/97 -0500, David P. Kemp wrote:
>> From: Paul Kierstead <[email-masked]>
>> 
>> Is Universal String TAG 28? My (admittidly old) documents do not refer
>> to UniversalString. Or BMPString, for that matter. 
>> 
>> More along these lines .... the Verisign certificates have private
>> enterprise extensions ( { 1 3 6 1 4 1 311 2 1 27}  and  { 1 3 6 1 4 1
>> 311 2 1 10}  ). Anybody know the content format of these extensions?
>> 
>> Any concrete knowledge would be greatly appreciated ....
>
>
>Finding concrete knowledge is certainly much more difficult than
>it should be.  Ideally there would be a repository of this information
>somewhere that anyone could consult, but if there is one, I don't know
>about it.  So we just limp along, trading tidbits of information one
>piece at a time.
>
>Here are the universal-class definitions from the 1993 version of X.680:
>
>				/*  0: reserved for end marker */
>#define BOOLEAN		0x01	/*  1: TRUE or FALSE */
>#define INTEGER		0x02	/*  2: Arbitrary precision integer */
>#define BITSTRING	0x03	/*  2: Sequence of bits */
>#define OCTETSTRING	0x04	/*  4: Sequence of bytes */
>#define NULLTAG		0x05	/*  5: NULL */
>#define OID		0x06	/*  6: Object Identifier (numeric sequence) */
>#define OBJDESCRIPTOR	0x07	/*  7: Object Descriptor (Graphic String) */
>#define EXTERNAL	0x08	/*  8: External / Instance Of */
>#define REAL		0x09	/*  9: Real (Mantissa * Base^Exponent) */
>#define ENUMERATED	0x0a	/* 10: Enumerated */
>#define EMBEDDED_PDV	0x0b	/* 11: Embedded Presentation Data Value */
>#define SEQUENCE	0x10	/* 16: Constructed Sequence / Sequence Of */
>#define SET		0x11	/* 17: Constructed Set / Set Of */
>#define NUMERICSTR	0x12	/* 18: Numeric String (digits 0-9 and space) */
>#define PRINTABLESTR	0x13	/* 19: Printable String (74 chars) */
>#define TELETEXSTR	0x14	/* 20: T.61 String (Teletex) */
>#define VIDEOTEXSTR	0x15	/* 21: Videotex String */
>#define IA5STR		0x16	/* 22: Int'l Alphabet 5 (ISO 646 - 128 chars) */
>#define UTCTIME		0x17	/* 23: UTC Time */
>#define GENERALIZEDTIME	0x18	/* 24: Generalized Time */
>#define GRAPHICSTR	0x19	/* 25: Graphic String */
>#define VISIBLESTR	0x1a	/* 26: Visible String (ISO 646 - 95 chars) */
>#define GENERALSTR	0x1b	/* 27: General String */
>#define UNIVERSALSTR	0x1c	/* 28: Universal String (4 octets/char) */
>#define CHARACTERSTR	0x1d	/* 29: Unrestricted Character String */
>#define BMPSTR		0x1e	/* 30: Basic Multilingual Plane (2 octets) */
>				/* 31: High tag number follows in radix 128 */
>
>
>And here is a little info about the root of the OID tree:
>
>/*
> * ITU(0) includes: Recommendation(0), Question(1), Administration(2),
> *             Network-Operator(3), Identified-Organization(4)
> *
> * ISO(1) includes: Standard(0), Member-Body(2), Identified-Organization(3)
> *   1 2 includes: us(840), ca(124)
> *   1 3 includes: osinet(4), gosip(5), dod(6), oiw(14)
> *
> * JOINT-ISO-CCITT(2) includes: Directory Service(5), Country(16)
> *   2 16 includes: us(840), ca(124)
> *   2 16 840 includes: organization(1), mhs-md(2), state(3)
> *
> * From ISO/IEC 9594-2 (X.501) "The Directory: Models"
> *
> *   Directory Service         ds ::= {joint-iso-ccitt(2) ds(5)}
> *   attributeType          id-at ::= {ds 4}
> *   algorithm                    ::= {ds 8}
> *   certificateExtension   id-ce ::= {ds 29}  (from AM 4)
> *
> * From ISO/IEC 9594-6 (X.520) "The Directory: Selected Attribute Types"
> *   id-at-commonName             ::= {id-at 3}
> *   id-at-countryName            ::= {id-at 6}
> *   id-at-localityName           ::= {id-at 7}
> *   id-at-stateOrProvinceName    ::= {id-at 8}
> *   id-at-organizationName       ::= {id-at 10}
> *   id-at-organizationalUnitName ::= {id-at 11}
> */
>
>
>So you can see that {1 3 6 ...} is in the ISO dod arc, but I can't help
>you from there.  MISSI uses the joint-iso-itu arc for dod:
>{joint (2) country (16) us (840) organization (1) gov (101) dod (2)}.
>
>----------------------------------
>
>My questions are:
>
>1)  draft-ietf-asid-inetorgperson-00.txt defines these OIDs:
>
>	2.16.840.1.113730.3.1.1  carLicense"
>	2.16.840.1.113730.3.1.2  departmentNumber"
>	2.16.840.1.113730.3.1.3  employeeNumber"
>	2.16.840.1.113730.3.1.4  employeeType"
>	2.16.840.1.113730.3.2.2  inetOrgPerson"
>
>  A Verisign cert request included the following OIDs:
>
>	2.16.840.1.113730.1.1
>	2.16.840.1.113730.1.8
>	2.16.840.1.113730.1.13
>
>  RSADSI is 1.2.840.113549, but who is 2.16.840.1.113730, and where are
>  the OIDs under it defined?
>
>
>2)  The 1 December 1996 Draft Amendment to X.509 lists certificate
>    extensions id-ce 9, 14-21, 23-24, 27-36 and lists id-ce 34 as deprecated.
>    It also includes the following comment:
>
>   "The following OBJECT IDENTIFIERS are not used by this specification:"
>    id-ce 2-8, 10-13, 22, 25, 26.
>
>    That comment is not as helpful as it could be, since it says
>    nothing about id-ce 1, and doesn't point to the specification that
>    *does* use id-ce 2-8 ...
>
>    The same Verisign cert request mentioned above included 2.5.29.3
>    (id-ce 3).  That extension is pretty useless if it isn't documented
>    somewhere, and it would be nice if X.509 DAM 1 pointed to the
>    appropriate specification.
>
>

Sender: [email-masked]
Date: Fri, 28 Feb 1997 10:20:47 -0800
From: "Anil R. Gangolli" <[email-masked]>
Organization: Netscape Server Product Development
To: "David P. Kemp" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Unknown string type (28) and content of private enterprise extensions.

David P. Kemp wrote:
> My questions are:
> 
> 1)  draft-ietf-asid-inetorgperson-00.txt defines these OIDs:
> 
>         2.16.840.1.113730.3.1.1  carLicense"
>         2.16.840.1.113730.3.1.2  departmentNumber"
>         2.16.840.1.113730.3.1.3  employeeNumber"
>         2.16.840.1.113730.3.1.4  employeeType"
>         2.16.840.1.113730.3.2.2  inetOrgPerson"
> 
>   A Verisign cert request included the following OIDs:
> 
>         2.16.840.1.113730.1.1
>         2.16.840.1.113730.1.8
>         2.16.840.1.113730.1.13
> 
>   RSADSI is 1.2.840.113549, but who is 2.16.840.1.113730, and where are
>   the OIDs under it defined?

2.16.840.1.113730 is Netscape Communications Corp.

I will ask the keeper of the Netscape registry to make sure the
definitions are
available from our web site.  

--a.

Date: Fri, 28 Feb 1997 12:15:15 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked]
Subject: Re: Unknown string type (28) and content of private enterprise extensions.

> From: Paul Kierstead <[email-masked]>
> 
> Is Universal String TAG 28? My (admittidly old) documents do not refer
> to UniversalString. Or BMPString, for that matter. 
> 
> More along these lines .... the Verisign certificates have private
> enterprise extensions ( { 1 3 6 1 4 1 311 2 1 27}  and  { 1 3 6 1 4 1
> 311 2 1 10}  ). Anybody know the content format of these extensions?
> 
> Any concrete knowledge would be greatly appreciated ....

Finding concrete knowledge is certainly much more difficult than
it should be.  Ideally there would be a repository of this information
somewhere that anyone could consult, but if there is one, I don't know
about it.  So we just limp along, trading tidbits of information one
piece at a time.

Here are the universal-class definitions from the 1993 version of X.680:

				/*  0: reserved for end marker */
#define BOOLEAN		0x01	/*  1: TRUE or FALSE */
#define INTEGER		0x02	/*  2: Arbitrary precision integer */
#define BITSTRING	0x03	/*  2: Sequence of bits */
#define OCTETSTRING	0x04	/*  4: Sequence of bytes */
#define NULLTAG		0x05	/*  5: NULL */
#define OID		0x06	/*  6: Object Identifier (numeric sequence) */
#define OBJDESCRIPTOR	0x07	/*  7: Object Descriptor (Graphic String) */
#define EXTERNAL	0x08	/*  8: External / Instance Of */
#define REAL		0x09	/*  9: Real (Mantissa * Base^Exponent) */
#define ENUMERATED	0x0a	/* 10: Enumerated */
#define EMBEDDED_PDV	0x0b	/* 11: Embedded Presentation Data Value */
#define SEQUENCE	0x10	/* 16: Constructed Sequence / Sequence Of */
#define SET		0x11	/* 17: Constructed Set / Set Of */
#define NUMERICSTR	0x12	/* 18: Numeric String (digits 0-9 and space) */
#define PRINTABLESTR	0x13	/* 19: Printable String (74 chars) */
#define TELETEXSTR	0x14	/* 20: T.61 String (Teletex) */
#define VIDEOTEXSTR	0x15	/* 21: Videotex String */
#define IA5STR		0x16	/* 22: Int'l Alphabet 5 (ISO 646 - 128 chars) */
#define UTCTIME		0x17	/* 23: UTC Time */
#define GENERALIZEDTIME	0x18	/* 24: Generalized Time */
#define GRAPHICSTR	0x19	/* 25: Graphic String */
#define VISIBLESTR	0x1a	/* 26: Visible String (ISO 646 - 95 chars) */
#define GENERALSTR	0x1b	/* 27: General String */
#define UNIVERSALSTR	0x1c	/* 28: Universal String (4 octets/char) */
#define CHARACTERSTR	0x1d	/* 29: Unrestricted Character String */
#define BMPSTR		0x1e	/* 30: Basic Multilingual Plane (2 octets) */
				/* 31: High tag number follows in radix 128 */

And here is a little info about the root of the OID tree:

/*
 * ITU(0) includes: Recommendation(0), Question(1), Administration(2),
 *             Network-Operator(3), Identified-Organization(4)
 *
 * ISO(1) includes: Standard(0), Member-Body(2), Identified-Organization(3)
 *   1 2 includes: us(840), ca(124)
 *   1 3 includes: osinet(4), gosip(5), dod(6), oiw(14)
 *
 * JOINT-ISO-CCITT(2) includes: Directory Service(5), Country(16)
 *   2 16 includes: us(840), ca(124)
 *   2 16 840 includes: organization(1), mhs-md(2), state(3)
 *
 * From ISO/IEC 9594-2 (X.501) "The Directory: Models"
 *
 *   Directory Service         ds ::= {joint-iso-ccitt(2) ds(5)}
 *   attributeType          id-at ::= {ds 4}
 *   algorithm                    ::= {ds 8}
 *   certificateExtension   id-ce ::= {ds 29}  (from AM 4)
 *
 * From ISO/IEC 9594-6 (X.520) "The Directory: Selected Attribute Types"
 *   id-at-commonName             ::= {id-at 3}
 *   id-at-countryName            ::= {id-at 6}
 *   id-at-localityName           ::= {id-at 7}
 *   id-at-stateOrProvinceName    ::= {id-at 8}
 *   id-at-organizationName       ::= {id-at 10}
 *   id-at-organizationalUnitName ::= {id-at 11}
 */

So you can see that {1 3 6 ...} is in the ISO dod arc, but I can't help
you from there.  MISSI uses the joint-iso-itu arc for dod:
{joint (2) country (16) us (840) organization (1) gov (101) dod (2)}.

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

My questions are:

1)  draft-ietf-asid-inetorgperson-00.txt defines these OIDs:

	2.16.840.1.113730.3.1.1  carLicense"
	2.16.840.1.113730.3.1.2  departmentNumber"
	2.16.840.1.113730.3.1.3  employeeNumber"
	2.16.840.1.113730.3.1.4  employeeType"
	2.16.840.1.113730.3.2.2  inetOrgPerson"

  A Verisign cert request included the following OIDs:

	2.16.840.1.113730.1.1
	2.16.840.1.113730.1.8
	2.16.840.1.113730.1.13

  RSADSI is 1.2.840.113549, but who is 2.16.840.1.113730, and where are
  the OIDs under it defined?

2)  The 1 December 1996 Draft Amendment to X.509 lists certificate
    extensions id-ce 9, 14-21, 23-24, 27-36 and lists id-ce 34 as deprecated.
    It also includes the following comment:

   "The following OBJECT IDENTIFIERS are not used by this specification:"
    id-ce 2-8, 10-13, 22, 25, 26.

    That comment is not as helpful as it could be, since it says
    nothing about id-ce 1, and doesn't point to the specification that
    *does* use id-ce 2-8 ...

    The same Verisign cert request mentioned above included 2.5.29.3
    (id-ce 3).  That extension is pretty useless if it isn't documented
    somewhere, and it would be nice if X.509 DAM 1 pointed to the
    appropriate specification.

From: Paul Kierstead <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Unknown string type (28) and content of private enterprise extensions.
Date: Fri, 28 Feb 1997 09:37:25 -0500

While browsing some X.509 certificates included with Internet Explorer,
I came across some names encoded using a tag identifier of 28. I would
appear to be ASCII with each character encoded as 4-bytes. Now obviously
it was intended for more then just ASCII; I presume the other three
bytes are used under some conditions.

Does anybody know exactly what these string are? Peter Gutman, in his
style guide, referred to a 4 byte scheme  which he guessed to be Unicode
.... however Unicode is 16-bit. Is it Unicode encoded as 32-bit? 

Is Universal String TAG 28? My (admittidly old) documents do not refer
to UniversalString. Or BMPString, for that matter. 

More along these lines .... the Verisign certificates have private
enterprise extensions ( { 1 3 6 1 4 1 311 2 1 27}  and  { 1 3 6 1 4 1
311 2 1 10}  ). Anybody know the content format of these extensions?

Any concrete knowledge would be greatly appreciated ....

------------------------------
Paul Kierstead			TimeStep Corporation
mailto:[email-masked]		http:\\www.timestep.com 

To: "David P. Kemp" <[email-masked]>
cc: [email-masked]
Subject: Re: Private key possession 
Date: Wed, 26 Feb 1997 22:01:34 +0000
From: "Frank O'Dwyer" <[email-masked]>

> Your examples are all of the form "authority A asserts that
> attribute B applies to subject C".  The assertions could be in the
> form of an "attribute certificate" (whatever that is) or could be
> any other signed document, such as a signed email message saying
> "the subject holding public key xxyyzz is a bad credit risk".
> 
> Clearly, anyone can write and sign such an email message, just as
> anyone could make the same assertion by issuing an attribute certificate.
> 
> But an assertion of the form "authority A asserts that public key B
> belongs to the subject using the name C", i.e. an identity certificate,
> is a special case of a signed statement, and must be treated specially
> if it is to have any meaning beyond that of a generic signed object.
> The whole point of designing a public key infrastructure
> (standardizing the format of certification paths and management
> protocols) is to facilitate the automation of trust decisions regarding
> generic signed objects.

Sure, but names are not the only special case.  "..the subject
authorized to do..." and "...a subject considered to be..."
are also special, and also interesting.  I suppose you could even,
at a stretch, consider these a type of name (the first is very
like a role or group, and the second is like a label**). In my opinion 
any statements that are "about" a subject that uses keys, and which 
can be vouched for by a trusted third party - these are fair game 
for a certificate.  Even more so if some application can automatically
process them. After all, "bad credit risks" also create generic 
signed objects.

Since PKIX-1 (or at least X.509 v3) is clearly open-ended
for new attributes, and the PKIX-3 stuff can be used to request 
any attributes that are going, I don't really see why there 
should be a problem with attributes that are not names (at 
least, not in the conventional sense). Except of course,
that you might want to say something "about" a key-holding
subject without their co-operation - which is where I came in...

Cheers,
Frank O'Dwyer.

** There are also other interesting certificates which don't
appear to contain anything that would ordinarily be considered
a name. For example, I would be interested in a certificate
whose main attribute was a GIF or EPS of a company logo. Is a logo
a name?  (I guess it is if you are The Artist Formerly Known As
Prince, but otherwise...).  Also interesting would be a cert
with just a jpeg of somebody's face, or with the image or
text from a hyperlink (as distinct from the URL).  I wrote a 
paper a while back about 'Hyperlink Spoofing' which proposed 
these types of extensions to SSL (i.e. X.509 v3) certificates 
as a remedy for fake hyperlinks - it's at 
http://www.brd.ie/papers/sslpaper/sslpaper.htm if anyone is
interested.

Date: Tue, 25 Feb 1997 11:29:58 -0800
To: [email-masked] (Bill Burr), [email-masked]
From: Peter Williams <[email-masked]>
Subject: Re: Private Key Possession

Bill,

My take is we are determining the nature of the intended PKIX infrastructure,
by the question being considered. The technical subject being argued
(mandatory/required checking of an assurance entitled "proof of
possession") could
have been one of several control instruments being used.

There are those who see PKIX as a toolkit of standard elements for building
certification domains, of quality expressed by the X.509 policy field (ME!
based on X.509 standard semantics)

And there are those who are engineering into the technical protocols
for management some miminal assurance requirements for all domains.

Such minimal assurances are perhaps expressed in the APKI I-D, which I
know I personally can see little commercial value. I just
dont believe in the management culture it envisions - for 
commercial purposes.

At the end of the day, I expect to go with the flow of the group;
if APKI objectives are what the protocol helps instrument, then executing the
agreed standard is what participating in an open standards process is all
about! I putting my contribution in the pot, versus seeking to hold
things up for any pariticular purpose.  Authors shoudl take and
ignore what they want, from my contributions.

Now, I read the WG scope very specifically - it allows 1422 like management
culture, including the culture of persona CAs. Others seem to disagree when it
comes to the practice of conforming to the spec.

I think this is the underlying tension, causing what is perhaps
one of the final hurdles to just doing it, and amending the 2 documents later,
if their procedures break, or receive too much adverse technically-motivated 
feedback upon deployment.

The choice of language is perhaps all we are now considering - a normal
event in standards processes reaching maturity. its a final statge
of concensus building, to ensure the language exhibits the intended
environment and space for all interested players to now "just do it".

At 05:59 PM 2/24/97 -0500, Bill Burr wrote:
>I'm quite confused about this thread, which I've been trying to follow with
>ever diminishing success as it continues.  I don't understand what aspect of
>the PKIX the debate is about.  Specifically:
>
>- Are we talking about PKIX-1 or PKIX-3 here?
>
>- Does a certificate have to be issued via PKIX-3 to be a valid PKIX
>certificate? Is it a condition of "PKIX conformance"  that a certificate
>that conforms to the syntax and semantics of PKIX-1, must also have been
>issued via the PKIX-3 protocol to be a "conforming PKIX certificate?"
>
>- If, as I hope, you don't necessarily have to use the PKIX-3 protocol to
>issue conforming PKIX certificates, then is the argument about a semantic
>requirement in PKIX-1 that the issuing CA shall ensure that the certificate
>subject prove that he knows the private key corresponding to the certified
>subject public key, whatever the protocol used to issue the certificate?
>
>- Or is the question simply limited to whether the PKIX-3 protocol should or
>should not allow for less rigorous issuance options where the prospective
>certificate holder does not have to demonstrate possession of the private
>key?  Surely nobody is arguing that the protocol need not even provide a way
>to prove that the certificate holder actually has the private key, are they?
>
>
>It seems to me that there is a respectable (but by no means overwhelming)
>case to be made that the PKIX should choose to be only for "high assurance"
>certificates and single out this one important principle as a vital for any
>claim of "PKIX conformance."  
>
>It also seem to me that there's an even better case to be made for confining
>the PKIX-3 protocol to reasonably high assurance cases where the possession
>of the private key is verified.  That's certainly the case of the most
>interest to me.  Then it might be sufficient for a certificate practice
>statement to say that certificates are issued via PKIX-3, and not be
>necessary to further state what was done to ensure the integrity of the
binding,
>
>But it would seem to me to be a very bad idea to link PKIX-1 conformance to
>certificate issuance via PKIX-3.  After all, the certificate is issued once,
>and the issuance protocol could very well be by some non-standard protocol,
>but the certificate could still be perfectly interoperable with PKIX
>certificates issued in completely different ways.  There is a much stronger
>reason for needing PKIX-1 level  interoperability than PKIX-3 level
>interoperablity.  
>
>
>Regards,
>
>Bill Burr
>301-975-2914
>http://www.nist.gov/itl/div877/staff/burr/
>
>
>

Date: Mon, 24 Feb 1997 17:59:51 -0800
To: "Frank O'Dwyer" <[email-masked]>
From: [email-masked] (Tony Bartoletti)
Subject: Re: Private key possession
Cc: [email-masked]

Frank O'Dwyer wrote:
>It's really nothing like junk mail or telemarketing since it's purpose
>is to NOT involve uninterested or uncooperative parties.  If someone
>creates and makes available a certificate concerning Joe, how is this
>like Joe getting spammed?  The certificate might indicate 'holder posts
>thoughtful articles to sci.crypt', or it might say 'holder
>repeatedly posts 10,000 line articles to comp.os.ms-windows.advocacy
>arguing that the moon shot was faked in a hollywood studio'.  Joe
>need never see either certificate - it just happens to certify something
>_about_ him, to anyone who cares to believe the issuer.  But you want
>people to call Joe up and get him to use his key before they can
>certify to interested parties that he is a guru/idiot (delete as
>applicable).  Now THAT would be like junk mail and telemarketing.

>Cheers,
>Frank O'Dwyer

I tend to agree with you, but...

Please respond to David Kemp's comments.  The line between "certificate"
and "signed message" is eroding quickly.  It seems that the public key is
simply being used as a stand-in for the target's "name".

I think I see a drifting here to accomodate SPKI, which intends to "simply" certify that "entity-that-can-sign-as XXX has YYY attribute, authority, etc."

I can sign a message attributing anything to anyone, and I don't need their
permission.  I can be sued for libel, defamation, etc., of course.  But what
difference if my message refers to them by name, address, or public key?
Does my reference to their public key make my signed message a "certificate"?
Perhaps it does, in a vague sense at least.

To me, the fundamental responsibility of any PKI is to provide a standard
way of "validating a certificate chain (or mesh?)" to the satisfaction of
the relying party.  Where such satisfaction desires proof-of-ability-to-sign,
this capability should be addressed in some fashion by ANY PKI.  A form of
challenge-response along these lines can be the foundation of a very strong
set of bindings, and I believe this was in the minds of the SPKI group, who
use it as a bootstrap via "self-signed certificates".

(IMNSHO)

___TONY___

Tony Bartoletti                                             LL
SPI Project Leader                                       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

To: Stephen Kent <[email-masked]>
cc: [email-masked]
Subject: Re: Private key possession 
Date: Mon, 24 Feb 1997 22:23:40 +0000
From: "Frank O'Dwyer" <[email-masked]>

[...]
> The intranet CA still needs to
> be contacted by the user to request the cert (if this is an offline, e.g.,
> phone request, this point may not be relevant) and the CA needs to acquire
> the cert and relevant CRLs, and all of this entails communications across
> the firewall protecting the CA and its domain.  A key question here seems
> to be whether the protocols needed to acquire the certificate for the user
> (who may have requested access for this domain in some online fashion) are
> more "dangerous" than fielding a cert request through the firewall.  Our
> experience at BBN in providing the latter functionality would suggest
> otherwise.

A lot depends on who initiates the communications. I would rather 
import the odd certificate than to hang an RA out in the breeze for 
all-comers to throw gnarly ASN.1 requests at.  You've got to presume
that these things have bugs. Also, whereas I (presumably) _need_ the 
ability to get your certificate, I don't _need_ to provide an online 
RA service to the internet.  Why accept a risk (or spend money)
if you don't have to?  

[...]
> I expect to have different keys for
> different cert sfrom different CAs.  Not trusting the same CAs is not the
> issue here; in fact, a lack of inter-CA trust is a very good motivation for
> wanting a different key in each certificate, as I mentioned earlier.

Why?  If I trust Verisign CA more than Newbie CA and don't trust
Digicrime CA at all, then I won't request a cert for my key from 
Digicrime CA.  (It may still issue one, of course). But if 
I got a cert from the other two, why would I care if the keys 
were the same or not?  How could it possibly get any worse than 
the Digicrime CA using the key from my Verisign cert?  And what
could any CA do that my having another key would stop them 
doing?

[As a matter of fact, I would be extremely keen on having my key 
certified by multiple CAs.  I would also like if verifiers would 
require at least N independent certs before accepting my key (the 
PGP model). This protects me against CAs.  I don't really
expect this to happen, though - especially if you have to 
pay for certs.]

[...]
> Sorry, but I cannot agree with the argument that unsolicited cert issuance
> is a feature!  It has all the appeal of junk mail and telemarketing calls.

It's really nothing like junk mail or telemarketing since it's purpose 
is to NOT involve uninterested or uncooperative parties.  If someone 
creates and makes available a certificate concerning Joe, how is this
like Joe getting spammed?  The certificate might indicate 'holder posts 
thoughtful articles to sci.crypt', or it might say 'holder 
repeatedly posts 10,000 line articles to comp.os.ms-windows.advocacy 
arguing that the moon shot was faked in a hollywood studio'.  Joe
need never see either certificate - it just happens to certify something
_about_ him, to anyone who cares to believe the issuer.  But you want 
people to call Joe up and get him to use his key before they can 
certify to interested parties that he is a guru/idiot (delete as 
applicable).  Now THAT would be like junk mail and telemarketing.

Cheers,
Frank O'Dwyer 

To: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: Private key possession 
Date: Mon, 24 Feb 1997 20:54:58 +0000
From: "Frank O'Dwyer" <[email-masked]>

> Frank,
> 
> 	I'd like to think that having an RA, as an agent of a CA, verify
> private key possesion is acceptable as an alternative to direct CA
> validation.  However, I'd also like to think that the proof afforded to the
> RA could be made available to the CA to help resolve any later dispute over
> whether the user in question did make a certificate request (vs.
> unsolicited certificate issuance).  is this inconsistent with your model?

No, that sounds fine, so long as it's a policy matter for the CA
whether or not to require this of the RA.  I do think it makes good
sense for the RA to always require it of the user.  I see it more 
as a safety catch mechanism rather than something that you could 
use later on to resolve disputes, though.  

Cheers,
Frank O'Dwyer.

Date: Mon, 24 Feb 1997 17:59:11 -0500
To: [email-masked]
From: [email-masked] (Bill Burr)
Subject: Re: Private Key Possession

I'm quite confused about this thread, which I've been trying to follow with
ever diminishing success as it continues.  I don't understand what aspect of
the PKIX the debate is about.  Specifically:

- Are we talking about PKIX-1 or PKIX-3 here?

- Does a certificate have to be issued via PKIX-3 to be a valid PKIX
certificate? Is it a condition of "PKIX conformance"  that a certificate
that conforms to the syntax and semantics of PKIX-1, must also have been
issued via the PKIX-3 protocol to be a "conforming PKIX certificate?"

- If, as I hope, you don't necessarily have to use the PKIX-3 protocol to
issue conforming PKIX certificates, then is the argument about a semantic
requirement in PKIX-1 that the issuing CA shall ensure that the certificate
subject prove that he knows the private key corresponding to the certified
subject public key, whatever the protocol used to issue the certificate?

- Or is the question simply limited to whether the PKIX-3 protocol should or
should not allow for less rigorous issuance options where the prospective
certificate holder does not have to demonstrate possession of the private
key?  Surely nobody is arguing that the protocol need not even provide a way
to prove that the certificate holder actually has the private key, are they?

It seems to me that there is a respectable (but by no means overwhelming)
case to be made that the PKIX should choose to be only for "high assurance"
certificates and single out this one important principle as a vital for any
claim of "PKIX conformance."  

It also seem to me that there's an even better case to be made for confining
the PKIX-3 protocol to reasonably high assurance cases where the possession
of the private key is verified.  That's certainly the case of the most
interest to me.  Then it might be sufficient for a certificate practice
statement to say that certificates are issued via PKIX-3, and not be
necessary to further state what was done to ensure the integrity of the binding,

But it would seem to me to be a very bad idea to link PKIX-1 conformance to
certificate issuance via PKIX-3.  After all, the certificate is issued once,
and the issuance protocol could very well be by some non-standard protocol,
but the certificate could still be perfectly interoperable with PKIX
certificates issued in completely different ways.  There is a much stronger
reason for needing PKIX-1 level  interoperability than PKIX-3 level
interoperablity.  

Regards,

Bill Burr
301-975-2914
http://www.nist.gov/itl/div877/staff/burr/

Date: Mon, 24 Feb 97 12:36:54 
From: "Housley, Russ" <[email-masked]>
Encoding: 533 Text
To: Peter Williams <[email-masked]>
CC: [email-masked]
Subject: Re: Private key possession

Peter:

You said:

     If there are indeed elements of default policy built into the 
     protocol design, based on the designer's expections and beliefs,
     then perhaps they should be identified as options (or at least 
     identified for review purposes), and, as I say, possibly abstracted 
     out as generic policy rules in the policy document.

If the protocol does not include fields that can be used to verify private key 
possession, then we would not support a large class of resonable policies.

Russ

Date: Mon, 24 Feb 1997 10:49:11 -0800
To: [email-masked] (David P. Kemp), [email-masked]
From: Peter Williams <[email-masked]>
Subject: Re: Private key possession

 >Given that the PKIX mechanism is not a significant burden to implement,
>and given that those who have better ideas on how to demonstrate
>possession of a private key and those who feel proof of possession is
>unnecessary are free to turn off the PKIX mechanism for their
>installations, the PKIX mechanism should remain a REQUIRED capability
>of PKIX-compliant software.

Im going to hold off responding much to this thread for a while, so others
can get a shot in.

But, for later general use, I am now going to introduce two sets of facts
which
make the above seemingly reasonable statement invalid in real life of a
diverse world based on commercial objectives, not military command=and=control
principles.

(a) it is a burden to implement, as the consequences of having done
so are burdensome on the CA/RA party which implicitely makes a representation
of having received a request, by a cliam of conformance to generic PKIX,
and by
admission of the designers, may be required to demonstrate proof of such act
by the legitmiate subscriber to satisfy a claim of
unethical/unlicensed-issuance
under the prevailing ethical or legal standard.

Costs just went up 1000% due to the terms "legal" and "ethical". 
All *PKIX* cert-server, and "RA"-server software just got 100* more
complicated, requiring basis for higher trust.

While it is possible in OECD signatory countries that govt immunity could be
imposed to limit the liabilities on CAs and RAs, through accredititation and
licensing type means, this is hardly an IETF issue, or something suitable to
serve as basis for open-forum technical protocol design for systems
to be deployed without regard to such environmental expectations.

(b) The use of certiifcates to impose any control policy is a
policy-specific matter - be that policy mandatory escrow, mandatory
crypto-registration, mandatory licensing of providers, or be it mandatory
imposure of some other regulation system such as taxation, or
sign-up to VISA operating regulations on account usage...

It is not the purpose of the technical PKI infrastructure to (a) impose
any such policy (b) provide a sufficient technical basis for uniformly
imposing any such rule.

A cooperationg domain of CA/RA/users within the internet PKI interworking
space,
each acepting use of a policy oid value "foo" can sign-up to, and give/accept
notice of, aspects of operating policy which give rise to that domain's
"meaningful PKI". As per 1422, there will likely be a small number
of meaningful certification domains, which would not naturally
share subscribers and users. You will not have permission to
use your VISA SET merchant cert/keys to establish secure SSL-based shopping
service, for example.

Enablement of the separation of policy and technology
is the purpose of the X.509 policy extn, and external
control-enabling-policy mechanism, and what it should be used for. PKIX
should mandate use of the standard verification algorithm expressed now
in X.509, to instrument such a diverse world based on the std policy
signal.

This call-to-recollect fact is even a suggestion conformant with US
Federal Govt. designs for its uniform world-wide KMI to be imposed
upon all internet persons. The policy conformance requirements can be stated
critically, nor non-critically, (X.509 has the optional
criticality mechanism, remember) as means to insist upon enforcement
of the control *policy* of the domain, by conforming end-systems.

Operators of domains, and CAs/RAs, can offer some or all
the available control policies, as normal business and market conditions
require (SET | SSL | KMI | ...} . They can innovate, add-value, and/or ignore
control objectives, as the customers/users demand. Not everyone
needs to buy and sell using the SET payment service!

Date: Mon, 24 Feb 1997 17:58:21 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Housley, Russ" <[email-masked]>
Cc: [email-masked]
Subject: Re: Private key possession

Housley, Russ wrote:

> He does not advocate the removal of fields that permit validation, rather
> he suggests that they should be optional.

Correct.

> I think that this verification is easy to do, and that it should remain
> mandatory. 

I do not think that because "it is easy to do" is a valid argument. 

Please have a look at the mail I sent today.

Denis

-- 

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

Date: Mon, 24 Feb 1997 11:40:14 -0500
From: John Lowry <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Private key possession
Cc: [email-masked]

More importantly, the proof must be transitive as the RA may not be
a function provided by (as opposed to supported by) the CA.

Consider the case where the CA is a service provider and the
RA is operated by the CA's customer (or agent of the CA's customer !)
I question whether the RA is an agent only of the CA.  It seems to
me that the RA is an agent of both the CA and the "customer".

The RA _may_ be bound procedurally to verify possession but how
can the CA always rely on that ?  For some cases the CA will still
need to verify proof of possession or verify that the RA performed
that function.  It is important that there be technical means to
do that verification and that the CA can look to its local store
to confirm performance of its agents.

> From [email-masked]  Mon Feb 24 11:20:58 1997
> X-Sender: [email-masked]
> Mime-Version: 1.0
> Date: Mon, 24 Feb 1997 10:25:01 -0500
> To: "Frank O'Dwyer" <[email-masked]>
> From: Stephen Kent <[email-masked]>
> Subject: Re: Private key possession
> Cc: [email-masked]
> 
> Frank,
> 
> 	I'd like to think that having an RA, as an agent of a CA, verify
> private key possesion is acceptable as an alternative to direct CA
> validation.  However, I'd also like to think that the proof afforded to the
> RA could be made available to the CA to help resolve any later dispute over
> whether the user in question did make a certificate request (vs.
> unsolicited certificate issuance).  is this inconsistent with your model?
> 
> Steve
> 
> 

Date: Mon, 24 Feb 1997 09:12:28 -0700
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Private key possession -Reply

Question:

Would it be assumed that a cross-certification of a well known CA public
key require a "signed" request?  I think that that would be optional on the
cross-certifying CA's part.

Michael

>>> Denis Pinkas <[email-masked]> 02/24/97 01:27pm >>>
Steve, Gene, Carlisle, Peter, Frank ... and all others

This is single reply to all of you, that I will attempt to make short, 
I would like first to re-focus on the original matter.

A. The original question was : Should a protocol, proving possession of 
the private key to the *CA*, be mandatorilly supported to claim 
conformance to PKIX ? My answer to this question is NO.

There are various simple arguments for this, among them:

1) As Franck said , that proof may be given by the user to a RA and the 
CA will trust the (signed request of the) RA to have done the 
verification.

2) The CA (or the RA) may be the entity generating the private key and 
thus the user is unable to support any such protocol.. In other words we 
cannot suppose that the subject will always generate the key.

This demonstrates that the proposed protocol is just one of the 
alternatives to do it, and not the *single* way to do it.

Can we, first, all agree on this ?

B. The remaining of this E-mail is important as well, but I would really 
like the opinion of the group on that question first.  :-)

I truly like many parts of the presentation from Carlisle in particular 
when he says that "the CA asserts a binding between the entity and the 
private key". 

I also agree to say that proof-of-possession-of-private-key is a 
mandatory aspect of the certification process (this does not mean that 
this must be done by that *protocol* only).

I almost agree when he says " Clearly, (an honest) CA can only validly 
assert such a binding if, in fact, it is convinced that such a binding 
exists".

The general statement is that any CA should use appropriate mechanisms

AND procedures to make sure that for each of its certificates, the 
subject has current possession/usage of the corresponding private key.

Can we agree on that statemment too ?

Carlisle says (and I fully agree) :

" If a CA claims conformance to PKIX, and PKIX mandates proof-of-
possession, then when it is discovered that the CA did not actually do 
the proof-of-possession (i.e., certificates are found for Alice and Bob 
which contain the same public key), legal action can be taken against 
the malpractice. The CA can be sued for damages, or driven out of 
business, or whatever. "

How can we discover that the CA did not actually do the proof-of-
possession (by whatever means) ? So the BIG question is  :

Should that discovery be done :

1 - at the time the checking using the certificate is performed, or 
2 - long after ?

My personal answer is : At the time the checking using the certificate 
is performed. Otherwise wrong decisions (false authentication or steal 
of signatures) would be discovered too late and damages would have 
already occurred.

Can we agree on this ?

If by some means an application protocol allows to make sure of an 
effective knowledge of the private key due to some real time
computation, then possession of the private key is done by the subject
[and thus does 
not need to be provided by the CA].

Note that proof-of-possession can also be proven *by the subject* to 
other parties, not necessarily by the CA, using one of the two 
techniques I already mentioned: 

a) counter-signature of the certificate by the user or 
b) inclusion of the certification path (or only the certificate) 
   in some data signed using the subject private key.

Note that the support of one of these two techniques is not necessarily 
required for any protocol. However including it would never hurt and it 
would be most advisable to always include it, when the size of the 
message is not a major concern. On the contrary a more detailed analysis

of the protocol would be necessary.

My conclusion would be that "all PKIX-using software" should NOT
assume 
that each CA has indeed performed the check correctly (which is a point 
on which Carlisle and myself may still share a different view).  :-(

Denis

-- 

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

Date: Mon, 24 Feb 1997 11:09:39 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Private key possession

> From: "Frank O'Dwyer" <[email-masked]>
>
> There is another reason why demonstrating possession of a private 
> key might not be a good thing to make mandatory, and I think it
> is more plausible than the patent example. For example, I might 
> want to make a local intranet certificate which binds certain 
> X.509 extensions to your key.  This certificate permits you (say) 
> to upload signed files via my firewall. That doesn't seem an
> unreasonable requirement, but I can't do it if I need to demonstrate 
> ability to use your private key. Certainly you (or your agent) could 
> request the same cert, but an intranet CA is likely to reject 
> out of hand certification requests that originate from outside.  
> 
> There are clearly other examples, too, where you might not want
> to consent to an attribute (e.g. it says you are not a
> good risk for a loan). Or, it might be confidential (you can't
> decrypt it and therefore _can't_ consent to it). Still, I might wish 
> to request it, the CA might be willing to grant it, and someone else 
> might wish to trust it.  But it's all impossible if I have to know 
> your private key.  
> 
> Seems like a broad class of applications to be ruling out.

They aren't being ruled out at all.

Your examples are all of the form "authority A asserts that
attribute B applies to subject C".  The assertions could be in the
form of an "attribute certificate" (whatever that is) or could be
any other signed document, such as a signed email message saying
"the subject holding public key xxyyzz is a bad credit risk".

Clearly, anyone can write and sign such an email message, just as
anyone could make the same assertion by issuing an attribute certificate.

But an assertion of the form "authority A asserts that public key B
belongs to the subject using the name C", i.e. an identity certificate,
is a special case of a signed statement, and must be treated specially
if it is to have any meaning beyond that of a generic signed object.
The whole point of designing a public key infrastructure
(standardizing the format of certification paths and management
protocols) is to facilitate the automation of trust decisions regarding
generic signed objects.

I agree that in principle, cert management protocols could be made
entirely policy-neutral, and a CA's proof of possession policy could be
documented in the CPS, perhaps even in machine-parseable format. Or it
could in principle be documented in something like David Boyce's
"privateKeyPossessionPath" certificate extension.  But just because
ridiculously complicated policy expressions are possible does not
mean that they should be used. Proof of possession is a fundamental
requirement, not an optional feature, of any meaningful Public Key
Infrastructure.  Offering 10 different options (none mandatory) for
accomplishing it, in the name of policy-neutrality, is counterproductive.

--------

Denis raised two related but separate questions:

1) should proof of possession be mandatory for the CA, since the
   existing certificate format offers no proof that is demonstrable
   to a third party?, and

2) should the specific PKIX proof-of-possession PROTOCOL be a mandatory
   mechanism for accomplishing it?

To address only question 2, yes the protocol should be mandatory to
implement.  This seems to be a recurring theme in nearly all IETF
working groups, and the answer is always the same:

 * REQUIRED features are so designated to provide a
   least-common-denominator for interoperability.

 * REQUIRED features do not have to actually be used by everyone, they
   just have to be supported in every implementation that claims to
   comply with the standard.

Given that the PKIX mechanism is not a significant burden to implement,
and given that those who have better ideas on how to demonstrate
possession of a private key and those who feel proof of possession is
unnecessary are free to turn off the PKIX mechanism for their
installations, the PKIX mechanism should remain a REQUIRED capability
of PKIX-compliant software.

Date: Mon, 24 Feb 1997 10:59:39 -0500
To: "Frank O'Dwyer" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Private key possession
Cc: [email-masked]

Frank,

Let's examine the scenarios you provided in more detail:

>(a) the user has a certificate from Verisign or a similar
>neutral CA outside the company.  I want to allow the user
>limited access based on that public key, but I don't want to
>allow everyone with a Verisign cert in, and I don't want to
>have to maintain ACLs.  I also want this to be valid for
>just three weeks, whereas the user's current cert is good
>for a year. I'm assuming requests for intranet certs
>cannot traverse the company firewall (although I take your
>point below).
>
>(b) the user has a certificate for use in some other
>company's intranet.  Otherwise, as above.

Whether the cert comes from Verisign or some other, external organization
doesn't seem to be central to the argument.  The intranet CA still needs to
be contacted by the user to request the cert (if this is an offline, e.g.,
phone request, this point may not be relevant) and the CA needs to acquire
the cert and relevant CRLs, and all of this entails communications across
the firewall protecting the CA and its domain.  A key question here seems
to be whether the protocols needed to acquire the certificate for the user
(who may have requested access for this domain in some online fashion) are
more "dangerous" than fielding a cert request through the firewall.  Our
experience at BBN in providing the latter functionality would suggest
otherwise.

>What you're describing sounds like a firewalled internet CA, where
>requests from the internet are normal and expected. However, if
>you have an _intranet_ CA, then a "nothing from outside" rule
>would seem quite natural. You can certainly imagine some people
>wanting that, even if it's only a perception issue. It's new
>software, after all.

But there really must be some communication between the CA and the outside
world, for the reasons cited above.

>> Also reusing the same key in multiple
>> certificates is often frowned upon, since it is not clear under what policy
>> the keys are being used, i.e., ambiguity results when any of several
>> certificates can be matched to the same private key.
>
>Well, I think multiple certs for the same key will be a fact of
>life, if only because we won't all trust the same
>CAs, but we will still need to interwork.  We will also disagree
>about which attributes belong with a key (and even about which
>attributes are defined!).

I don't understand your argument here.  I expect to have different keys for
different cert sfrom different CAs.  Not trusting the same CAs is not the
issue here; in fact, a lack of inter-CA trust is a very good motivation for
wanting a different key in each certificate, as I mentioned earlier.

>Cross-certificates will help here but I don't think
>they solve every issue. Or, another approach is to have
>multiple private keys, which will probably happen too,
>but may not always work either (e.g. suppose you want to sign
>a doc and have it believed in multiple domains, but they
>do not have a common point of trust. As far as I can see
>you then need to sign more than once with different keys,
>or you need multiple certs for the same key.)

This example better motivates your point about the desire for the same
public key to be embedded in multiple certs, i.e., the need to sign a
document and have it recognized across multiple certification domains.
However, the examples provided earlier are for authorization certs, not for
certs use for document signature (maybe non-repudiation?) purposes.  Also,
because of the complex problems of non-repudiation systems, it is extremely
dangerous to have the same key in multiple certs issued by different CAs.
I do believe that cross certs are the best way to address the need you
cited here, i.e., a signature recognizable across many different
certification domains.

>> 	The second set of examples you provided also concern me.  As a
>> user, I don't want to be issused a certificate that I didn't ask for, but
>> with my public key in it, in much the same way that I don't like receiving
>> unsolicited credit cards on the mail.  Requiring proof of possesion as part
>> of certificate issuance helps prevent such unsolicited issuance, since a CA
>> would not be able to prove that I requested the cert in question.  (Of
>> course this does not solve the bigger problem of having a cert issed with
>> some other public key in it and having it bound to my name, but relaxing
>> the proof-of-possesion requirement also does not address that problem.)
>
>Sure, but the flip side is that, as a CA, I don't want to be
>constrained to issuing certificates that you request
>or even certificates that you like.  Someone may want to issue
>a certificate saying "The holder of this public key teases cats",
>or "the holder of this public key is ugly, incompetent, and known
>to the police".  As soon as the attributes get interesting then
>there will undoubtedly arise such controversial and even
>libellous certificates. Whether this type of thing is desirable
>or not is a political/moral question that people won't agree on.
>But it doesn't seem appropriate to take a position on it at the
>protocol level.

Sorry, but I cannot agree with the argument that unsolicited cert issuance
is a feature!  It has all the appeal of junk mail and telemarketing calls.
I don't really believe that opinion is divided here, as you suggest, but
maye a straw poll is in order to test this belief.  How many people believe
that issuing a cert to a user who has not requested one is an important
feature.  (Note, the question is not whether the user gets a cert with
exactly the attributes he requested, as John Lowry pointed out earlier.
The question is whether you want certs to be issued with your public key
(and maybe your name) without your knowledge.  Of course a CA could do
this, unilaterally, but the question is how many forlks this this is a
desirable feature and thus the PKIX standards should be structured to allow
(encourage?) such cert issuance?

>> 	It seems that there might be a common thread in these examples,
>> i.e., the question of whether a third party ought to be able to cause a
>> certificate to be issued containing a key already associated with a user,
>> but without the consent or active participation of the user.  Is this a
>> feature, or a bug?  Making proof-of-possesion an optional aspect of cert
>> requests side steps the question, but is that good?
>
>To be able to require the active participation of the user would
>imo be a feature.  To be unable to do anything else would imo be
>a bug.  I think maybe if the RA requires the proof, but the CA doesn't
>necessarily require it, then you get both options?

I don't think that the examples provided so far support the conclusion that
requiring proof-of-possesion is a bug, but I remain open to more evidence.
At least the discussion is causing us to better explore the underlying
assumptions and issues surrounding the complex topic.

Steve

Date: Mon, 24 Feb 1997 10:25:01 -0500
To: "Frank O'Dwyer" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Private key possession
Cc: [email-masked]

Frank,

	I'd like to think that having an RA, as an agent of a CA, verify
private key possesion is acceptable as an alternative to direct CA
validation.  However, I'd also like to think that the proof afforded to the
RA could be made available to the CA to help resolve any later dispute over
whether the user in question did make a certificate request (vs.
unsolicited certificate issuance).  is this inconsistent with your model?

Steve

Date: Mon, 24 Feb 1997 16:46:18 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: David Boyce <[email-masked]>
Cc: "Frank O'Dwyer" <[email-masked]>, [email-masked]
Subject: Re: Private key possession

David Boyce wrote:

(...) 'yet another' extension named privateKeyPossessionPath (...)

We already have many extensions. There are simpler solutions, life is
already enough complicated.   :-)

Denis.

-- 

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

Date: Mon, 24 Feb 97 06:40:26 
From: "Housley, Russ" <[email-masked]>
Encoding: 1418 Text
To: [email-masked]
Subject: Re: Private key possession

All:

I just reread this thread, and I think we have lost sight of the original 
issue.  In his original message, Denis Pinkas said:

     At the last PKIX meeting we had some discussion to say that each CA 
     SHALL verify the possession of the private key by the user before 
     issuing a certificate containing the corresponding public key.
     
     I would like to show that, while this is desirable, it does not 
     solve all problems, in particular the problem of steeling a signature 
     from some one else.
     
     [Stuff deleted]
     
     The conclusion is that each CA SHOULD verify the possession of the 
     private [key] by the user before issuing a certificate containing 
     the corresponding public key.
     
     As a consequence, this means that having a protocol to verify the 
     possession of a private signature key shall not be mandatory and if 
     we defined one, it should only be optionally supported.

So, his point is that CAs should verify possion of the private key.  He 
does not advocate the removal of fields that permit validation, rather 
he suggests that they should be optional.

I think that this verification is easy to do, and that it should remain 
mandatory.  If a CA does not actually perform the processing necessary 
to verify this, then it will be discovered before too long and that CA 
will loose customers.

Russ

To: "Frank O'Dwyer" <[email-masked]>
cc: [email-masked]
Subject: Re: Private key possession
Date: Mon, 24 Feb 1997 14:34:01 +0000
From: David Boyce <[email-masked]>

"Frank O'Dwyer" writes:

>Yes, that's it. I have two fairly concrete scenarios in mind:
>
>(a) the user has a certificate from Verisign or a similar
>neutral CA outside the company.  I want to allow the user 
>limited access based on that public key, but I don't want to 
>allow everyone with a Verisign cert in, and I don't want to 
>have to maintain ACLs.  I also want this to be valid for 
>just three weeks, whereas the user's current cert is good 
>for a year. I'm assuming requests for intranet certs 
>cannot traverse the company firewall (although I take your
>point below).
>
>(b) the user has a certificate for use in some other 
>company's intranet.  Otherwise, as above. 

Carlisle has a sound argument that proof-of-possession is inherent in 
certification, but it is possible to consider a scheme by which a CA 
need not perform this proof itself, providing adequate proof is 
available.  It has some flaws which I've identified below, and there 
are probably others I've missed;  but I hope it may provide a way 
forward in this discussion.

The key-possession issue may perhaps be managed by mandating that a CA 
is always responsible for providing a route to verifying of possession, 
but is not necessarily the source of proof itself.

This may be handled by 'yet another' extension named 
privateKeyPossessionPath which holds information (e.g. a certificate 
path) identifying the entity responsible for verifying possession of 
the private key corresponding to the public key in the certificate.  
This entity might be another CA or an RA.  I think this extension 
*should* be critical, but this may be impractical for existing 
applications.

In ordinary cases, the CA would itself be the verifier of possession, 
and this would be mandated to be the case when the certificate contains 
no such extension.  Hence 'ordinary' certificates have the mandatory 
characteristics desired.

When a CA routinely works in association with an RA, I would expect 
this to be stated in the policy of the issuing CA, and hence this 
extension would not be required for this case.

The privateKeyPossessionPath extension allows a CA to issue a 
certificate without itself proving possession of the private key (by 
generating a certificate with the  extension) provided that it trusts 
the original proof of possession assertion (a statement to the effect 
that this is the case should be stated in its policy).

Should an application accept such a certificate?  It boils down to how 
far the user trusts two entities:  the issuing CA, and the named 
possession-verifying authority (PVA).  If the named PVA is recognised 
by the application (and it is able to verify the certificate path), 
there remains the question of whether the application trusts the 
issuing CA's right to bind information to a public key whose private 
component has been verified by another authority.  This 

Does this scheme address Frank's requirements?  Let's see:

a) [Public certificate case] Frank's CA can issue a certificate with 
the  extension containing the Verisign certificate and any additional 
path his applications require to recognise it.  One issue may be how 
they gain access to CRL information for these certificates through the 
firewall.

b) [Intranet certificate case]  Frank's CA has a problem, since the 
chances are that no application will be able to verify the certificate 
path, even if a cross-certificate is generated (no access to CRLs).  If 
this can be surmounted, then perhaps there's a chance.  

[Perhaps a present but EMPTY privateKeyPossessionPath extension could 
be understood to mean 'Frank's CA hasn't verified the possession of the 
private key, but if you trust Frank's CA, then trust the binding 
anyway'.  In this case, the extension definitely should be critical.]

David.

-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;

Date: Mon, 24 Feb 1997 12:27:51 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: [email-masked]
Subject: Re: Private key possession

Steve, Gene, Carlisle, Peter, Frank ... and all others

This is single reply to all of you, that I will attempt to make short, 
I would like first to re-focus on the original matter.

A. The original question was : Should a protocol, proving possession of 
the private key to the *CA*, be mandatorilly supported to claim 
conformance to PKIX ? My answer to this question is NO.

There are various simple arguments for this, among them:

1) As Franck said , that proof may be given by the user to a RA and the 
CA will trust the (signed request of the) RA to have done the 
verification.

2) The CA (or the RA) may be the entity generating the private key and 
thus the user is unable to support any such protocol.. In other words we 
cannot suppose that the subject will always generate the key.

This demonstrates that the proposed protocol is just one of the 
alternatives to do it, and not the *single* way to do it.

Can we, first, all agree on this ?

B. The remaining of this E-mail is important as well, but I would really 
like the opinion of the group on that question first.  :-)

I truly like many parts of the presentation from Carlisle in particular 
when he says that "the CA asserts a binding between the entity and the 
private key". 

I also agree to say that proof-of-possession-of-private-key is a 
mandatory aspect of the certification process (this does not mean that 
this must be done by that *protocol* only).

I almost agree when he says " Clearly, (an honest) CA can only validly 
assert such a binding if, in fact, it is convinced that such a binding 
exists".

The general statement is that any CA should use appropriate mechanisms 
AND procedures to make sure that for each of its certificates, the 
subject has current possession/usage of the corresponding private key.

Can we agree on that statemment too ?

Carlisle says (and I fully agree) :

" If a CA claims conformance to PKIX, and PKIX mandates proof-of-
possession, then when it is discovered that the CA did not actually do 
the proof-of-possession (i.e., certificates are found for Alice and Bob 
which contain the same public key), legal action can be taken against 
the malpractice. The CA can be sued for damages, or driven out of 
business, or whatever. "

How can we discover that the CA did not actually do the proof-of-
possession (by whatever means) ? So the BIG question is  :

Should that discovery be done :

1 - at the time the checking using the certificate is performed, or 
2 - long after ?

My personal answer is : At the time the checking using the certificate 
is performed. Otherwise wrong decisions (false authentication or steal 
of signatures) would be discovered too late and damages would have 
already occurred.

Can we agree on this ?

If by some means an application protocol allows to make sure of an 
effective knowledge of the private key due to some real time
computation, then possession of the private key is done by the subject
[and thus does 
not need to be provided by the CA].

Note that proof-of-possession can also be proven *by the subject* to 
other parties, not necessarily by the CA, using one of the two 
techniques I already mentioned: 

a) counter-signature of the certificate by the user or 
b) inclusion of the certification path (or only the certificate) 
   in some data signed using the subject private key.

Note that the support of one of these two techniques is not necessarily 
required for any protocol. However including it would never hurt and it 
would be most advisable to always include it, when the size of the 
message is not a major concern. On the contrary a more detailed analysis 
of the protocol would be necessary.

My conclusion would be that "all PKIX-using software" should NOT assume 
that each CA has indeed performed the check correctly (which is a point 
on which Carlisle and myself may still share a different view).  :-(

Denis

-- 

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

To: Fred Ou <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Any ideas of collecting random seeds from NT 4.0 
Date: Sat, 22 Feb 1997 11:47:23 +0000
From: "Frank O'Dwyer" <[email-masked]>

>   I am going to  implement a random number generator for key generation.
> I  like to get some ideas about  the good sources in NT 4.x for random
> seeds collecting from this group.

Look for Peter Gutmann's cryptlib on the net.  It contains
some code that does what you want, and it seems pretty well
thought out.  

Cheers,
Frank O'Dwyer.

To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: Private key possession 
Date: Sat, 22 Feb 1997 11:27:46 +0000
From: "Frank O'Dwyer" <[email-masked]>

> 	let me see if I understand the scenario you cited a a justification
> for not requiring a user to demonstrate possesion of a private key.  A CA
> wants to create a cert with some authorization extensions by taking a
> public key from some other cert and stuffing it into the new cert.  The CA
> doing this is inside a net associated with the resources to which access
> will be granted, based on use of the new cert.  However, this CA is not
> able to allow a cert request to reach it from outside, where the user who
> is to be granted authorization lives, presumably due to security concerns.
> Is this an accurate characterization?

Yes, that's it. I have two fairly concrete scenarios in mind:

(a) the user has a certificate from Verisign or a similar
neutral CA outside the company.  I want to allow the user 
limited access based on that public key, but I don't want to 
allow everyone with a Verisign cert in, and I don't want to 
have to maintain ACLs.  I also want this to be valid for 
just three weeks, whereas the user's current cert is good 
for a year. I'm assuming requests for intranet certs 
cannot traverse the company firewall (although I take your
point below).

(b) the user has a certificate for use in some other 
company's intranet.  Otherwise, as above. 
 
> 	If so, I'd like to observe that CAs performing online cert issuance
> tend to operate in the fashion that your scenario suggest would not be
> vaible, i.e., the CA is behind a firewall and it receives cerg requests
> from the open Internet, and that is exactly how it does it's job.  We have
> supplied CAs of this sort to clients, and I know of others that work this
> way, and it has not been a problem.  

What you're describing sounds like a firewalled internet CA, where
requests from the internet are normal and expected. However, if
you have an _intranet_ CA, then a "nothing from outside" rule
would seem quite natural. You can certainly imagine some people 
wanting that, even if it's only a perception issue. It's new
software, after all.

> Also reusing the same key in multiple
> certificates is often frowned upon, since it is not clear under what policy
> the keys are being used, i.e., ambiguity results when any of several
> certificates can be matched to the same private key.

Well, I think multiple certs for the same key will be a fact of 
life, if only because we won't all trust the same
CAs, but we will still need to interwork.  We will also disagree 
about which attributes belong with a key (and even about which 
attributes are defined!).  

Cross-certificates will help here but I don't think
they solve every issue. Or, another approach is to have
multiple private keys, which will probably happen too, 
but may not always work either (e.g. suppose you want to sign 
a doc and have it believed in multiple domains, but they 
do not have a common point of trust. As far as I can see
you then need to sign more than once with different keys, 
or you need multiple certs for the same key.)
 
> 	The second set of examples you provided also concern me.  As a
> user, I don't want to be issused a certificate that I didn't ask for, but
> with my public key in it, in much the same way that I don't like receiving
> unsolicited credit cards on the mail.  Requiring proof of possesion as part
> of certificate issuance helps prevent such unsolicited issuance, since a CA
> would not be able to prove that I requested the cert in question.  (Of
> course this does not solve the bigger problem of having a cert issed with
> some other public key in it and having it bound to my name, but relaxing
> the proof-of-possesion requirement also does not address that problem.)

Sure, but the flip side is that, as a CA, I don't want to be 
constrained to issuing certificates that you request
or even certificates that you like.  Someone may want to issue
a certificate saying "The holder of this public key teases cats",
or "the holder of this public key is ugly, incompetent, and known
to the police".  As soon as the attributes get interesting then 
there will undoubtedly arise such controversial and even 
libellous certificates. Whether this type of thing is desirable 
or not is a political/moral question that people won't agree on.  
But it doesn't seem appropriate to take a position on it at the 
protocol level.

> 	It seems that there might be a common thread in these examples,
> i.e., the question of whether a third party ought to be able to cause a
> certificate to be issued containing a key already associated with a user,
> but without the consent or active participation of the user.  Is this a
> feature, or a bug?  Making proof-of-possesion an optional aspect of cert
> requests side steps the question, but is that good?

To be able to require the active participation of the user would
imo be a feature.  To be unable to do anything else would imo be 
a bug.  I think maybe if the RA requires the proof, but the CA doesn't
necessarily require it, then you get both options? 

Cheers,
Frank O'Dwyer.

Date: Fri, 21 Feb 1997 18:21:26 -0800
From: Fred Ou <[email-masked]>
To: [email-masked], [email-masked]
Subject: Any ideas of collecting random seeds from NT 4.0

  I am going to  implement a random number generator for key generation.
I  like to get some ideas about  the good sources in NT 4.x for random
seeds collecting from this group.

Thank you very much!

-Fred

Date: Fri, 21 Feb 1997 17:57:49 -0800
To: Stephen Kent <[email-masked]>
From: Peter Williams <[email-masked]>
Subject: Re: Private key possession
Cc: [email-masked]

Steve,

(a) I find myself disagreeing not with any of your basic recent
arguments, but remain wholly unconvinced that a technical protocol
should ever embed any issuing or management handling procedures, even
when conventionally and/or reasonably expected in a many services defined
to use that protocol.

My argument is mainly religious, and concerns the known benefits
of ensuring protocol and service definition are separated. There are
just always enviornment-specific cases where the service needs a different
policy.

I could expect the PKIX "policy" document to perhaps list those
operating expectations - codifying thus the minimal operational conformance
criteria for PKIX-conformant IAs, based on their global reasonableness. 
One could then expect the policy statment of each CA to claim it satisfies
the PKIX expectation/issues list, should it wish. 

If there are indeed elements of default policy built into the 
protocol design, based on the designer's expections and beliefs,
then perhaps they should be identified as options (or at least identified
for review purposes), and, as I say, possibly abstracted out as generic
policy rules in the policy document.

Given that the judgements were already taken, and are present in the document,
they cannot be too hard to at least enumerate. This will
serve later, by elimination of certain types of 
legal debate as to intended meanings and policy purposes
of technical specs.

(b) Expectation-based handling of conditions such as "one key : one
certificate",
which may produce ambiguity potential, really worry me. Either the policy
mechanism and key usage mechanisms in X.509 are sufficient, or  not (*). It
seems once again we are avoiding use (or design) of standard instruments, and
loading semantics and expectations mechanisms into technical procedures.

Where there are signals for such purposes, and std or per-CA policy
documents to disclose their very precise semantics, it worrying
to see their non-use, and therefore a potential biasing
of the technical protocol design.

(* little can prevent one key being issued with one set of characterisics
by one CA, and another set by another CA, and being
used by a single subscriber. The only differentiator of
semantics and requirements for enrollment ultimately is the issuing policy
(CPS) of the CA, and are ultimately enforced only via the agreements of
the subscribers and verifying parties, to the various request, use and
reliance obligations)

(c)

"Requiring proof of possesion as part
of certificate issuance helps prevent such unsolicited issuance, since a CA
would not be able to prove that I requested the cert in question."

Once again, I see "leakage" of semantics. We start out with an expectation
that its good practice to have proof of possession, and now the CA has
suddenly received the obligation to possibly prove it received a request,
based upon that information.

This would lead me to believe, that the mandatory mechanism could
have the effect of requiring CAs to maintain and verify proof of request,
given
an available mechanism exists for such purpose.

In agreeing to enforce something socially friendly (.e. prove possession), a
CA now find itself suddenly loaded with ambiguity of semantics, and
consequently
additional handling obligations which have nothing to do with the intended
effect on the quality of the PKI, but which may instrument legal and
political matters. Who knows what other implications there are, once there
is a first - instrument for registration of crypto-capabilities, possibly!?

Perhaps the generic issuing (aka CA ethical behaviour) policy of PKIX
wishes to
mandate such matters; but once again, the issue should be explicit, and
separated
from  a specification of message formats and crypto handling procedures.
Issuing parties can then claim conformance to (i) technical matters (ii)
generic
policy matters, as their markets and customers require.

This was a very way of saying I really disagree with little except your
basic conclusions.  

At 04:04 PM 2/21/97 -0500, Stephen Kent wrote:
>Frank,
>
>	let me see if I understand the scenario you cited a a justification
>for not requiring a user to demonstrate possesion of a private key.  A CA
>wants to create a cert with some authorization extensions by taking a
>public key from some other cert and stuffing it into the new cert.  The CA
>doing this is inside a net associated with the resources to which access
>will be granted, based on use of the new cert.  However, this CA is not
>able to allow a cert request to reach it from outside, where the user who
>is to be granted authorization lives, presumably due to security concerns.
>Is this an accurate characterization?
>
>	If so, I'd like to observe that CAs performing online cert issuance
>tend to operate in the fashion that your scenario suggest would not be
>vaible, i.e., the CA is behind a firewall and it receives cerg requests
>from the open Internet, and that is exactly how it does it's job.  We have
>supplied CAs of this sort to clients, and I know of others that work this
>way, and it has not been a problem.  Also reusing the same key in multiple
>certificates is often frowned upon, since it is not clear under what policy
>the keys are being used, i.e., ambiguity results when any of several
>certificates can be matched to the same private key.
>
>	The second set of examples you provided also concern me.  As a
>user, I don't want to be issused a certificate that I didn't ask for, but
>with my public key in it, in much the same way that I don't like receiving
>unsolicited credit cards on the mail.  Requiring proof of possesion as part
>of certificate issuance helps prevent such unsolicited issuance, since a CA
>would not be able to prove that I requested the cert in question.  (Of
>course this does not solve the bigger problem of having a cert issed with
>some other public key in it and having it bound to my name, but relaxing
>the proof-of-possesion requirement also does not address that problem.)
>
>	It seems that there might be a common thread in these examples,
>i.e., the question of whether a third party ought to be able to cause a
>certificate to be issued containing a key already associated with a user,
>but without the consent or active participation of the user.  Is this a
>feature, or a bug?  Making proof-of-possesion an optional aspect of cert
>requests side steps the question, but is that good?
>
>Steve
>
>
>
>

Date: Fri, 21 Feb 1997 16:38:42 -0800
To: Carlisle Adams <[email-masked]>
From: Peter Williams <[email-masked]>
Subject: RE: Private key possession
Cc: "[email-masked]'" <[email-masked]>

Carlise

I suspect you dont mean all this in the literal legal sense, as its
just not appropriate for the techncial PKIX1/3 specs to be apparently
engineering a legal framework by virtue of its conformance
claim design. Its not appropriate for an ISO standard, even given
its due process and PICS methods, and even less for an RFC.

While I would expect any security provider to explain
to the jury why they did not use a standard and publicly
reviewed security process/format (having had some proprietary equivalent
function broken, and causing user damages), I dont see the language
of, or function of, PKIX ever being so tightly drafted or agreed
so as to serve more specific judicial purposes concerning regulation
of IAs, or supporting civil/professional actions against IAs not satisfying
their own local or policy claims.
 
We have to be sure any such intentions are exorcised from
a technical interworking spec. If the technical document
is truely being rigged for such non-technical purposes, we need
much more careful review by accreditation and legal specialists.

Such matters are clearly policy.

 If a CA claims conformance to PKIX,
>and PKIX mandates proof-of-possession, then when it is discovered that
>the CA did not actually do the proof-of-possession (i.e., certificates
>are found for Alice and Bob which contain the same public key), legal
>action can be taken against the malpractice.  The CA can be sued for
>damages, or driven out of business, or whatever.  In any case, its
>certificate is revoked and all certificates issued by it will no longer
>verify.  If, on the other hand, proof-of-possession is optional or
>absent, no legal recourse is available a 

To: [email-masked]
Cc: [email-masked]
Subject: Re: Private key possession 
Date: Sat, 22 Feb 1997 00:03:39 +0000
From: "Frank O'Dwyer" <[email-masked]>

> Frank O'Dwyer argues against requiring a CA to require a subject to prove
> possession of a private key before the CA issues a certificate (binding the
> subject to a public key).  His argument seems to be that such cooperation
> of the subject means that the subject consents to all attributes in the
> certificate.  I don't see any such semantics implicit in proof of
> possession of a private key.

No, that's not what I meant. If the _only_way_ of requesting 
a certificate requires that a proof of possession of the 
private key be done, then this (as a side effect) turns the 
private key into an instrument of granting and witholding 
consent to certification requests. (N.B. - _requests_).  I don't 
believe that's what is intended, and I think it stops you from 
doing some interesting applications.

>From talking to Stephen Farrell, I gather that a possibility
is in fact that the proof would be (required to be) done to 
an RA, but a CA might not necessarily require it of
an RA.  If I have that right, then that would answer
all the concerns I raised in my previous message, since
an RA could ask for any certificate it liked, without
necessarily needing to know the subject's private key.
(And of course a CA could create any certificate it
wanted to anyhow).

Just to be clear, I do think it's a good idea that somebody
somewhere always requires a demonstration of private key
possession, since it is a simple measure that makes many 
"social engineering" attacks against the CA significantly 
more difficult.  The RA seems like a good place to do it. It 
limits the scope for abuse of requests (because most entities 
are not RAs), without limiting what you can implement with 
the PKIX.  However putting the requirement all the way back 
at the _CA_ would imo be too restrictive, for the reasons I 
gave before. 

Cheers,
Frank O'Dwyer.

Date: Fri, 21 Feb 1997 16:05:56 -0800
To: Carlisle Adams <[email-masked]>
From: Peter Williams <[email-masked]>
Subject: RE: Private key possession
Cc: "[email-masked]'" <[email-masked]>

Carlise,

I have no problem verifying the PKCS#10 SIGNED protocol elements (using
the procedures defined by the signature algoirithm) on incoming subscription
requests seeking to register certified keys, and thus ensuring
the CA has assurance of the originator's possession of the private
key.

Now, is this issue so critical in PKIX, and therefore mandatory
for conformance, that I have, as a result, say, to keep proper
(repeatable) and auditable records of this verification?

We are all agreed testing availability of the private key is
generally a good thing, though some argue there
are contrary cases. Now why are some folk insisting its
mandatory for conformance, versus merely a recommendation, say?
 
Is there a functional or implementation assurance condition present,
which can be made explicit to substantiate such
the "mandatory" condition requirement?

"(especially given the assurance it offers)"

  >To be perfectly honest, I don't understand what all the resistance is
>about.  It's not like adding proof-of-possession adds much extra
>computation or overhead to the protocol (especially given the assurance
>it offers).  Furthermore, all those proponents of PKCS #10 (Peter, I
>believe you were one) already *do* proof-of-possession.  PKIX-3 is
>simply stating that this should be done for encryption and
>Diffie-Hellman certification requests as well, which PKCS #10 does not
>do in its present form.
>
>>--------------------------------------
>>Carlisle Adams
>>Entrust Technologies
>>[email-masked]
>>---------------------------------------
>
>

Date: Fri, 21 Feb 1997 16:16:19 -0500
To: Peter Williams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Private key possession
Cc: [email-masked]

Peter,

	I don't agree with your conclusions, though I understand the
principle you cite.  If our standards require CAs to engage in a protocol
that demonstrates the certificate requestor does hold the corresponding
private key, then we are, I believe, codifying a practice that most people
would assume is appropriate and that is consistent with the basic premises
of certification, i.e., that the subject of a certificate does hold the
corresponding private key.  True, we cannot ensure that all CAs will do
this, or will do it properly, but if they fail to do so, then they are
non-compliant (and will burn in the fires of hell as a result, no doubt).
I think we are merely trying to establish a convention that matches normal
expectations, and I have not seen any arguments that convince me that this
is a bad thing to do, i.e., that this is an unduly restrictive policy.
Yes, one could accomplish a similar (maybe equivalent) effect through the
use of appropriate CPSs, but I'm not sure that is the right basis on which
to make this decision.

 	Do we believe that there are circumstances where issuance of a cert
is appropriate and yet the subject does not hold the private key?  If not,
then is the issue that it is infeasible for the subject to demonstrate
possesion of the private key?   If neither or the above, I see no reason
for making this an optional, vs. mandatory, aspect of certificate issuance.

Steve

Date: Fri, 21 Feb 1997 16:04:52 -0500
To: "Frank O'Dwyer" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Private key possession
Cc: [email-masked], "David P. Kemp" <[email-masked]>, [email-masked]

Frank,

	let me see if I understand the scenario you cited a a justification
for not requiring a user to demonstrate possesion of a private key.  A CA
wants to create a cert with some authorization extensions by taking a
public key from some other cert and stuffing it into the new cert.  The CA
doing this is inside a net associated with the resources to which access
will be granted, based on use of the new cert.  However, this CA is not
able to allow a cert request to reach it from outside, where the user who
is to be granted authorization lives, presumably due to security concerns.
Is this an accurate characterization?

	If so, I'd like to observe that CAs performing online cert issuance
tend to operate in the fashion that your scenario suggest would not be
vaible, i.e., the CA is behind a firewall and it receives cerg requests
from the open Internet, and that is exactly how it does it's job.  We have
supplied CAs of this sort to clients, and I know of others that work this
way, and it has not been a problem.  Also reusing the same key in multiple
certificates is often frowned upon, since it is not clear under what policy
the keys are being used, i.e., ambiguity results when any of several
certificates can be matched to the same private key.

	The second set of examples you provided also concern me.  As a
user, I don't want to be issused a certificate that I didn't ask for, but
with my public key in it, in much the same way that I don't like receiving
unsolicited credit cards on the mail.  Requiring proof of possesion as part
of certificate issuance helps prevent such unsolicited issuance, since a CA
would not be able to prove that I requested the cert in question.  (Of
course this does not solve the bigger problem of having a cert issed with
some other public key in it and having it bound to my name, but relaxing
the proof-of-possesion requirement also does not address that problem.)

	It seems that there might be a common thread in these examples,
i.e., the question of whether a third party ought to be able to cause a
certificate to be issued containing a key already associated with a user,
but without the consent or active participation of the user.  Is this a
feature, or a bug?  Making proof-of-possesion an optional aspect of cert
requests side steps the question, but is that good?

Steve

Date: Fri, 21 Feb 1997 15:25:04 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Private key possession
Cc: [email-masked]

Denis,

	The notion of a user countersigning a certificate does address the
problem you cited, but since not all uses of signature certificates are for
non-repudiation, it seems more appropriate to have an application that
requires non-repudiation engineer the necessary mechanisms into the
application.  Otherwise one could make the argument that a timestamp should
be included with each signature (and I have seen such proposals), because
of the benefits that would accrue in some applications.

	Now one might argue that there are other, more general benefits to
the countersigned cert approach, but the required change to the cert format
is rather significant and one would have to marshall a lot of strong
arguments in order to persuade folks to accept it.  I don't think we have
seen such arguments and, given the charter of PKIX (relative to .509) I
don't think it is within scope for this WG.

Steve

Date: Fri, 21 Feb 1997 15:50 -0500
From: "Simonetti David" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Profiles, Profiles, Profiles

Anil,

I understand your dilemma, and will try to address some of your issues.

I expect the MISPC profile and the Federal PKI profile to agree, if not be 
one in the same, at some point, so I'd like to leave that as that.

The MISSI profile and Federal profile have differences that are mainly due 
to two reasons.  First, MISSI is developing its own components, e.g., CAW 
and User Agent.  The Federal group is constrained by the use of "Commercial 
Off The Shelf" (COTS) products.  Thus, as an example, MISSI profiles the use 
of what I might consider "efficiency-related" extensions such as 
authorityKeyIdentifier and subjectKeyIdentifier.  We've reasoned that 
requiring the Federal COTS products to implement these extensions may be 
overly constraining, and products shouldn't be ruled out solely because they 
did not implement these two extensions.  The Federal profile does, however, 
recommend use of these extensions whenever possible.

Secondly, MISSI and the FPKI operate under fundamentally different 
architectures.  MISSI implements a strictly hierarchical infrastructure and 
prohibits cross-certification at any level below their top-level CA (Policy 
Approving Authority - PAA).  The FPKI implements a hybrid infrastructure 
combining elements of the hierarchical and network infrastructure models 
(recommend you review the FPKI CONOP for more info here).  These fundamental 
differences necessitate differences between the profiles.  The 
inhibitPolicyMapping field of policyConstraints is probably a good example 
of one difference.

There are also fundamental differences between the PKIX infrastructure and 
the MISSI/FPKI infrastructures.  PKIX does not assume the existence of an 
X.500 Directory, and, for example, allows the subject of the base 
certificate to be "null" and the subjectAltName to be of some form other 
than directoryName.  MISSI and FPKI continue X.500 reliance and require the 
subject of the base certificate to be the directoryName (yes, potential 
non-interoperabilty), and make more limited use of the subjectAltName 
extension.  Additionally, PKIX has added private extensions which are not 
part of the MISSI/FPKI profiles.

In summary, there are many fundamental differences between the target 
systems, much too many for me to identify here.  I recommend you review the 
subject documents for each system; they are intended to provide sufficient 
detail for implementation (the FPKI document is still draft; I am, at this 
moment, updating it based on recent comments).  I think it is up to the 
product vendors to decide which community they see as a potential market, 
and develop their products based on that community's requirements.  I think 
the safe bet is to implement X.509 as it is written (I hope!).  It will then 
be up to the CAs to generate certificates that will work between the 
intended systems.

Hope this helps some.

David Simonetti
Booz-Allen & Hamilton
900 Elkridge Landing Road
Linthicum, MD 21090
 ----------
From: Anil R. Gangolli
To: Simonetti David
Cc: ietf-pkix
Subject: Re: Profiles, Profiles, Profiles
Date: Friday, February 21, 1997 1:56PM

Simonetti David wrote:
>
> Anil,
>
> I am the author of several of these profiles (MISSI and Federal PKI) and 
let
> me say that interoperability is one of the primary objectives in this 
work.
>  We have worked closely in the past with those contributing to the PKIX 
and
> MISPC work to ensure that there are no interoperability concerns.
>
> Due to the general nature of X.509, I feel it is necessary that these
> profiles be developed to, in fact, foster interoperability.  The intent of
> the profile is to standardize implementations and reduce the complexity of
> certificate generation and certificate processing.  That is why we feel it
> necessary in the MISSI and Federal PKI profiles to provide somewhat more
> detail that other profiles.  We also feel that specific extensions
> undoubtedly increase the security of the infrastructure, and that is why
> they are explicitly "profiled in".
>
> Also note that the profiles are not meant to be all inclusive.  The 
profiles
> for MISSI and Federal PKI (and an uncoming ISO profile) all permit
> communities the opportunity to tailor and control certificate and CRL 
usage.
>
> If you have any specific questions on the profiles, please feel free to
> contact me.
>
> David Simonetti
> Booz-Allen & Hamilton Inc.
> 900 Elkridge Landing Road
> Linthicum, MD 21090

Hi, and thank you for responding.

I fully agree on the need and support this effort.  My only objection
is to the plural "profiles".

If there is indeed a common core to these proposals, it should be made
explicit.  Interoperability depends on this core.  Maintaining
multiple specifications for this common part introduces its own
problems: First different language is prone to different
interpretation and is thus detrimental to interoperability.  Second,
maintaining different specifications is comparable in difficulty to
maintaining different versions of software --it's hard.

There are many out here like me who are trying to keep abreast of these
proposals in order to implement compliant and interoperating software.
The worthy efforts by you and others in these working groups towards
maintaining commonality would be more apparent (and more usable) if, at
very least, the specifications would provide some comparative annotation
and justification for the differences.  At present every reader of
every profile spec is left to fend for themselves in this regard.

At the risk of sounding repetitive, if you have (or anyone else
reading has) a field-by-field comparison available, I would appreciate
it if you could post it.  I think it would be of service
to the community as well.

If you could even summarize the differences between those profiles
to which you contribute, that would also be helpful to some degree.

 --a.

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Private key possession
Date: Fri, 21 Feb 1997 14:34:36 -0500
Encoding: 117 TEXT

Hi,

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Thursday, February 20, 1997 2:58 PM
>To: 	[email-masked]; [email-masked]
>Cc: 	[email-masked]
>Subject: 	Re: Private key possession
>
>I would personally agree with the notion than an Internet-centric CA
>infrastructure 
>which is NOT given over to ONLY supporting non-repudation grade services,
>should NOT need to make the estabishment of private key of a subscriber a
>mandatory,
uniform requirement, or that all PKIX-using software should assume such
>a condition
>of a CA claiming conformance to PKIX
>
>I would argue, that based on the disclosed operating policy of the CA, and
>any reliability criteria, such a property can be relied upon by those
>subscribers/users 
>with a need, based upon their "acceptance" and utility of the policy rules to
>their environment.
>
All I agreeing technically here, is that technical mechanisms and
>operating policy are
naturally separated in this protocol standard, as everywhere else in the
>open networking world.
>
>On this basis, I would agree with Denis' proposal to change the mandatory
>language, and do 
>react to the apparent intent of those who wrote it to uniformly constrain the
>key management infrastructure in a policy-specific manner.

Rather than invent slightly malicious "intent" out of the blue, impute
it to another party, and then publicly criticize that party for
supposedly having that intent, why don't we try to focus on the facts of
the issue at hand?

What, exactly, does a CA do?  It may do a number of things, but the
primary thing that it does (in fact, it's entire reason for existence)
is to assert a binding between an entity and a key.  This binding is,
after all, the definition of a certificate, and a CA is not a CA if it
does not issue certificates.  Fair enough, but *which* key?  On the
surface, it appears that the binding is between the entity and the
public key, since this is what the certificate contains.  A few moment's
reflection, however, will show that this couldn't possibly be true.  The
public key, by definition, is a purely public quantity; anyone (and, if
interested, everyone) can claim knowledge of it, and an assertion to
that effect by a CA is a completely meaningless assertion.

No, the CA asserts a binding between the entity and the private key.
Under two assumptions ("a", that the entity is the only one who knows
the private key, and "b", that it is computationally infeasible to
derive the private key from the public key), a certificate for Joe says
that "if you encrypt something using the contained public key then only
Joe can decrypt it", or "if you verify a signature using the contained
public key then Joe must have signed it".  Clearly, the CA can only
validly assert such a binding if, in fact, it is convinced that such a
binding exists.

It is hard to put this any more clearly.  This is *not* a policy issue,
by any stretch of the imagination.  A certificate (by definition) states
a binding between an entity and its *private* key and a CA (by
definition) is trusted to be the one to assert this binding.  This is
the fundamental underlying principle of a public key infrastructure
(i.e., without this principle "certificates" are meaningless bundles of
bits and there is no credible PKI).

Making proof-of-possession-of-private-key a mandatory aspect of the
certification process is not "constraining the key management
infrastructure in a policy-specific manner".  It is making explicit an
underlying principle of the PKI and ensuring that it is implemented
correctly.  This may not be so important in a closed environment in
which one vendor supplies all the bits and pieces and builds the same
assumptions into them all, but it is critical in an open environment
with open protocols and multiple vendors.  That is what PKIX is trying
to design for the Internet PKI so it is essential to make those
assumptions explicit so that all the bits and pieces do the right thing.

O.K., so at this point presumably Denis jumps in and says that he can't
trust a CA to do the "right thing" even if it is mandatory in the
protocol, which is why he raised this issue in the first place.  His
solution is to make it optional (or absent) in the protocol and to put
the necessary checks and balances in other operational protocols (or
perhaps even to modify the certificate format itself).  On the contrary,
it seems to me that the issue he raises shows that proof-of-possession
really should be mandatory.  Why?  If a CA claims conformance to PKIX,
and PKIX mandates proof-of-possession, then when it is discovered that
the CA did not actually do the proof-of-possession (i.e., certificates
are found for Alice and Bob which contain the same public key), legal
action can be taken against the malpractice.  The CA can be sued for
damages, or driven out of business, or whatever.  In any case, its
certificate is revoked and all certificates issued by it will no longer
verify.  If, on the other hand, proof-of-possession is optional or
absent, no legal recourse is available and there is no way to remove the
bad certificates from the system.  Note that making proof-of-possession
mandatory does not preclude putting checks and balances in other
protocols anyway, if people want to do so; it just makes them
unnecessary.

To be perfectly honest, I don't understand what all the resistance is
about.  It's not like adding proof-of-possession adds much extra
computation or overhead to the protocol (especially given the assurance
it offers).  Furthermore, all those proponents of PKCS #10 (Peter, I
believe you were one) already *do* proof-of-possession.  PKIX-3 is
simply stating that this should be done for encryption and
Diffie-Hellman certification requests as well, which PKCS #10 does not
do in its present form.

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

Sender: [email-masked]
Date: Fri, 21 Feb 1997 10:47:34 -0800
From: "Anil R. Gangolli" <[email-masked]>
Organization: Netscape Server Product Development
To: Simonetti David <[email-masked]>
CC: [email-masked]
Subject: Re: Profiles, Profiles, Profiles

Simonetti David wrote:
> 
> Anil,
> 
> I am the author of several of these profiles (MISSI and Federal PKI) and let
> me say that interoperability is one of the primary objectives in this work.
>  We have worked closely in the past with those contributing to the PKIX and
> MISPC work to ensure that there are no interoperability concerns.
> 
> Due to the general nature of X.509, I feel it is necessary that these
> profiles be developed to, in fact, foster interoperability.  The intent of
> the profile is to standardize implementations and reduce the complexity of
> certificate generation and certificate processing.  That is why we feel it
> necessary in the MISSI and Federal PKI profiles to provide somewhat more
> detail that other profiles.  We also feel that specific extensions
> undoubtedly increase the security of the infrastructure, and that is why
> they are explicitly "profiled in".
> 
> Also note that the profiles are not meant to be all inclusive.  The profiles
> for MISSI and Federal PKI (and an uncoming ISO profile) all permit
> communities the opportunity to tailor and control certificate and CRL usage.
> 
> If you have any specific questions on the profiles, please feel free to
> contact me.
> 
> David Simonetti
> Booz-Allen & Hamilton Inc.
> 900 Elkridge Landing Road
> Linthicum, MD 21090

Hi, and thank you for responding.

I fully agree on the need and support this effort.  My only objection
is to the plural "profiles".

If there is indeed a common core to these proposals, it should be made
explicit.  Interoperability depends on this core.  Maintaining
multiple specifications for this common part introduces its own
problems: First different language is prone to different
interpretation and is thus detrimental to interoperability.  Second,
maintaining different specifications is comparable in difficulty to
maintaining different versions of software --it's hard.

There are many out here like me who are trying to keep abreast of these
proposals in order to implement compliant and interoperating software.
The worthy efforts by you and others in these working groups towards
maintaining commonality would be more apparent (and more usable) if, at
very least, the specifications would provide some comparative annotation
and justification for the differences.  At present every reader of
every profile spec is left to fend for themselves in this regard.

At the risk of sounding repetitive, if you have (or anyone else
reading has) a field-by-field comparison available, I would appreciate
it if you could post it.  I think it would be of service
to the community as well.

If you could even summarize the differences between those profiles
to which you contribute, that would also be helpful to some degree.

--a.

Date: Fri, 21 Feb 1997 10:41:37 -0500
From: John Lowry <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Private key possession
Cc: [email-masked], [email-masked]

Of course attributes are assigned by a CA and not automatically
grated because the end user asked for them. They have to prove
possession of the attribute (for some value of prove) just as they
have to prove possession of the secret key.

Attributes can also be assigned administratively.
It really doesn't matter whether you "concent" to an attribute.  An authority
may assign one for their own (or other's) purposes.  It works like that today.
Suppose you really are a bad risk for a loan.  Obviously you would
not want an attribute certificate generated that made that statement.
Tough nuggies.  If you are then you are.  If you aren't a bad risk
then use existing procedure to fix it or sue.

John

> From [email-masked]  Thu Feb 20 20:13:03 1997
> To: [email-masked]
> cc: "David P. Kemp" <[email-masked]>, [email-masked]
> Subject: Re: Private key possession 
> Mime-Version: 1.0
> Date: Fri, 21 Feb 1997 00:43:48 +0000
> From: "Frank O'Dwyer" <[email-masked]>
> 
>  
> There is another reason why demonstrating possession of a private 
> key might not be a good thing to make mandatory, and I think it
> is more plausible than the patent example. For example, I might 
> want to make a local intranet certificate which binds certain 
> X.509 extensions to your key.  This certificate permits you (say) 
> to upload signed files via my firewall. That doesn't seem an
> unreasonable requirement, but I can't do it if I need to demonstrate 
> ability to use your private key. Certainly you (or your agent) could 
> request the same cert, but an intranet CA is likely to reject 
> out of hand certification requests that originate from outside.  
> 
> There are clearly other examples, too, where you might not want
> to consent to an attribute (e.g. it says you are not a
> good risk for a loan). Or, it might be confidential (you can't
> decrypt it and therefore _can't_ consent to it). Still, I might wish 
> to request it, the CA might be willing to grant it, and someone else 
> might wish to trust it.  But it's all impossible if I have to know 
> your private key.  
> 
> Seems like a broad class of applications to be ruling out.
> 
> Cheers,
> Frank O'Dwyer.
> 

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Fri, 21 Feb 1997 10:33:29 -0400
Subject: Re: Private key possession

Gene Hilborn/SED/CSC
02/21/97 10:33 AM

Frank O'Dwyer argues against requiring a CA to require a subject to prove
possession of a private key before the CA issues a certificate (binding the
subject to a public key).  His argument seems to be that such cooperation
of the subject means that the subject consents to all attributes in the
certificate.  I don't see any such semantics implicit in proof of
possession of a private key.
An analogous argument is saying that if I go into court and prove who I am
then I am consenting to whatever I am accused of.  Not so.  That is a
separate issue.

There could be an implicit consent to certificate content when a subject
includes and signs the certificate in a transaction, but that is a
different matter.

I see the real issue as simply whether every PKIX-compliant CA should be
*required* to use some specified mechanism to verify that for each of its
certificates, a public-key-submitting subject has current possession/usage
of the corresponding private key.   Or, should this verification be
entirely optional as a matter of a CA's policy.  If it such verification is
optional, interoperability will be enhanced by limiting the CA's choices of
mechanisms/protocols to a small specified set - perhaps one.

Gene Hilborn

Date: Fri, 21 Feb 1997 10:17 -0500
From: "Simonetti David" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Profiles, Profiles, Profiles

Anil,

I am the author of several of these profiles (MISSI and Federal PKI) and let 
me say that interoperability is one of the primary objectives in this work. 
 We have worked closely in the past with those contributing to the PKIX and 
MISPC work to ensure that there are no interoperability concerns.

Due to the general nature of X.509, I feel it is necessary that these 
profiles be developed to, in fact, foster interoperability.  The intent of 
the profile is to standardize implementations and reduce the complexity of 
certificate generation and certificate processing.  That is why we feel it 
necessary in the MISSI and Federal PKI profiles to provide somewhat more 
detail that other profiles.  We also feel that specific extensions 
undoubtedly increase the security of the infrastructure, and that is why 
they are explicitly "profiled in".

Also note that the profiles are not meant to be all inclusive.  The profiles 
for MISSI and Federal PKI (and an uncoming ISO profile) all permit 
communities the opportunity to tailor and control certificate and CRL usage.

If you have any specific questions on the profiles, please feel free to 
contact me.

David Simonetti
Booz-Allen & Hamilton Inc.
900 Elkridge Landing Road
Linthicum, MD 21090
 ----------
From: Anil R. Gangolli
To: ietf-pkix
Subject: Profiles, Profiles, Profiles
Date: Thursday, February 20, 1997 9:12PM

I am aware of the following certificate, crl, and/or verification
profiles in development or existence today:

1. PEM   (will be mostly obsolete, I expect, after PKIX)
2. PKIX  (IETF)
3. MISSI
4. MISPC (NIST)
5. Federal PKI (Federal PKI-TWG)

I worry that the proliferation of certificate profiles
poses a serious threat to interoperability and will
slow down the adoption and usability of PKI as a whole.

Most of these profiles specify contents requirements for
each field in the certificate, crl, etc..  Has anyone here
done a comparative field-by-field analysis of these to
see where they are in common and where they differ?
(I suppose a comparitive analysis of the verification
procedures may be harder to write down succinctly.)

Any comparative analysis would be useful both to the IETF
PKIX effort as well as these other profile efforts.
Ideally there would be  one uniform profile across
the board, but barring that, at least one could hope
for (and drive toward) the minimal differences in
profiles that are needed to support any actual
differences in requirements.

Thanks in advance for any information in this area.
 --a.

Subject: RE: Profiles, Profiles, Profiles
From: [email-masked] (Judith A. Furlong)
To: [email-masked] (Anil R. Gangolli)
cc: [email-masked]
Date: Fri, 21 Feb 97 07:34:16 -0500

SET also has its own Certificate & CRL profile.  (See Part II of the 
Programmer's Guide)

I have done some comparative analysis of the Certificate and CRL profiles 
defined by PKIX, MISSI & SET.  This analysis has been focused more on field 
content versus processing rules.  I would be glad to talk with you about the 
comparison.

Judy Furlong
[email-masked]

>I am aware of the following certificate, crl, and/or verification
>profiles in development or existence today:
>
>1. PEM   (will be mostly obsolete, I expect, after PKIX)
>2. PKIX  (IETF)
>3. MISSI 
>4. MISPC (NIST)
>5. Federal PKI (Federal PKI-TWG)
>
>I worry that the proliferation of certificate profiles
>poses a serious threat to interoperability and will
>slow down the adoption and usability of PKI as a whole.
>
>Most of these profiles specify contents requirements for
>each field in the certificate, crl, etc..  Has anyone here
>done a comparative field-by-field analysis of these to
>see where they are in common and where they differ?
>(I suppose a comparitive analysis of the verification
>procedures may be harder to write down succinctly.)
>
>Any comparative analysis would be useful both to the IETF
>PKIX effort as well as these other profile efforts.
>Ideally there would be  one uniform profile across
>the board, but barring that, at least one could hope
>for (and drive toward) the minimal differences in
>profiles that are needed to support any actual
>differences in requirements.
>
>Thanks in advance for any information in this area.
>--a.
>
>

Date: Fri, 21 Feb 1997 09:44:40 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Peter Williams <[email-masked]>
Cc: [email-masked]
Subject: Re: Private key possession

Peter Williams wrote:

> Denis,
> 
> I like to know when my deductions from a claim assumption are false,
> and therefore thankyou for your definitive answer concerning the
> non-repudation semantics. 

Your original question was : Are you claiming this is a messaging
proof/non-repudiation of acceptance service ? As I was no claiming
anything,
I answered no.

The term you are using "non-repudiation of acceptance service" is new to
me, although I recognize that there are illimitted forms of
non-repudiation in addition to "non repudiation of origin" and "non
repudiation of delivery" as defined in ISO 7498-2 and 10181-4.

Looking more carefully to your mail let me now think that the dual
signature mechanism does provide a way to prove the acceptance of the
certificate and thus could be considered as an appropriate mechanism to
provide such a service ... provided that some one defines with some
English sentence what this really means in order to avoid multiple
interpretations   :-)

Denis.

-- 

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

Organization: Consensus Development Corporation <http://www.consensus.com/>
Date: Thu, 20 Feb 1997 18:40:13 -0800
To: "Anil R. Gangolli" <[email-masked]>
From: Christopher Allen <[email-masked]>
Subject: Re: Profiles, Profiles, Profiles
Cc: [email-masked]

At 5:11 PM -0800 2/20/97, Anil R. Gangolli wrote:
>1. PEM   (will be mostly obsolete, I expect, after PKIX)
>2. PKIX  (IETF)
>3. MISSI
>4. MISPC (NIST)
>5. Federal PKI (Federal PKI-TWG)

You should also consider S/MIME to be a profile. Another profile, though
not yet documented as such, is the SSL Certificate Profile.

Both are a little orthagonal to the above, but are more applicable in practice.

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

Sender: [email-masked]
Date: Thu, 20 Feb 1997 17:11:46 -0800
From: "Anil R. Gangolli" <[email-masked]>
Organization: Netscape Server Product Development
To: [email-masked]
Subject: Profiles, Profiles, Profiles

I am aware of the following certificate, crl, and/or verification
profiles in development or existence today:

1. PEM   (will be mostly obsolete, I expect, after PKIX)
2. PKIX  (IETF)
3. MISSI 
4. MISPC (NIST)
5. Federal PKI (Federal PKI-TWG)

I worry that the proliferation of certificate profiles
poses a serious threat to interoperability and will
slow down the adoption and usability of PKI as a whole.

Most of these profiles specify contents requirements for
each field in the certificate, crl, etc..  Has anyone here
done a comparative field-by-field analysis of these to
see where they are in common and where they differ?
(I suppose a comparitive analysis of the verification
procedures may be harder to write down succinctly.)

Any comparative analysis would be useful both to the IETF
PKIX effort as well as these other profile efforts.
Ideally there would be  one uniform profile across
the board, but barring that, at least one could hope
for (and drive toward) the minimal differences in
profiles that are needed to support any actual
differences in requirements.

Thanks in advance for any information in this area.
--a.

To: [email-masked]
cc: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: Private key possession 
Date: Fri, 21 Feb 1997 00:43:48 +0000
From: "Frank O'Dwyer" <[email-masked]>

There is another reason why demonstrating possession of a private 
key might not be a good thing to make mandatory, and I think it
is more plausible than the patent example. For example, I might 
want to make a local intranet certificate which binds certain 
X.509 extensions to your key.  This certificate permits you (say) 
to upload signed files via my firewall. That doesn't seem an
unreasonable requirement, but I can't do it if I need to demonstrate 
ability to use your private key. Certainly you (or your agent) could 
request the same cert, but an intranet CA is likely to reject 
out of hand certification requests that originate from outside.  

There are clearly other examples, too, where you might not want
to consent to an attribute (e.g. it says you are not a
good risk for a loan). Or, it might be confidential (you can't
decrypt it and therefore _can't_ consent to it). Still, I might wish 
to request it, the CA might be willing to grant it, and someone else 
might wish to trust it.  But it's all impossible if I have to know 
your private key.  

Seems like a broad class of applications to be ruling out.

Cheers,
Frank O'Dwyer.

Date: Thu, 20 Feb 1997 11:58:05 -0800
To: [email-masked], "David P. Kemp" <[email-masked]>
From: Peter Williams <[email-masked]>
Subject: Re: Private key possession
Cc: [email-masked]

At 02:19 PM 2/20/97 -0800, Denis Pinkas wrote:

>First, the [SPKI endorsement] example was there to show that when this
protocol is
>supported, only the CA can rely on it (and no one else)  

This is now crystal clear.

>At that time, the private key has expired and thus the token holding it
>is no more usable. No one is, at that time, able to sign anything.
>However the judge must still solve the case ...  

This indicates there are some needs to support third-party evaluation, some
of the time.

But, 

I would personally agree with the notion than an Internet-centric CA
infrastructure 
which is NOT given over to ONLY supporting non-repudation grade services,
should
NOT need to make the estabishment of private key of a subscriber a mandatory,
uniform requirement, or that all PKIX-using software should assume such a
condition
of a CA claiming conformance to PKIX

I would argue, that based on the disclosed operating policy of the CA, and
any reliability criteria, such a property can be relied upon
by those subscribers/users with a need, based upon their "acceptance" and
utility
of the policy rules to their environment.

All I agreeing technically here, is that technical mechanisms and operating
policy are
naturally separated in this protocol standard, as everywhere else in the open
networking world.

On this basis, I would agree with Denis' proposal to change the mandatory 
language, and do react to the apparent intent of those who wrote it to 
uniformly constrain the key management infrastructure in a policy-specific
manner.

Date: Thu, 20 Feb 1997 11:30:08 -0800
To: [email-masked]
From: Peter Williams <[email-masked]>
Subject: Re: Private key possession
Cc: [email-masked]

Denis,

I like to know when my deductions from a claim assumption are false,
and therefore thankyou for your definitive answer concerning the
non-repudation semantics. Now, we can look at the claim more carefully and
see if
it has any real meaning, and then, determine what that meaning is,
in detail.

I quote (again) your text, which led me down the dubious reasoning
path.

"This is a proof that the user not only knows the private key but also
accepts the
certificate."

Let's pull the claim apart, in more formal claims language.

1. The endorsement mechanism proves the user knows the private key.

2. The endorsement mechanism "demonstrates" [my insertion] that the subscriber
accepts the certificate.

How does the mechanism (of endorsement) "demonstrate" acceptance?

If it does not "demonstrate" acceptance, what does it do?

Does it "prove" some property of acceptance, if it does not prove the
performance
of the act of acceptance itself?

(The original claims language makes some grammatical allusion to there
being a useful "proof" event, presumably of sufficient merit to serve
as input for some enforcement process, though not one 
relying upon ISO-defined non-repudiation security service semantics)

I investigate this claim so carefully, for there would be many, many online
applications of the mechanism and its derived acceptance service, if it really
exists such that it satisifes the claim. As claimed, the service would be
useful
to the CA industry for its own purposes of assuring there to be sastified
customers
of certification services delivered in non face-to-face circumstances.

If however the mechanism has no determinable meaning to a third party, it
may not be very useful except in hand-waving security system designs!

If the only benefactor of the endorsement is the CA, then perhaps the CA
can encourage subscribers to merely use the cert in some protocol (SSL,
S/MIME etc)
with the CA as recipient to gain the fuzzy acceptance signal. There seems
little reasoned need to change formats or semantics of certs/CA, or
established
standard issuing and reliance models, when mere use conveys the 
same (vague, but warm and fuzzy) acceptance signal.

At 02:22 PM 2/20/97 -0800, Denis Pinkas wrote:
>Peter Williams wrote:
>
>> >Their document introduces the notion of a certificate counter-signed by
>> >the user. In such an architecture a certificate holds two signatures:
>> >one from the CA and another one from the user. In this way the user
>> >endorses the fact that the CA has issued the certificate. This is a
>> >proof that the user not only knows the private key but also accepts the
>> >certificate.
>> 
>> Are you claiming this is a messaging proof/non-repudiation of acceptance,
>> service?
>
>No.

To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: Private key possession 
Date: Thu, 20 Feb 1997 10:21:57 -0800
From: "Mike StJohns" <[email-masked]>

> Mike wrote:
> 
> > Clyde at the patent office scratches his head at the fact that both Alice
> > and Bob have sent patent requests for the same item... mumbles and then
> > sends back a request to both parties to resign the patent request this
> > time, including the text of their certificate within the patent request.
> > Alice promptly proves she posesses the private key corresponding to the
> > public key by signing the request. Bob, unable to validly sign the request,
> > feeling his days are numbered and looking over his shoulder for the FBI,
> > packs and leaves for Barracuda.
> 
> Your proposal works nicely but signing the request involves an extra
> exchange that can be avoided. I wrote :
> 
> "The general way to solve the problem is to include enough information 
> within the signed text to identify unambiguously the signer. (...) A
> more general solution is to reserve some place within the signed text 
> to insert at least the identifier of the certificate. The best being to 
> insert a certification path."
> 
> Basically, what I propose is to do it in the initial sending of the
> patent rather than doing it in an additional request coming from the
> patent office.
> 
> Denis

Denis - certificates do not stand on their own - basic to the concept is the 
fact you might have to prove any signature at a later time.

If you want to prove you know the private key of the public key in the 
certificate, include the certificate in what you have to sign....

S[privatekey]{patentrequest, certificate}  

(as per your suggestion...) but you may still have to recourse to having them 
prove they know the private key at a later time (especially if Alice is 
masquerading as Ann at a consulting company and has a certificate to prove 
it...)

Mike

Date: Thu, 20 Feb 1997 14:27:21 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Paul Kierstead <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Private key possession

Paul Kierstead wrote:
> 
> >>The conclusion is that each CA SHOULD verify the possession of the
> >>private by the user before issuing a certificate containing the
> >>corresponding public key.
> >
> >>As a consequence, this means that having a protocol to verify the
> >>possession of a private signature key shall not be mandatory and if we
> >>defined one, it should only be optionally supported.
> 
> A very interesting case. However, I do not agree with your conclusion.
>
>               (...)                  . So PKIX should specify that a CA
> verifies private key ownership without making the assumption that it was
> done correctly.

I strongly agree with your conclusion and thus I am not sure that you
fully disagree with my conclusion  :-)

Denis

Note: see other responses made on the same topic as well.

> ------------------------------
> Paul Kierstead                  TimeStep Corporation
> mailto:[email-masked]            http:\\www.timestep.com
> 
> >

-- 

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

Date: Thu, 20 Feb 1997 14:22:55 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Peter Williams <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: Private key possession

Peter Williams wrote:

> >Their document introduces the notion of a certificate counter-signed by
> >the user. In such an architecture a certificate holds two signatures:
> >one from the CA and another one from the user. In this way the user
> >endorses the fact that the CA has issued the certificate. This is a
> >proof that the user not only knows the private key but also accepts the
> >certificate.
> 
> Are you claiming this is a messaging proof/non-repudiation of acceptance,
> service?

No.

> generalised it would say, if I send you a signed message, containing
> your public key bound to some datum, and you countersign that msg, this is
> a mechanism for proof of acceptance of datum, if a validator can find
> a public key value in the (next) inner-signed component which validates the
> outer signature. 

"proof of acceptance of datum" which looks like non repudiation of
acceptance of datum could not be provided by the mechanism you describe.
You are on a different thread here which is far away from the origional
topic that was discussed.

Denis

-- 

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

Date: Thu, 20 Feb 1997 14:19:16 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "David P. Kemp" <[email-masked]>
Cc: [email-masked]
Subject: Re: Private key possession

David P. Kemp wrote:
 
> > What I what to say is that we will have to live in a world where CAs,
> > when required to make that verification, will make it or not (and this
> > will happen whether we like it or not)  :-(
> 
> I agree completely with this, and also agree that adding the subject's
> countersignature to X.509 certificates is an interesting idea.
>
> (...)
> 
> But accepting this premise still doesn't lead to the conclusion that
> the PKIX standard should make the CA signature verification step
> optional.

Let me clarify the point. The question is whether we need a PROTOCOL for
doing this and whether that PROTOCOL shall be mandatorilly supported.

First, the example was there to show that when this protocol is
supported, only the CA can rely on it (and no one else) since there will
be no evidence that the CA will effectively perform the verification.

Second, the example was also given to show that we do not need this
protocol if, in the example, we use the private key to sign "some data"
including an identifier of the certificate (CA name+ serial number), or
even better of the certification chain (i.e. a certification path). That
signed data may be either:

 1 - the signed message which then includes the certificate identifier 
     (as this was initially proposed in my first E-mail),

 2 - the certificate itself which is then counter-signed by the user 
     (as this was mentionned in my second E-mail).

My position is thus that this protocol does *not* need to be
mandatorilly supported but that CAs *should* verify the possession of
the private key by any available means. 

Remember that in some cases the private key is given directly to the
user by the CA and then to the user through the RA. This protocol would
be useless in that case.

(...)
 
> If the patent office has two applications with the same signature, one
> with Bob's certificate from the Republic of Banana timestamped on Monday,
> and the other with Alice's certificate from (for example) GTE timestamped
> on Wednesday, they won't just blindly accept Bob's claim because it was
> received first.  They will (or should) investigate the reliability of
> the respective certification paths.

Correct.

> As long as signature verification is REQUIRED, if two CAs certify the
> same public key for two different subjects, you know that one of the CAs
> is lying.  It won't be difficult to determine which one - just bring
> Alice and Bob into court and ask them to sign something.

Bringing people into court takes about two years in some countries :-(

At that time, the private key has expired and thus the token holding it
is no more usable. No one is, at that time, able to sign anything.
However the judge must still solve the case ... Here is the reason why
this signature is indeed provided before the case happens, and not after
the event.
 
> But if signature verification by the CA is OPTIONAL, then two CAs could
> comply with the standard and still be absolved of all responsibility for
> issuing an invalid certificate.  

The verification of the possession of a private key is important for
regular CAs wishing to make sure that they guarantee the value of the
public key and the affiliation to a domain. As said earlier there are
many means to provide this, so that the *CA* can be confident about it,
but not that anyone else can be confident about it. One of these means
may be to use a protocol as proposed.

> I don't understand the motivation for not requiring proof of possession
> in the standard.  

The proposed protocol is one way of doing it, not the single mandatory
way.
In addition we should say that this protocol does not provide anyone
else than the CA that the user is effectively in possession of the
private key.

> We know that it is necessary.  We also admit that there
> may be CAs who will not verify possession regardless of whether it
> is required.

Yes.

> The only question is should such CAs be able to accurately claim that
> they comply with the PKIX standard?  Clearly, the answer is "no".

Complying would mean that the CA should do the verification by any
means, including this optional protocol, so that it can be convinced of
the possession of the private key.

Denis

-- 

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

Date: Thu, 20 Feb 1997 13:21:25 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: [email-masked]
Cc: [email-masked]
Subject: Re: Private key possession

Mike wrote:

> Clyde at the patent office scratches his head at the fact that both Alice
> and Bob have sent patent requests for the same item... mumbles and then
> sends back a request to both parties to resign the patent request this
> time, including the text of their certificate within the patent request.
> Alice promptly proves she posesses the private key corresponding to the
> public key by signing the request. Bob, unable to validly sign the request,
> feeling his days are numbered and looking over his shoulder for the FBI,
> packs and leaves for Barracuda.

Your proposal works nicely but signing the request involves an extra
exchange that can be avoided. I wrote :

"The general way to solve the problem is to include enough information 
within the signed text to identify unambiguously the signer. (...) A
more general solution is to reserve some place within the signed text 
to insert at least the identifier of the certificate. The best being to 
insert a certification path."

Basically, what I propose is to do it in the initial sending of the
patent rather than doing it in an additional request coming from the
patent office.

Denis

-- 

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

Date: Thu, 20 Feb 1997 08:59:34 +1100
From: Michael Warner <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Private key possession

> From: Denis Pinkas <[email-masked]>
> 
> Topic: Private key possession.
> 
><snip>
> 
> Let us take the following example:
> 
> Alice wishes to apply for a patent today and for doing so signs the 
> text of the patent using its private key, attach to it its certificate 
> and send the two pieces to a patent office. When receiving the two 
> pieces, the patent office would place a counter-signature from a 
> Trusted Time Stamping Authority on the whole package so that one can 
> make sure that the registration date is correct.
> 
> Since Bob intercepted the message from Alice, the patent office did not 
> received Alice's message at this time. Bob promptly asks to a CA 
> located in Barracuda (in the Republic of Banana) to issue a certificate 
> containing the same public key as Alice but with his name in it. For a 
> reasonable fee the CA omits to verify the possession of the private key 
> by the user before issuing the certificate. Thereafter Bob sends the 
> intercepted signed text of the patent and replaces Alice's certificate 
> by his new own certificate. When receiving the two pieces, the patent 
> office places a counter-signature from a Trusted Time Stamping 
> Authority on the whole package so that one can make sure that the 
> registration date is correct.
> 
> In such a scenario Bob would now the patent holder. If for some reason 
> Alice re-sends her message it will be time-stamped after the message 
> from Bob and she will not be recognized as the patent holder.
> 

As you later hint, the problem here lies not with the CA not checking 
the possession of the private key, but rather with the patent lodging
protocol.   Such a protocol must obviously explicitly associate the
identity of the person lodging the patent with the text of the patent.

I don't think extra effort should be tolerated in the certification
stage in an attempt to protect from poor protocol design in applications !

Cheers,

Michael Warner
Telstra Research Labs

Date: Wed, 19 Feb 1997 12:25:50 -0800
To: [email-masked], "David P. Kemp" <[email-masked]>
From: Peter Williams <[email-masked]>
Subject: Re: Private key possession
Cc: [email-masked]

 >
>Their document introduces the notion of a certificate counter-signed by
>the user. In such an architecture a certificate holds two signatures:
>one from the CA and another one from the user. In this way the user
>endorses the fact that the CA has issued the certificate. This is a
>proof that the user not only knows the private key but also accepts the
>certificate.

Are you claiming this is a messaging proof/non-repudiation of acceptance,
service?

generalised it would say, if I send you a signed message, containing
your public key bound to some datum, and you countersign that msg, this is
a mechanism for proof of acceptance of datum, if a validator can find
a public key value in the (next) inner-signed component which validates the
outer signature. And, of course this is itself generalizable: five users
get a CA to issue a cert containing 5 name/key bindings, each of which
is then endorsed in some order relevant to say a groupware authority
signoff process. A final counter-signature is then applied by
the CA again, to protect against loss of endorsements.

As a raw mechanism, I like it. Lots of possibilitees for
transactional certs environments which often mix third-party and user 
signatures.

 

Date: Wed, 19 Feb 1997 15:24:51 -0500 (EST)
From: Marc Branchaud <[email-masked]>
To: [email-masked]
Subject: Re: Private key possession 

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

Hi, all...

I've lost Denis's original message, so I can't quote it exactly, but he
mentioned a second scnario in which Alice signed both the patent text and
the certification path.  It seems to me that if this solved the problem,
then the problem is solved. 

The basic lesson is: if you don't want any part of your message to be
forged (including an attached certification path) then you should sign the
whole darn thing.  So Alice should have acted as she did in Denis's second
scnario in the first place.

		Marc

==============================	------ I'M LOOKING FOR A JOB! -----
        Marc Branchaud        	I'm looking for a full-time career,
       [email-masked]       	and I'm willing to move almost any-
    www.zoo.net/~marcnarc/    	where.  You can see my CV online at
==============================	www.zoo.net/~marcnarc/Marc-CV.htm

From: <[email-masked]>
To: [email-masked]
cc: [email-masked]
Date: Wed, 19 Feb 1997 13:49:57 -0400
Subject: Re: Private key possession

Gene Hilborn/SED/CSC
02/19/97 01:49 PM

Strawmen... I love strawmen...

> Topic: Private key possession.
>

> Alice wishes to apply for a patent today and for doing so signs the
> text of the patent using its private key, attach to it its certificate
> and send the two pieces to a patent office. When receiving the two
> pieces, the patent office would place a counter-signature from a
> Trusted Time Stamping Authority on the whole package so that one can
> make sure that the registration date is correct.
>
> Since Bob intercepted the message from Alice, the patent office did not
> received Alice's message at this time. Bob promptly asks to a CA
> located in Barracuda (in the Republic of Banana) to issue a certificate
> containing the same public key as Alice but with his name in it. For a
> reasonable fee the CA omits to verify the possession of the private key
> by the user before issuing the certificate. Thereafter Bob sends the
> intercepted signed text of the patent and replaces Alice's certificate
> by his new own certificate. When receiving the two pieces, the patent
> office places a counter-signature from a Trusted Time Stamping
> Authority on the whole package so that one can make sure that the
> registration date is correct.
>
> In such a scenario Bob would now the patent holder. If for some reason
> Alice re-sends her message it will be time-stamped after the message
> from Bob and she will not be recognized as the patent holder.

Clyde at the patent office scratches his head at the fact that both Alice
 and Bob have sent patent requests for the same item... mumbles and then
 sends back a request to both parties to resign the patent request this
 time, including the text of their certificate within the patent request.
Alice promptly proves she posesses the private key corresponding to the
public key by signing the request. Bob, unable to validly sign the request,
 feeling his days are numbered and looking over his shoulder for the FBI,
packs and leaves for Barracuda.

The possession of the private key of a public/private key pair is
sufficient (and necessary) to unambiguously identify a signer.
Bob's binding of Alice's public key into a certificate (without
him having possession of the private key) only permits Alice to
masquerade as Bob, not for Bob to masquerade as Alice - since Alice has
 the key.

Mike

Date: Wed, 19 Feb 1997 13:49:41 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Private key possession

> What I what to say is that we will have to live in a world where CAs,
> when required to make that verification, will make it or not (and this
> will happen whether we like it or not)  :-(

I agree completely with this, and also agree that adding the subject's
countersignature to X.509 certificates is an interesting idea.
It might require getting rid of the SIGNED and SIGNATURE macros
(which might be a good idea anyway, since the SIGNATURE macro makes
the short-sighted and incorrect assumption that all signature algorithms
are of the form ENCRYPTED { HASHED { data-to-be-signed }} ).

But accepting this premise still doesn't lead to the conclusion that
the PKIX standard should make the CA signature verification step
optional.

> Note: All this is still a matter of trust. My favorite sentence is : 
> give me your trust conditions and I will tell you what kind of solutions
> are appropriate.

If your trust model says that you will validate certificates issued by
the Republic of Banana, or by the VeriSign Class 1 CA (or any
of the other unverified online certificate issuers), then perhaps that
trust is misplaced.

On the other hand, when you choose to trust a reasonable-assurance CA, you
are choosing to rely not only on the authentication procedures
documented in their Certification Practices Statement, but the fact
that those procedures are actually followed when that CA issues a
certificate.

If the patent office has two applications with the same signature, one
with Bob's certificate from the Republic of Banana timestamped on Monday,
and the other with Alice's certificate from (for example) GTE timestamped
on Wednesday, they won't just blindly accept Bob's claim because it was
received first.  They will (or should) investigate the reliability of
the respective certification paths.

As long as signature verification is REQUIRED, if two CAs certify the
same public key for two different subjects, you know that one of the CAs
is lying.  It won't be difficult to determine which one - just bring
Alice and Bob into court and ask them to sign something.

But if signature verification by the CA is OPTIONAL, then two CAs could
comply with the standard and still be absolved of all responsibility for
issuing an invalid certificate.  (Assume that both of their CPSs say "we
rely on a birth certificate for proof of identity, and follow the required
parts of the PKIX protocol for certificate issuance".)

I don't understand the motivation for not requiring proof of possession
in the standard.  We know that it is necessary.  We also admit that there
may be CAs who will not verify possession regardless of whether it
is required.

The only question is should such CAs be able to accurately claim that
they comply with the PKIX standard?  Clearly, the answer is "no".

To: [email-masked]
cc: [email-masked]
Subject: Re: Private key possession 
Date: Wed, 19 Feb 1997 10:27:42 -0800
From: "Mike StJohns" <[email-masked]>

Strawmen... I love strawmen...

> Topic: Private key possession.
> 
 
> Alice wishes to apply for a patent today and for doing so signs the 
> text of the patent using its private key, attach to it its certificate 
> and send the two pieces to a patent office. When receiving the two 
> pieces, the patent office would place a counter-signature from a 
> Trusted Time Stamping Authority on the whole package so that one can 
> make sure that the registration date is correct.
> 
> Since Bob intercepted the message from Alice, the patent office did not 
> received Alice's message at this time. Bob promptly asks to a CA 
> located in Barracuda (in the Republic of Banana) to issue a certificate 
> containing the same public key as Alice but with his name in it. For a 
> reasonable fee the CA omits to verify the possession of the private key 
> by the user before issuing the certificate. Thereafter Bob sends the 
> intercepted signed text of the patent and replaces Alice's certificate 
> by his new own certificate. When receiving the two pieces, the patent 
> office places a counter-signature from a Trusted Time Stamping 
> Authority on the whole package so that one can make sure that the 
> registration date is correct.
> 
> In such a scenario Bob would now the patent holder. If for some reason 
> Alice re-sends her message it will be time-stamped after the message 
> from Bob and she will not be recognized as the patent holder.

Clyde at the patent office scratches his head at the fact that both Alice and Bob have sent patent requests for the same item... mumbles and then sends back a request to both parties to resign the patent request this time, including the text of their certificate within the patent request.  Alice promptly proves she posesses the private key corresponding to the public key by signing the request. Bob, unable to validly sign the request, feeling his days are numbered and looking over his shoulder for the FBI,  packs and leaves for Barracuda.

The possession of the private key of a public/private key pair is sufficient (and necessary) to unambiguously identify a signer.  Bob's binding of Alice's public key into a certificate (without him having possession of the private key) only permits Alice to masquerade as Bob, not for Bob to masquerade as Alice - since Alice has the key.

Mike

From: Paul Kierstead <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Private key possession
Date: Wed, 19 Feb 1997 12:19:25 -0500

>>The conclusion is that each CA SHOULD verify the possession of the 
>>private by the user before issuing a certificate containing the 
>>corresponding public key.
>
>>As a consequence, this means that having a protocol to verify the 
>>possession of a private signature key shall not be mandatory and if we 
>>defined one, it should only be optionally supported.

A very interesting case. However, I do not agree with your conclusion.
The specified requirements of the protocol/CA do not imply that you must
trust that it was done to spec. i.e. you can specify that something
_must_ be done without a third party (the patent office in your example)
making the assumption that it was done. So PKIX should specify that a CA
verifies private key ownership without making the assumption that it was
done correctly.

I'm not being horribly clear here, but I hope you get my gist...

------------------------------
Paul Kierstead			TimeStep Corporation
mailto:[email-masked]		http:\\www.timestep.com 

>

Date: Wed, 19 Feb 1997 18:14:07 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Carlisle Adams <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Private key possession

Carlisle,

Sorry, I answered to the E-mail from David first. Have a look at it
before reading that E-mail.

> It is amazing to me that you could possibly reach this conclusion after
> the scenario you just described.  Making the verification of the
> possession of the private key OPTIONAL (or not defining it at all) is
> *precisely* what allows such a problem to occur.  Making it MANDATORY,
> so that every end entity and every CA must comply with the rules in
> order to complete the protocol, is what prevents such a problem (which
> is why we concluded that it must be mandatory in the first place!).

If I could really be sure that each CA will effectively perform that
test and if the CA would be ready to provide me with such an evidence,
then I would say that I agree with you.

As mentioned in my response to David, there is a way to do it (by asking
the user to counter-sign his certificate), ... but I doubt that the PKIX
group will follow it.

> By the way, if you're not going to trust a CA to do this part of
> certification correctly, why in the world would you trust it to do any
> other part of certification correctly?

This might be the start of another thread ! I would prefer to follow one
thread at a time. Shortly speaking, it is not because a certificate
exists that I should trust it. I can have general rules saying, e.g.
that I believe a given CA in the UK allowed/able to certify the key of
another given CA in Germany, but I cannot have such rules necessarilly
for every end user (at the termination of a certification path). Rules
beteween CAs are "relatively" easy to handle, rules between end-users
and CAs are more difficult (e.g. whether name subordination is used or
not). Once again let us focuss on the first thread at this time.

Denis

-- 

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

Date: Wed, 19 Feb 1997 18:01:09 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "David P. Kemp" <[email-masked]>
Cc: [email-masked]
Subject: Re: Private key possession

David,

When posting that original message, I was expecting such comments but
let us look more closely:

> I believe that the protocol standard should REQUIRE CAs to verify
> possession of the private key, even given the existence of CAs who,
> for a reasonable fee, will ignore the standard.

What I what to say is that we will have to live in a world where CAs,
when required to make that verification, will make it or not (and this
will happen whether we like it or not)  :-(

There is an interresting solution proposed by SPKI (not to be confused
with PKIX !).

Their document introduces the notion of a certificate counter-signed by
the user. In such an architecture a certificate holds two signatures:
one from the CA and another one from the user. In this way the user
endorses the fact that the CA has issued the certificate. This is a
proof that the user not only knows the private key but also accepts the
certificate.

Should I change the scope of the problem by asking whether the group
wishes to change the definition of an X.509 certificate by adding a
counter-signature from the owner of the certificate ?

I think this would introduce a major change ... but would also solve the
problem, this is why I did not proposed it first  :-)

Between these two solutions I prefer the one described in my first paper
since it will introduce less dramatic changes.

I cannot think a solution where all CAs will effectively do this test,
... unless there is some permanent proof that the verification was
really made.

Note: All this is still a matter of trust. My favorite sentence is : 
give me your trust conditions and I will tell you what kind of solutions
are appropriate.

Denis

-- 

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

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Private key possession
Date: Wed, 19 Feb 1997 10:09:27 -0500
Encoding: 37 TEXT

Hi Denis,

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Wednesday, February 19, 1997 4:30 PM
>To: 	[email-masked]
>Subject: 	Private key possession
>
>Topic: Private key possession.
>
(...stuff deleted...)
>
>The conclusion is that each CA SHOULD verify the possession of the 
>private by the user before issuing a certificate containing the 
>corresponding public key.
>
>As a consequence, this means that having a protocol to verify the 
>possession of a private signature key shall not be mandatory and if we 
>defined one, it should only be optionally supported.

It is amazing to me that you could possibly reach this conclusion after
the scenario you just described.  Making the verification of the
possession of the private key OPTIONAL (or not defining it at all) is
*precisely* what allows such a problem to occur.  Making it MANDATORY,
so that every end entity and every CA must comply with the rules in
order to complete the protocol, is what prevents such a problem (which
is why we concluded that it must be mandatory in the first place!).

By the way, if you're not going to trust a CA to do this part of
certification correctly, why in the world would you trust it to do any
other part of certification correctly?

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

Date: Wed, 19 Feb 1997 10:24:45 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Private key possession

> From: Denis Pinkas <[email-masked]>
>
>  [patent timestamping scenario snipped]
>
> I do not believe that such a model is practical. So we have to 
> recognize that we have to live with cases where that trust cannot be 
> placed and thus to adopt the appropriate measures to deal without it.
> 
> The conclusion is that each CA SHOULD verify the possession of the 
> private by the user before issuing a certificate containing the 
> corresponding public key.
> 
> As a consequence, this means that having a protocol to verify the 
> possession of a private signature key shall not be mandatory and if we 
> defined one, it should only be optionally supported.

Denis,
  Very nice story and analysis.  However I don't agree that the conclusion
follows from the analysis.

In the U.S. state of Maryland, it is illegal to drive without a seat
belt (you can be given a ticket for that offense even in the absense
of some other offense, like speeding).   However, if you are injured
in an accident due to not wearing a seat belt, the insurance company
cannot refuse to pay the medical bills just because you contributed
to your injuries.

In other words, the system recognizes and deals with the fact that not
everyone will comply with the seat-belt requirement, yet that
requirement is still mandatory.

I believe that the protocol standard should REQUIRE CAs to verify
possession of the private key, even given the existence of CAs who,
for a reasonable fee, will ignore the standard.

Date: Wed, 19 Feb 1997 09:38:26 -0800
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Memphis PKIX Meeting

The PKIX meeting has been scheduled as follows:

	Monday, April 7 at 0930 (opposite ngtrans, disman, mobileip)
	Tuesday, April 8 at 0900 (opposite rmonmib, ion)

The main agenda topics, so far, are review of progress on the PKIX Part 1,
Part 2, Part 3, and Part 4 drafts.  Please advise any other topics you
believe should be included on the agenda.

Warwick
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date: Wed, 19 Feb 1997 13:30:59 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: [email-masked]
Subject: Private key possession

Topic: Private key possession.

At the last PKIX meeting we had  some discussion to say that each CA 
SHALL verify the possession of the private key by the user before 
issuing a certificate containing the corresponding public key.

I would like to show that, while this is desirable, it does not 
solve all problems, in particular the problem of steeling a signature 
from some one else.

Let us take the following example:

Alice wishes to apply for a patent today and for doing so signs the 
text of the patent using its private key, attach to it its certificate 
and send the two pieces to a patent office. When receiving the two 
pieces, the patent office would place a counter-signature from a 
Trusted Time Stamping Authority on the whole package so that one can 
make sure that the registration date is correct.

Since Bob intercepted the message from Alice, the patent office did not 
received Alice's message at this time. Bob promptly asks to a CA 
located in Barracuda (in the Republic of Banana) to issue a certificate 
containing the same public key as Alice but with his name in it. For a 
reasonable fee the CA omits to verify the possession of the private key 
by the user before issuing the certificate. Thereafter Bob sends the 
intercepted signed text of the patent and replaces Alice's certificate 
by his new own certificate. When receiving the two pieces, the patent 
office places a counter-signature from a Trusted Time Stamping 
Authority on the whole package so that one can make sure that the 
registration date is correct.

In such a scenario Bob would now the patent holder. If for some reason 
Alice re-sends her message it will be time-stamped after the message 
from Bob and she will not be recognized as the patent holder.

Of course there are several ways to counter that threat, one of them 
being to use a confidentiality service between the patent requester and 
the patent office, but relying on the existence of a confidentiality 
service is not a good practice, since the fraud could even occur by an 
employee of the patent office after the decryption of the message.

The general way to solve the problem is to include enough information 
within the signed text to identify unambiguously the signer. In the 
case of Alice and Bob, including Alice's name would work nicely but 
what happens for a name like Mike Walker ? How can we differentiate two 
people with the same name ? Using the address would be one response, 
using the company name would be another one. But this would mandate to 
look at the semantic of the message and thus this would prevent the 
automation of the verification procedure.

A more general solution is to reserve some place within the signed text 
to insert at least the identifier of the certificate. The best being to 
insert a certification path.

Let us now reconsider a variation of the same scenario :

Alice wishes to apply for a patent today and for doing so signs both 
the text of the patent and a certification path using its private key, 
and sends that single signed piece of information to a patent office. 
When receiving that piece, the patent office places a counter-signature 
from a Trusted Time Stamping Authority on it so that one can make sure 
that the registration date is correct.

Since the certification path is signed, Bob cannot do anything this 
time.

This rather long story is there to illustrate the fact that asking each 
CA to verify the possession of the private by the user implies a model 
where every CA over the world would be trusted to do this correctly.

I do not believe that such a model is practical. So we have to 
recognize that we have to live with cases where that trust cannot be 
placed and thus to adopt the appropriate measures to deal without it.

The conclusion is that each CA SHOULD verify the possession of the 
private by the user before issuing a certificate containing the 
corresponding public key.

As a consequence, this means that having a protocol to verify the 
possession of a private signature key shall not be mandatory and if we 
defined one, it should only be optionally supported.

Denis

Note: I have analyzed the problem for a signature key, but not for an 
encryption key. 

-- 

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

Date: Thu, 13 Feb 1997 14:41:03 +0000
From: [email-masked] (Christopher Welles)
To: [email-masked] ([email-masked]')
Cc: [email-masked] (Margaret Alix)
Subject: Bug in PKIX1-3 DSA OIDs?

In the course of testing the interoperability of some certificate generation software, we came across a peculiarity in PKIX1-3's definition of DSA algorithm object IDs.

draft-ietf-pkix-ipki-part1-03.txt (12/96) has the following object ID (OID) definitions for DSA algorithms:

	id-dsa-with-sha1 ID ::= {
                     iso(1) member-body(2)  us(840) x9-57(10040) secsig(2) 
                     x9algorithm(4) 3}  -- DSA signature algorithm
and
	id-dsa ID ::= {
                     iso(1) member-body(2)  us(840) x9-57(10040) secsig(2) 
                     x9algorithm(4) 1} -- DSA signature key

On the other hand, Appendix C of X9.57 (June,  1996) has the following definitions:

	x9cm ID ::= { iso(1) member-body(2)  us(840) x9-57(10040) }
	x9algorithm ::= {x9cm 4}

	id-dsa-with-sha1 ::= { x9algorithm 3}
	id-dsa  ::= { x9algorithm 1} 

It seems odd that PKIX1-3 would give different values for the same OID names from X9.57.  Is the interpolation of the "secsig (2)" node in PKIX1-3 a bug, or is there a method to this madness?

   - Chris Welles

Date: Wed, 12 Feb 1997 18:07:27 -0700
From: [email-masked] (KESTERSON.H)
Subject: new address for OSIdirectory server
To: [email-masked], [email-masked]
Content-Description: cc:Mail note part

the services previously accessed on NC-17 have been split across two systems.
unfortunately, i do not get to stay on the system with the neat name. the x.500
documents are now at a system with a descriptive, but somewhat mundane, name of
ftp.bull.com

   ftp://ftp.bull.com/pub/OSIdirectory

   hoyt

Date: Thu, 6 Feb 1997 13:32:28 -0500
To: [email-masked]
From: Robert Hettinga <[email-masked]>
Subject: My apologies...

I'm very sorry.

I just committed a major breach of nettiquette.

I just accidentally sent out the last FC97 Revised Program to this
monsterous cc list, instead of using the bcc: field.

Again, please my most sincere apologies.

Cheers,
Bob Hettinga

-----------------
Robert Hettinga ([email-masked]), Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"Never attribute to conspiracy what can be
explained by stupidity." -- Jerry Pournelle
The e$ Home Page: http://www.shipwright.com/rah/
FC97: Anguilla, anyone? http://www.ai/fc97/

Date: Thu, 6 Feb 1997 13:12:35 -0500
To: FC97 Distribution <[email-masked]>
From: Robert Hettinga <[email-masked]>
Subject: revised FC97 program
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], "stewart alsop" <[email-masked]>, [email-masked] (Steve Roberts), [email-masked] (Adam C. Engst), "Nicholas Petreley" <[email-masked]>, [email-masked], [email-masked] (Charles Wiltgen), Tony Rich <[email-masked]>, [email-masked] (Peggy Enes), [email-masked] (Jonathan Budil), [email-masked], Gibo <[email-masked]>, "bob kayne" <[email-masked]>, [email-masked], [email-masked], [email-masked] (John Burt), [email-masked], [email-masked] (Nevin Summers), Vincent Cate <[email-masked]>, "Mark A. McCarren" <[email-masked]>, Mark Tenney <[email-masked]>, "Stephen Humphrey" <[email-masked]>, "Paul M. Jones" <[email-masked]>, [email-masked] (Kathy Kahre), [email-masked], Robert Seidman <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], "Richard Lonergan, VISA International" <[email-masked]>, "John Matonis, Verisign" <[email-masked]>, "Colin Crook, Citicorp" <[email-masked]>, "David G.W. Birch, Hyperion, Inc." <[email-masked]>, "Frank Trotter, Mark Twain Bank" <[email-masked]>, "Art Hutchinson, Northeast Consulting Resources" <[email-masked]>, "John Curran, BBN Planet" <[email-masked]>, "Jeff Sutherland, Individual, Inc." <[email-masked]>, "Kathryn Szot, Bell Atlantic" <[email-masked]>, "Ken	Rodrigues, Open Software Foundation" <[email-masked]>, "Keiji Kono, Bank of Japan" <[email-masked]>, "Ed Kozel, Cisco" <[email-masked]>, "Lee Stein, First Virtual" <[email-masked]>, "Marty Stein, Bank of America" <[email-masked]>, <[email-masked]>, "Philip Zimmermann, PGP, Inc." <[email-masked]>, "Daya Puls,  Digital"<[email-masked]>, "Steven Willis, Bay Networks" <[email-masked]>, "Tom Wills, CommerceNet" <[email-masked]>, " Andy Klein, Spring Street Brewing" <[email-masked]>, "Donald Eastlake, Cybercash"  <[email-masked]>, "Dan Eldridge, Digicash" <[email-masked]>, "David Saul, State Street Bank" <[email-masked]>, "Frank Jaffe, FSTC Electronic Check Project" <[email-masked]>, "Jeff Bussgang, Open Market" <[email-masked]>, "Jim Philips, Security First Network Bank" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked] (Business D'Affaire)

--- begin forwarded text

Sender: [email-masked]
Reply-To: [email-masked]
Precedence: Bulk
Date: Thu, 6 Feb 1997 18:33:11 +0100
From: [email-masked]
To: Multiple recipients of <[email-masked]>
Subject: revised FC97 program

		      Financial Cryptography '97
		  February 24-28 1997, Anguilla, BWI
			 PRELIMINARY PROGRAM
		      (Revised 6 February 1997)

General Information:

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

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

Program Committee:

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

Preliminary Conference Program for FC97:

Monday 24 February 1997

 800 --  820
    Breakfast

 820 --  830
    Welcome

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

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

 940 -- 1015
    Anonymous Networking and Virtual Intranets: Tools for Anonymous
        Corporations
    Jim McCoy (Electric Communities, Cupertino, CA, USA)

1015 -- 1045
    Coffee Break

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

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

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

1230 -- 1330
    Lunch

1800 -- 1930
    Cocktail Reception (at Mariners Hotel)

Tuesday 25 February 1997

 800 --  830
    Breakfast

 830 --  930
    Invited Speaker
    Evaluating the security of electronic money;
        the view of a European central bank
    Simon L. Lelieveldt (De Nederlandsche Bank, Amsterdam, Netherlands)

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

1005 -- 1045
    Coffee Break

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

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

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

1230 -- 1330
    Lunch

Wednesday 26 February 1997

 800 --  830
    Breakfast

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

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

1005 -- 1045
    Coffee Break

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

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

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

1230 -- 1330
    Lunch

Thursday 27 February 1997

 800 --  830
    Breakfast

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

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

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

1015 -- 1045
    Coffee Break

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

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

1230 -- 1330
    Lunch

1930 -- 2015
    Invited Speaker
    Money Laundering: Yesterday, Today and Tomorrow
    Peter Wayner (Baltimore, MD, USA)

2015 -- 2200
    Rump Session

Friday 28 February 1997

 800 --  830
    Breakfast

 830 --  905
    The Strategic Role of Government in Electronic Commerce
    Paul Lampru (Verifone, Atlanta, GA, USA)

 905 --  940
    Using Markets to Achieve Efficient Task Distribution
    Ian Grigg, Christopher C. Petro (Systemics, Amsterdam, Netherlands)

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

1015 -- 1045
    Coffee Break

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

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

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

1230 -- 1330
    Lunch

Updates of the conference schedule will be available at the URL
http://www.cwi.nl/conferences/FC97/.

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

Workshop:

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

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

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

Venue:

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

Air Transportation and Hotels:

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

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

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

General Chairs:

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

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

Conference, Exhibits, and Sponsorship Manager:

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

Workshop Leader:

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

Registration:

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

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

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

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

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

It is sponsored by:

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

--- end forwarded text

-----------------
Robert Hettinga ([email-masked]), Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"Never attribute to conspiracy what can be
explained by stupidity." -- Jerry Pournelle
The e$ Home Page: http://www.shipwright.com/rah/
FC97: Anguilla, anyone? http://www.ai/fc97/

Date: Wed, 05 Feb 1997 13:23:02 -0800
To: [email-masked], [email-masked]
From: Peter Williams <[email-masked]>
Subject: Re: PKCS#7 in PKIX-3

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

Ok, I amend my basic proposal - Im tired of debating 
the irrelvant PKCS7-nature issue here; the PKCS7 forums
are a better place.

The precise nature of PKCS7, or some alternative,
is not relevant, yet (though few of the passing comments
are objectively true; bias and key recovery agenda are strange 
subjective beasts)

The whole point here is to separate protection from information.
There is emerging also the need to ensure group concensus on 
the provision of optional or even mandatory presence of key recovey
capability during PKIX key certification activities.

So,

I move we re-consider PKIX-3 design to ensure the necessary 
object protection is provided by relying upon the services
of the  mime multipart security types, and that any certification system
specific protection requirements are abstracted out of the current spec
and put into either a specification for a new "PKIX" security multiparts
protocol or a PKIX-specified profile suitably combining existing available
multipart services (multipart/signed, multipart/enveloped, etc)

Once this separation of object and protection has occured (like
for DOD's MSP and MMP equivalent problem, or Netscape
use of SSL to protect their CSR messages, or MS demo of PKCS7 to
protect PKCS#10 during initial subscriber enrollment), we can argue
the nature of the std multipart protocol from an identified
requirements standpoint.  

Nortel and other members of the Open Group (see APKI I-D) has
indeed identified a specific claim of a requirement - to ensure
mandatory and uniquitous presence of key recovery registation
capabilities during public key certification activities, which
neither 1424 nor MOSS were designed to guarantee. SO I
can see perhaps MOSS, S/.MIME, PGP - as multpart providers-
could well need to be tweaked in nesxt versions to satisfy PKIX-3 needs,
if they are to be used in that context by certification systems.
  
But lets identify and agree the needs first, and only then choose
the technology. Putting mime multiparts into the architecture
forces this important issue, by ensuring functional separation. It
also makes practical system integration/building from
std components even easier than just mandating PKCS7, say. The
entire point of my argument is to obtain separation, not merely
swap one specified technique for another. Reuse of
what is deployed or available is obviously a major benefit,
also, when weighing up the psosible approaches.

Finally, if it is truely the groups intention to satisfy the
PKIX APKI I-Ds requirements to mandate key recovery capability
on any and all key certification implementations
conforming to PKIX, for all deployments across the
Internet, then we can make a positive affimration of this design
requirement and analyse adequacy of either a single method (e.g. the
Entrust approach already built into PKIX-3), or a framework for
enabling multiple providers and technology approaches to perform
mandatory key recovery/escrow functions.

I dont want this mandatory key recovery thing pushed in by default;
its too sensitive a political issue. A nice sideeffect of
my argument, is that during the separation process, the
need for this as a mandatory requirements is questioned,
and can be agreed upon explicitely. If its mandatory, then
we can ensure the multipart protection environment really
enforces the escrow requirement.

Given the feedback to my iniative (which fell out of reading
the minutes of montreal and san jose IETF WG sessions), hopefully
I've updated and moved the issue forward. A few issues have fallen
out additionally upon reflection and comment (particularly the
escrow topic), and we might really try to reuse the multiparts stuff
as a middle-ground approach.  It certainly hurts noone, and gets the job
done nicely without lots of room for future flexiblity. That PKCS7
can be one multiparts provider brings us round to the original
suggestion and motive, but now the topic is more refined and flexible, 
embracing more players and technology approaches.

At 09:47 PM 2/4/97, Peter Gutmann wrote:
>Death Rays from Mars made Housley, Russ <[email-masked]> write:
> 
>>I think that we are near concensus on this point.  A single encapsulation
>>mechanism would be ideal.  PKIX Part 3 contains one suggestion, and PKCS #7
>>contains another.  Carlise provided an analysis for the PKIX Part 3
approach.
>>PKCS #7 has a market share that should not be ignored, and the specification
>>is open for reivew and update.
> 
>Just to further muddy the water, I've been using a format which is (IMHO) an
>improvement on PKCS #7 (it fixes a few problems in the PKCS format and is
>easier to use).  In case anyone's interested, I've included the ASN.1
>specification for the encapsulation below.
> 
>Peter.
> 
>-/ The basic content type.  PKCS #7 defines content as a sequence of { OID,
>   ANY DEFINED BY } and then nests one of a number of different grand unified
>   data types (signed, enveloped, signedAndEnveloped, etc) inside this.  This
>   doesn't allow for useful extensions such as compressed data or (currently)
>   signed then encrypted data, and has the nasty problem of a combinatorial
>   explosion of data types (which is also endemic among other RSADSI products
>   which use grand unified types) such as SignedAndEncryptedButNotCompressed,
>   SignedAndEncryptedAndCompressed, SignedAndEncrypted, EncryptedAndSigned,
>   etc etc.  A neater solution is to provide at the start of the content a
>   SEQUENCE OF ContentInfo records which define the transformations to be
>   applied to the content.  The contentInfo field encodes in one step a
>   transformation which would normally be encoded using nested ASN.1 objects,
>   so that for example the transformation:
> 
>    Sign( Compress( data ))
> 
>   would be encoded as:
> 
>    Sign, Compress( data )
> 
>   The reason for trying to reduce the level of nesting as much as possible
>   is that nested, indefinite-length ASN.1 data types are messy to encode and
>   lead to unnecessary message expansion.  This form of encapsulation is
>   known as "logical wrapping", in which a single physical level of wrapping
>   is used to provide the equivalent of multiple logical levels of wrapping.
> 
>   The sequence of ContentInfo fields encodes the progression of levels in
>   which the data is encased.  For example a contentInfo field of { Signed,
>   Compressed } would specify that the content should be signature checked
>   and then decompressed to recover the original data (ie the compressed data
>   has been signed).  In contrast a contentInfo field of { Compressed, Signed
>   } would specify that the content should be decompressed and then signature
>   checked (ie the decompressed data has been signed).
> 
>   This system can be used to encode arbitrary transformations on the
>   content, with arbitrary logical nesting and an arbitrary processing order.
> 
>   One disadvantage of the one-size-fits-all basic content type is that two
>   fields which are specific to two of the content types must be added.  The
>   signatures field is used for the Signed data type to contain the
>   signatures on the data (which may be empty if the signatures are stored
>   separately), and the padding field is used for the Encrypted data type to
>   contain optional message padding /-
> 
>Content ::= SEQUENCE {
>    contentInfo     SEQUENCE OF ContentInfo,
>                                    -- Transformation to apply to the content
>    content         OCTET STRING,   -- Data payload
>    signatures  [0] SET OF Signature OPTIONAL,  -- Signature(s) on the data
>    padding     [1] OCTET STRING OPTIONAL       -- Data padding
>    }
> 
>ContentInfo ::= CHOICE {
>    nestedData  [0] IMPLICIT NestedDataInfo,
>    encryptedData
>                [1] IMPLICIT EncryptedDataInfo,
>    signedData  [2] IMPLICIT SignedDataInfo,
>    compressedData
>                [3] IMPLICIT CompressedDataInfo,
>    ...
>    }
> 
>-/ Nested data.  This specifies that the data payload contains nested content
>   which should be further processed.  This is usually used after the
>   encryptedData type to specify that the decrypted data should be further
>   processed.  The use of a BOOLEAN is somewhat unnecessary since the mere
>   presence of the nestedData field is enough to convey the necessary
>   information, however providing the field and setting the value to FALSE
>   can also convey the information "I want to bloat up the header
>   unnecessarily" /-
> 
>NestedDataInfo ::= BOOLEAN
> 
>-/ Encrypted data.  The encryptionKeyInfo contains the session key and bulk
>   data encryption algorithm details, encrypted with zero or more public or
>   conventional key encryption keys.  If the set is empty, the session key
>   must be supplied by some other means.  If the set is nonempty, the session
>   key may be reconstructed by decrypting one of the EncryptionKeyInfo
>   records with the appropriate private key or conventional KEK.  Public and
>   conventional KEK's may be mixed, so that a single message could be
>   decrypted with one or more conventional and/or private keys.
> 
>   The IV is always present as a fixed-length string to obscure the details
>   of the algorithm and mode being used.  If necessary it is extended to more
>   than CRYPT_MAX_IVSIZE bytes by padding to the right with 0 bits /-
> 
>EncryptedDataInfo ::= SEQUENCE {
>    encryptionKeyInfo
>                    SET OF EncryptionKeyInfo,
>                                    -- Encrypted seesion key, may be empty
set
>    keyCookie   [0] IMPLICIT KeyCookie OPTIONAL,            -- Key cookie
>    iv              OCTET STRING (SIZE(CRYPT_MAX_IVSIZE))   -- IV
>    }
> 
>-/ Signed data.  The digestAlgorithms field contains information on which
>   types of message digest to compute for the data in order to allow the
>   signature check to be performed once the end of the data has been reached.
>   This is stored before the data itself to allow for one-pass processing.
>   The signatureCookie field is used to tie the signed data to the signature
>   or signatures associated with it if they are stored separately /-
> 
>SignedDataInfo ::= SEQUENCE {
>    digestAlgorithms
>                    DigestAlgorithmIdentifiers,
>                                    -- Information on digests for sig.check
>    signatureCookie
>                [0] IMPLICIT SignatureCookie OPTIONAL   -- Signature cookie
>    }
> 
>-/ Compressed data.  This provides information on the compression algorithm
>   used and any necessary parameters.  Unfortunately the only ISO-approved
>   algorithms are peculiar, usually patented or otherwise restricted ones
>   (check if Zip has an OID) /-
> 
>CompressedDataInfo ::= SEQUENCE {
>    compressionAlgorithm
>                    CompressionAlgorithmIdentifier  -- Compression algorithm
>    }
>
>
>
-----=_=_ 1113268275-6741220-12276944 _=_=---
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

-----=_=_ 1113268275-6741220-12276944 _=_=-----

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'ietf-pkix%tandem.com'" <[email-masked]>
Subject: RE: PKCS#7 in PKIX-3
Date: Mon, 3 Feb 1997 13:08:33 -0500
Encoding: 108 TEXT

Hi,

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Friday, January 31, 1997 2:15 PM
>To: 	Carlisle Adams; 'housley%spyrus.com'
>Cc: 	'ietf-pkix%tandem.com'
>Subject: 	RE: PKCS#7 in PKIX-3
>
>Carlise:
"Carlisle".

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

No one has accused me, anywhere, at any time, of always saying "no, no,
and no" to anything without considered thought and reasoning, so I can
only conclude that either you're not reading my postings or you're not
understanding them.

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

Every person I know in any way connected with PKIX is absolutely agreed
on this point, so your implication here shows again that you may not
have been following this discussion in sufficient detail...
>
>
>
>From my mailbox, and having consulted the primary players, I think 
>Carlise you are the only party not in consort with the proposal. 

Sounds like your mailbox has a selective memory because my mailbox (and
the PKIX archive) suggest otherwise, but let's move on:

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

I have no problem whatsoever with saying that when PKCS#7 is able to
accommodate the requirements of the PKIX-3 environment (i.e., when it
has evolved in the ways in which it needs to evolve), then it will be
the preferred (perhaps the *mandated*) protection mechanism.  In its
current form it cannot accommodate all the requirements of the PKIX-3
environment, but it can accommodate some, so I have no problem also
stating in the document that PKCS#7 may be used now wherever it is
appropriate.  I think that Stephen Farrell will agree with such wording
(Stephen?).

Note that this requires no changes at all to the current PKIX-3 protocol
(i.e., PKIX-3 already supports all this, as I have been saying
repeatedly); it simply requires a bit more explanatory text to make the
intentions clearer.  Is this something we can all live with?

>So, 
>
>Just as the Oakley key agreement spec for IPSEC asserts that use of
>DNS security/certs is mandatory (despite the fact that DNS security is
>neither agreed, fully finished/documented, nor ratified within its
>respective WG and the IESG security area directorate) so then,
>with the appropriate language, we mandate an architectural
>realationship to a PKCS7-like messaging service, but not required
>that all implementations have to realise it.
>
>just as SKIP specifies 4 cert types, not all of which need
>to be implemented...
>
>just as IPSEC std allows a multitude of non-interoperable 
>security service and algoirithm profiles....
>
>just as SSL/TLS allows an RSA client to fail to work with a DH-only
>SSL server...

Interesting.  I guess I must be an "old-timer" at IETF now, because I
still remember the days when interoperability was of some value to
protocol designers and working groups...
>
>These std are real, and not pure. So PKIX-3 should be.

So PKIX-3 *is*.  If your point with the examples above is that other
protocols allow non-interoperable options, then it is abundantly clear
that PKIX-3 already has this.  What Stephen and I have tried to do is to
profile this activity (i.e., specify the mandatory subset of the myriad
options) so that a working, interoperable protocol can be achieved.  I'm
guessing that if the PKIX working group does not have a set of working,
interoperable protocols for certificate management then it hasn't really
achieved anything.

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

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: PKCS#7 in PKIX-3
Date: Mon, 3 Feb 1997 13:32:55 -0500
Encoding: 82 TEXT

Hi Warwick,

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Friday, January 31, 1997 7:57 PM
>To: 	[email-masked]
>Subject: 	Re: PKCS#7 in PKIX-3
>
>From observation of many prior standardization activities, I suggest that
>solutions built by incrementally advancing existing, accepted,
>well-understood solutions have been far more successful than attempts to
>define something totally new, even if the latter was technically superior.
>
>I believe this same feeling was supported by strong concensus in the San
>Jose PKIX meeting.  If PKCS#7 satisfies requirements for many people, and
>some incremental extensions to PKCS#7 would satisfy requirements for
>everyone, then this is clearly far more likely to be accepted as a standard
>than a totally new invention such as the proposal in the December I-D.

I agree with this reasoning.  However, I would argue that PKCS#7 does
*not* "satisfy requirements for many people", within the PKIX-3
environment, because initialization (for example) cannot be done using
PKCS#7 in its current form.  It does not make sense to *mandate* a
protection mechanism which does not even allow you to get *started* in
this protocol.  What you need to do is to mandate something which *will*
work, and optionally allow anything else to be used wherever it can be
used.  This is what PKIX-3, as currently defined, already does.

Why do I think that PKCS#7 will not work for initialization?  Let me
dredge up an old posting:

2. (con):        
PKCS7 isn't well suited for cases in which one protects a message before
getting allocated a name/certificate.  This is important for
initialization 
and for key recovery, where the end-entity may not know anything about
itself
or its environment prior to the exchange with the CA/RA.  Thus, the
mandatory field IssuerAndSerialNumber in SignerInfo (which is used to
identify the signer's certificate) will require a new (and very liberal)
interpretation in this context, meaning that existing implementations
would
have to be modified to deal with this situation.

3. (con):
It is not at all clear how to use the PKCS7 spec. to do a MAC on a 
message.  "Digesting" seems to apply to hashing only, and MACing does
not appear to fit very well in the SignedData construct.  Given that
MACing is important for some operations (again, initialization and
key recovery come to mind, in which the messages may be protected by
a MAC based on secret out-of-band information), further specification
or profiling of PKCS7 would be necessary before it could be used 
within PKIX-3.

4. (con):
Using D-H to calculate the signature bits for a PKCS7 signedData is 
quite different from using RSA to sign (i.e., although it is quite
possible to force the results into the same syntax, the semantics of
the "encryptedDigest" field of the SignerInfo construct is entirely
changed, resulting in a significant modification to existing PKCS7
implementations).  Thus, for example, an existing S/MIME user agent
will be very unlikely to produce the desired result.

As I have said to Peter (just posted), I'm certainly willing to migrate
to PKCS#7 as "the" PKIX-3 protection mechanism once it has evolved to
the point where these issues are solved.  But since we don't know how
long a process that might be it seems pointless to hold up progression
of PKIX-3 indefinitely (especially since it already does what we want,
including allowing PKCS#7, as is, wherever this can be used!).

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

So would I.
>
--------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
---------------------------------------
>

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: PKCS#7 in PKIX-3
Sender: [email-masked]
Reply-To: [email-masked]
Date: Tue, 4 Feb 1997 21:47:20 (NZDT)

Death Rays from Mars made Housley, Russ <[email-masked]> write:
 
>I think that we are near concensus on this point.  A single encapsulation
>mechanism would be ideal.  PKIX Part 3 contains one suggestion, and PKCS #7
>contains another.  Carlise provided an analysis for the PKIX Part 3 approach.
>PKCS #7 has a market share that should not be ignored, and the specification
>is open for reivew and update.
 
Just to further muddy the water, I've been using a format which is (IMHO) an
improvement on PKCS #7 (it fixes a few problems in the PKCS format and is
easier to use).  In case anyone's interested, I've included the ASN.1
specification for the encapsulation below.
 
Peter.
 
-/ The basic content type.  PKCS #7 defines content as a sequence of { OID,
   ANY DEFINED BY } and then nests one of a number of different grand unified
   data types (signed, enveloped, signedAndEnveloped, etc) inside this.  This
   doesn't allow for useful extensions such as compressed data or (currently)
   signed then encrypted data, and has the nasty problem of a combinatorial
   explosion of data types (which is also endemic among other RSADSI products
   which use grand unified types) such as SignedAndEncryptedButNotCompressed,
   SignedAndEncryptedAndCompressed, SignedAndEncrypted, EncryptedAndSigned,
   etc etc.  A neater solution is to provide at the start of the content a
   SEQUENCE OF ContentInfo records which define the transformations to be
   applied to the content.  The contentInfo field encodes in one step a
   transformation which would normally be encoded using nested ASN.1 objects,
   so that for example the transformation:
 
    Sign( Compress( data ))
 
   would be encoded as:
 
    Sign, Compress( data )
 
   The reason for trying to reduce the level of nesting as much as possible
   is that nested, indefinite-length ASN.1 data types are messy to encode and
   lead to unnecessary message expansion.  This form of encapsulation is
   known as "logical wrapping", in which a single physical level of wrapping
   is used to provide the equivalent of multiple logical levels of wrapping.
 
   The sequence of ContentInfo fields encodes the progression of levels in
   which the data is encased.  For example a contentInfo field of { Signed,
   Compressed } would specify that the content should be signature checked
   and then decompressed to recover the original data (ie the compressed data
   has been signed).  In contrast a contentInfo field of { Compressed, Signed
   } would specify that the content should be decompressed and then signature
   checked (ie the decompressed data has been signed).
 
   This system can be used to encode arbitrary transformations on the
   content, with arbitrary logical nesting and an arbitrary processing order.
 
   One disadvantage of the one-size-fits-all basic content type is that two
   fields which are specific to two of the content types must be added.  The
   signatures field is used for the Signed data type to contain the
   signatures on the data (which may be empty if the signatures are stored
   separately), and the padding field is used for the Encrypted data type to
   contain optional message padding /-
 
Content ::= SEQUENCE {
    contentInfo     SEQUENCE OF ContentInfo,
                                    -- Transformation to apply to the content
    content         OCTET STRING,   -- Data payload
    signatures  [0] SET OF Signature OPTIONAL,  -- Signature(s) on the data
    padding     [1] OCTET STRING OPTIONAL       -- Data padding
    }
 
ContentInfo ::= CHOICE {
    nestedData  [0] IMPLICIT NestedDataInfo,
    encryptedData
                [1] IMPLICIT EncryptedDataInfo,
    signedData  [2] IMPLICIT SignedDataInfo,
    compressedData
                [3] IMPLICIT CompressedDataInfo,
    ...
    }
 
-/ Nested data.  This specifies that the data payload contains nested content
   which should be further processed.  This is usually used after the
   encryptedData type to specify that the decrypted data should be further
   processed.  The use of a BOOLEAN is somewhat unnecessary since the mere
   presence of the nestedData field is enough to convey the necessary
   information, however providing the field and setting the value to FALSE
   can also convey the information "I want to bloat up the header
   unnecessarily" /-
 
NestedDataInfo ::= BOOLEAN
 
-/ Encrypted data.  The encryptionKeyInfo contains the session key and bulk
   data encryption algorithm details, encrypted with zero or more public or
   conventional key encryption keys.  If the set is empty, the session key
   must be supplied by some other means.  If the set is nonempty, the session
   key may be reconstructed by decrypting one of the EncryptionKeyInfo
   records with the appropriate private key or conventional KEK.  Public and
   conventional KEK's may be mixed, so that a single message could be
   decrypted with one or more conventional and/or private keys.
 
   The IV is always present as a fixed-length string to obscure the details
   of the algorithm and mode being used.  If necessary it is extended to more
   than CRYPT_MAX_IVSIZE bytes by padding to the right with 0 bits /-
 
EncryptedDataInfo ::= SEQUENCE {
    encryptionKeyInfo
                    SET OF EncryptionKeyInfo,
                                    -- Encrypted seesion key, may be empty set
    keyCookie   [0] IMPLICIT KeyCookie OPTIONAL,            -- Key cookie
    iv              OCTET STRING (SIZE(CRYPT_MAX_IVSIZE))   -- IV
    }
 
-/ Signed data.  The digestAlgorithms field contains information on which
   types of message digest to compute for the data in order to allow the
   signature check to be performed once the end of the data has been reached.
   This is stored before the data itself to allow for one-pass processing.
   The signatureCookie field is used to tie the signed data to the signature
   or signatures associated with it if they are stored separately /-
 
SignedDataInfo ::= SEQUENCE {
    digestAlgorithms
                    DigestAlgorithmIdentifiers,
                                    -- Information on digests for sig.check
    signatureCookie
                [0] IMPLICIT SignatureCookie OPTIONAL   -- Signature cookie
    }
 
-/ Compressed data.  This provides information on the compression algorithm
   used and any necessary parameters.  Unfortunately the only ISO-approved
   algorithms are peculiar, usually patented or otherwise restricted ones
   (check if Zip has an OID) /-
 
CompressedDataInfo ::= SEQUENCE {
    compressionAlgorithm
                    CompressionAlgorithmIdentifier  -- Compression algorithm
    }

Date: Mon, 3 Feb 1997 12:55:42 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKCS#7 in PKIX-3

> From: Warwick Ford <[email-masked]>
> 
> >From observation of many prior standardization activities, I suggest that
> solutions built by incrementally advancing existing, accepted,
> well-understood solutions have been far more successful than attempts to
> define something totally new, even if the latter was technically superior.
> 
> I believe this same feeling was supported by strong concensus in the San
> Jose PKIX meeting.  If PKCS#7 satisfies requirements for many people, and
> some incremental extensions to PKCS#7 would satisfy requirements for
> everyone, then this is clearly far more likely to be accepted as a standard
> than a totally new invention such as the proposal in the December I-D.
> 
> I would hate to see us use up scarce resources on a new protocol which lacks
> broad buy-in from day one.
> 
> I would appreciate hearing opinions from other members of the list.
> 
> Warwick
> 
> >I think that we are near concensus on this point.  A single 
> >encapsulation mechanism would be ideal.  PKIX Part 3 contains one 
> >suggestion, and PKCS #7 contains another.  Carlise provided an 
> >analysis for the PKIX Part 3 approach.  PKCS #7 has a market 
> >share that should not be ignored, and the specification is open 
> >for reivew and update.  Further, RSA has agreed to work with the 
> >IETF on the PKCS "standards" and give configuration control to 
> >the IETF where standards track RFCs result.
> >
> >So, how does the group want to proceed?
> >
> >Russ

I concur that:
  1) a single encapsulation mechanism would be ideal, and
  2) incremental improvement of an existing mechanism is better than
       "something totally new".

However, I don't see how PKCS #7 can be incrementally extended to
"satisfy requirements for everyone" except by being incrementally
extended until it includes a subset that looks remarkably like PKIX 3.

Therefore I think the group should proceed as follows:

  1) migrate PKIX 3 towards status as an IETF Technical Standard.
  2) accept PKCS-7 as an IETF draft, and migrate it towards status
       as an IETF Technical Standard.
  3) write an Applicability Statement (such as Tim's Minimum Interoperability
       Specification) that requires servers to support both PKIX 3 and PKCS 7
       message formats, and requires clients to support at least one of the
       two.
  4) if during the IETF standardization process PKCS-7 becomes incrementally
       extended to encompass the functionality of PKIX 3, then amend the
       Applicability Statement to require conformance with just the single
       improved message format.

    dpk

(who's former boss now works for the same company as Peter and Warwick)

Date: Mon, 03 Feb 1997 08:58:00 -0700
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: PKCS#7 in PKIX-3 -Reply

I concur, Warwick.

Michael

Date: Mon, 3 Feb 97 07:33:44 MST
From: scott%phx.sectel.mot.com@[160.12.2.1]@austx.tandem.com (Will Scott x7610)
To: [email-masked]

help
list

Date: Sat, 1 Feb 1997 08:34:28 -0800
From: sanders_jeff <[email-masked]>
To: [email-masked], [email-masked]
Subject: Monthly reminder

Welcome to the ietf-pkix mailing list!

If you ever want to remove yourself from this mailing list, 
send the following command in email to "[email-masked]"
(NOT [email-masked]):

    unsubscribe <your e-mail-id> ietf-pkix

Here's the general information for the list you've subscribed to, in
case you don't already have it:

Welcome to the ietf-pkix list. This list is intended to discuss
matters directly related to  develop Internet standards needed to
support an X.509-based public key infrastructure (PKI). The resulting
PKI is intended to provide a framework which will support a range of
trust/hierarchy environments and a range of usage environments.

If you have any questions about this interest group, you can contact 
Warwick Ford at [email-masked]  or Jean Pawluk at [email-masked].

If you have any questions about this list service in general, you
can contact [email-masked].

Date: Sat, 1 Feb 1997 08:29:19 -0800
From: sanders_jeff <[email-masked]>
Apparently-To: [email-masked]
Apparently-To: [email-masked]
Apparently-To: [email-masked]
Apparently-To: [email-masked]

Welcome to the ietf-pkix mailing list!

If you ever want to remove yourself from this mailing list, 
send the following command in email to "[email-masked]"
(NOT [email-masked]):

    unsubscribe <your e-mail-id> ietf-pkix

Here's the general information for the list you've subscribed to, in
case you don't already have it:

Welcome to the ietf-pkix list. This list is intended to discuss
matters directly related to  develop Internet standards needed to
support an X.509-based public key infrastructure (PKI). The resulting
PKI is intended to provide a framework which will support a range of
trust/hierarchy environments and a range of usage environments.

If you have any questions about this interest group, you can contact 
Warwick Ford at [email-masked]  or Jean Pawluk at [email-masked].

If you have any questions about this list service in general, you
can contact [email-masked].