Subject: unsubscribe
From: Ralph Schoenfelder <[email-masked]>
To: [email-masked]
Date: Fri, 31 Oct 1997 09:02:18 -0600

unsubscribe

Date: Thu, 30 Oct 1997 10:32:24 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Object Identifiers: Confusion now hath made his masterpiece
Status:

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 110

> From: [email-masked] (Peter Gutmann)
> To: [email-masked], [email-masked], [email-masked]

(I've trimmed the list to just ietf-pkix)

>  
> Below is a list of some of the problem OIDs or problem areas, if anyone has 
> any comments on these or can clear things up, please let me know.  Before 
> anyone asks, I didn't record the exact sources for all of this information, 
> but in general it came from sundry standards, drafts, RFC's, online 
> information, and moles and spies in standards bodies and companies :-).
>  
> 1. DSA and SHA combinations have multiple redundant definitions (X9.57, some 
>    old OIW OIDs, and a DMS OID).  Which one is the recommended one?

It depends on what standard you choose to follow.  Before there are
standards, there are many options for developers to choose from.  The
purpose of standards is to reduce developers' options.  When PKIX part 1
first becomes a Proposed Standard (perhaps by Dec 8?), it will specify
a consensus agreement on DSA/SHA-1 OIDs - the ones specified by ANSI X9.57.
DMS (MISSI) also follows PKIX wherever possible and uses the same OIDs for
id-dsa and id-dsa-with-sha1.  (As an aside, since there is no suitable OID 
for KEA other than the one on the MISSI Infosec arc, that KEA OID is the
one used by PKIX, and by extension, DMS).

If you rely on drafts, moles, and bleeding-edge implementations for
information, you should expect more confusion than if you rely on
approved standards with consensus agreement behind them.

> 4. There are a whole series of strange OIDs at (1 3 14) which don't make much 
>    sense and which are incompatible with or conflict with other OIDs (see the 
>    dumpasn1.c code for more information on these).  Any comments on these 
>    would be appreciated.
>    
> 5. (1 3 14 3 2 27) is assigned to both ripemd-160 and yet another dsaWithSHA1.
>    (This means there are no ripemd-160 OIDs which aren't also assigned to 
>    something else.  If noone knows what the situation is with these, I'll 
>    issue some RIPEMD-160 OIDs myself just to clear up the confusion).

As far as I know, there are only two sources of registered OIW
algorithm OIDs: the "stable agreements" and the "working agreements"
from December 1994 (listed in the attachment below).  What source
assigned {1 3 14 3 2 27} to ripemd-160, was that source authorized to
register it, and do you believe that source to be trustworthy?

> 6. X.509v3 cert extensions - what a mess!  There are often multiple 
>    generations of superseded and redundant OIDs for extensions, again see the 
>    dumpasn1 code comments.

There are no approved standards for X.509v3 cert extensions.  But when
X.509 1997 is ratified, there will be.  One may assume, at one's own risk,
that the standard will be similar to the latest draft from June 1997,
but until there is an approved standard, one must expect drafts to
change.  If you made the assumption that X.509 will be identical to
earlier drafts, you are taking more of a risk.

Although I disagree with your characterization of the process of revising
draft standards as "a mess", I do have one complaint with X.509:  it says
that a large list of superceded OIDs "are not used by this specification".
That statement is not helpful to developers, Peter Williams and I
agree:

  -----------------------------------------------------------------
  Date: Mon, 06 May 1996 10:01:27 -0700
  From: Peter Williams <[email-masked]>

  > -- The following OBJECT IDENTIFIERS are not used by this specification:
  > -- {id-ce 2}, {id-ce 4}, {id-ce 6}, {id-ce 7}, {id-ce 8}, {id-ce 10}, {id-ce
  > 11},
  > -- {id-ce 13}, {id-ce 25}, {id-ce 26}

  I assume this means implementations which use the OIDs and related
  notions will not be X.509 AM conformant.

  -----------------------------------------------------------------
  From: "warwick (w.s.) ford" <[email-masked]>
  Date:  Wed, 8 May 1996 13:38:00 -0400 

  Correct.  Those of us who have implemented DAM extensions are expected to 
  migrate to the AM extensions with time.  I think the migration can be 
  reasonably graceful, though.

  -----------------------------------------------------------------
  Date: Fri, 28 Feb 1997 12:15:15 -0500
  From: [email-masked] (David P. Kemp)

   "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 ...

  -----------------------------------------------------------------
  Date: Mon, 3 Mar 1997 09:26:14 -0500
  From: [email-masked] (David P. Kemp)

  {id-ce 3} and the other not-used extensions
  should either be a) defined, b) reserved (prohibited from being defined in
  some other IS/Recommendation), or c) deprecated in the next version of
  X.509.

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

I stand by that last suggestion: X.509 and PKIX should explicitly state
that those extension OIDs are either "reserved" or "deprecated".

"not used" is just too ambiguous for a formal standard.
----------
X-Sun-Data-Type: h-file
X-Sun-Data-Description: h-file
X-Sun-Data-Name: oid_oiw.h
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 44

/*  NIST Open Systems Environment (OSE) Implementor's Workshop (OIW)
 *
 *  http://www.oiw.org/agreements/stable/12s-9412.txt
 *  http://www.oiw.org/agreements/working/12w-9412.txt
 *
 *  Prefix: { iso(1) identified-organization(3) oiw(14) }
 */

	{ "1.3.14.3", "secsig" },
	{ "1.3.14.3.2", "algorithm" },
	{ "1.3.14.3.3", "auth-mechanism" },
	{ "1.3.14.3.4", "attribute" },
	{ "1.3.14.3.5", "doc-type" },
	{ "1.3.14.3.6", "module" },

	{ "1.3.14.3.2.2",  "md4WithRSA" },
	{ "1.3.14.3.2.3",  "md5WithRSA" },
	{ "1.3.14.3.2.4",  "md4WithRSAEncryption" },
	{ "1.3.14.3.2.6",  "desECB" },
	{ "1.3.14.3.2.7",  "desCBC" },
	{ "1.3.14.3.2.8",  "desOFB" },
	{ "1.3.14.3.2.9",  "desCFB" },
	{ "1.3.14.3.2.10", "desMAC" },
	{ "1.3.14.3.2.11", "rsaSignature" },
	{ "1.3.14.3.2.12", "dsa" },
	{ "1.3.14.3.2.13", "dsaWithSHA" },
	{ "1.3.14.3.2.14", "mdc2WithRSASignature" },
	{ "1.3.14.3.2.15", "shaWithRSASignature" },
	{ "1.3.14.3.2.16", "dhWithCommonModulus" },
	{ "1.3.14.3.2.17", "desEDE" },
	{ "1.3.14.3.2.18", "sha" },
	{ "1.3.14.3.2.19", "mdc-2" },
	{ "1.3.14.3.2.20", "dsaCommon" },
	{ "1.3.14.3.2.21", "dsaCommonWithSHA" },
	{ "1.3.14.3.2.22", "rsaKeyTransport" },
	{ "1.3.14.3.2.23", "keyed-hash-seal" },
	{ "1.3.14.3.2.24", "md2WithRSASignature" },
	{ "1.3.14.3.2.25", "md5WithRSASignature" },
	{ "1.3.14.3.2.26", "sha1" },
	{ "1.3.14.3.2.27", "dsaWithSHA1" },
	{ "1.3.14.3.2.28", "dsaCommonWithSHA1" },
	{ "1.3.14.3.2.29", "sha1WithRSASignature" },

	{ "1.3.14.3.6.1", "x9f1-certmgmt" },
----------
X-Sun-Data-Type: h-file
X-Sun-Data-Description: h-file
X-Sun-Data-Name: oid_x500.h
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 80

/* from ISO/IEC 9594-2 (ITU-T X.501) */

	{ "2.5.4", "attributeType" },
	{ "2.5.8", "algorithm" },
	{ "2.5.29", "certificateExtension" },	/* (from AM 4) */

/* Attribute types from ISO/IEC 9594-6 (ITU-T X.520) */

	{ "2.5.4.0", "objectClass" },
	{ "2.5.4.1", "aliasedObjectName" },
	{ "2.5.4.2", "knowledgeInformation" },
	{ "2.5.4.5", "serialNumber" },

	{ "2.5.4.12", "title" },
	{ "2.5.4.13", "description" },
	{ "2.5.4.14", "searchGuide" },
	{ "2.5.4.15", "businessCategory" },
	{ "2.5.4.16", "postalAddress" },
	{ "2.5.4.17", "postalCode" },
	{ "2.5.4.18", "postOfficeBox" },
	{ "2.5.4.19", "physicalDeliveryOfficeName" },
	{ "2.5.4.20", "telephoneNumber" },

/* from ISO/IEC 9594-8 (ITU-T X.509) */

  /* id-at  Attribute Types */
	{ "2.5.4.52", "supportedAlgorithms" },
	{ "2.5.4.53", "deltaRevocationList" },

  /* id-ce  Certificate Extensions */
	{ "2.5.29.9",  "subjectDirectoryAttributes" },
	{ "2.5.29.14", "subjectKeyIdentifier" },
	{ "2.5.29.15", "keyUsage" },
	{ "2.5.29.16", "privateKeyUsagePeriod" },
	{ "2.5.29.17", "subjectAltName" },
	{ "2.5.29.18", "issuerAltName" },
	{ "2.5.29.19", "basicConstraints" },
	{ "2.5.29.20", "cRLNumber" },
	{ "2.5.29.21", "reasonCode" },
	{ "2.5.29.23", "instructionCode" },
	{ "2.5.29.24", "invalidityDate" },
	{ "2.5.29.27", "deltaCRLIndicator" },
	{ "2.5.29.28", "issuingDistributionPoint" },
	{ "2.5.29.29", "certificateIssuer" },
	{ "2.5.29.30", "nameConstraints" },
	{ "2.5.29.31", "cRLDistributionPoints" },
	{ "2.5.29.32", "certificatePolicies" },
	{ "2.5.29.33", "policyMappings" },
	{ "2.5.29.34", "(deprecated) policyConstraints" },
	{ "2.5.29.35", "authorityKeyIdentifier" },
	{ "2.5.29.36", "policyConstraints" },
	{ "2.5.29.37", "extKeyUsage" },

/* Apparently from earlier drafts of X.509:
   these definitions taken from ANSI X9.55 draft December 8, 1995.
   The July 3, 1996 version of X9.55 is aligned with the above X.509 def'ns,
   except that it uses id-ce 34 (the deprecated policyConstraints) */

	{ "2.5.29.1",  "authorityKeyIdentifier (old)", },
	{ "2.5.29.2",  "keyAttributes (old)", },
	{ "2.5.29.3",  "certificatePolicies (old)", },
	{ "2.5.29.4",  "keyUsageRestriction (old)", },
	{ "2.5.29.5",  "policyMappings (old)", },

	{ "2.5.29.7",  "subjectAltName (old)", },
	{ "2.5.29.8",  "issuerAltName (old)", },

	{ "2.5.29.11", "nameConstraints (old)", },
	{ "2.5.29.12", "policyConstraints (old)", },
	{ "2.5.29.13", "basicConstraints (old)", },

	{ "2.5.29.22", "expirationDate (old)", },
	{ "2.5.29.25", "cRLDistributionPoints (old)", },
	{ "2.5.29.26", "issuingDistributionPoint (old)", },

/* Can't find any reference to these */

	{ "2.5.29.6",  "(???)", },
	{ "2.5.29.10",  "basicConstraints (old)", }, /* from Verisign web site */

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Object Identifiers: Confusion now hath made his masterpiece
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 30 Oct 1997 19:17:42 (NZDT)
Status:

I've been updating my ASN.1 dump/diagnostic program 
http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c) over the past few days and 
have started cross-referencing the various OIDs it knows about.  While doing 
this I've become a bit disturbed at the number of redundant, multiply defined, 
incorrectly used, and ambiguous OIDs which are floating around.  For example 
there are no less than a dozen OIDs for the various DSA and SHA combinations, 
including ones used incorrectly (JDK 1.1 uses SHA-1 but denotes its use with 
an SHA OID).
 
Below is a list of some of the problem OIDs or problem areas, if anyone has 
any comments on these or can clear things up, please let me know.  Before 
anyone asks, I didn't record the exact sources for all of this information, 
but in general it came from sundry standards, drafts, RFC's, online 
information, and moles and spies in standards bodies and companies :-).
 
1. DSA and SHA combinations have multiple redundant definitions (X9.57, some 
   old OIW OIDs, and a DMS OID).  Which one is the recommended one?
 
2. PKCS #1 OID (1 2 840 113549 1 1 6) is assigned to both 
   ripemd160WithRSAEncryption and rsaOAEPEncryptionSET.
                                                      
3. PKCS #9 OID (1 2 840 113549 1 9) is assigned to both symmetricCapabilities 
   and SMIMECapabilities.
   
4. There are a whole series of strange OIDs at (1 3 14) which don't make much 
   sense and which are incompatible with or conflict with other OIDs (see the 
   dumpasn1.c code for more information on these).  Any comments on these 
   would be appreciated.
   
5. (1 3 14 3 2 27) is assigned to both ripemd-160 and yet another dsaWithSHA1.
   (This means there are no ripemd-160 OIDs which aren't also assigned to 
   something else.  If noone knows what the situation is with these, I'll 
   issue some RIPEMD-160 OIDs myself just to clear up the confusion).
 
6. X.509v3 cert extensions - what a mess!  There are often multiple 
   generations of superseded and redundant OIDs for extensions, again see the 
   dumpasn1 code comments.
 
7. Most of the SET cert extensions are defined as both (2 23 42 7 x) and 
   (2 54 1775 x+2).
 
There are a couple of European e-commerce and certification initiatives which 
are planning to issue their own OIDs for everything as well (yippee!), if 
anyone knows more about these please let me know.  So far all I've seen are 
general comments to the effect that the OIDs for operations of type X will be 
allocated on branch Y, but no details on which OIDs are actually assigned (the 
BSI is (not surprisingly) quite keen on RIPEMD so maybe we'll see a series of 
proper OIDs issued for that).
             
Peter.

From: Dean Povey <[email-masked]>
To: [email-masked]
Subject: Path Length constraints in in path validation
Date: Thu, 30 Oct 97 13:13:31 +1000
Status:

Just a small point, but I notice that the Cert and CRL profile contains no 
mention of processing of path length constraints in the path validation 
section (well except implicitly under the "process other extensions").

This probably should be rectified.

-- 
+----------------------------------------+-------------------------------+
| Dean Povey,                            |  Email: [email-masked]     |
| Research Scientist, Security Unit,     |  Phone: +61 7 3864 2799       | 
| CRC for Distributed Systems Technology |  Fax:   +61 7 3864 1282       |
+----------------------------------------+-------------------------------+

Date: Wed, 29 Oct 1997 18:50:34 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Meeting Slots in D.C. IETF
Status:

Folks,

	We have been assigned two meeting slots at the next IETF in
Washington, D.C.:
        Monday, December 8 at 0930-1130
                (opposite pktway, calsch, pkix, tcpsat, mboned)
        Wednesday, December 10 at 1300-1500
                (opposite ospf, ftpext, ldapext, avt)

Please contact Warwick and me with agenda requests so that we can organize
presentations for these two days.

Thanks,

Steve

Date: Wed, 29 Oct 1997 14:28:03 -0500
To: Stephen Kent <[email-masked]>
From: "Jeffrey I. Schiller" <[email-masked]>
Subject: Re: Last Calls
Cc: [email-masked]
Status:

Great thanks!   -Jeff

At 01:54 PM 10/29/97 -0500, Stephen Kent wrote:
>Jeff,
>
>	I think it is thoroughly appropriate to qualify the document titles
>in this fashion, and we will make sure that future PKIX documents that are
>X.509-sepcific are titled appropriately.  Please advise the IESG that we
>will update the titles for these documents if they are approved for
>publication as RFCs.
>
>Steve
>
>
>

Date: Wed, 29 Oct 1997 13:54:25 -0500
To: "Jeffrey I. Schiller" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Last Calls
Cc: [email-masked]
Status:

Jeff,

	I think it is thoroughly appropriate to qualify the document titles
in this fashion, and we will make sure that future PKIX documents that are
X.509-sepcific are titled appropriately.  Please advise the IESG that we
will update the titles for these documents if they are approved for
publication as RFCs.

Steve

Date: Wed, 29 Oct 1997 13:06:11 -0500
To: Warwick Ford <[email-masked]>, [email-masked], [email-masked]
From: "Jeffrey I. Schiller" <[email-masked]>
Subject: Re: Last Calls
Status:

I have received some feedback directly regarding the titles of these 
documents. Specifically I have been asked if we can add the token "X.509" at 
appropriate places in the titles so as to no imply that the IETF has decided 
that X.509 will be *the* key management infrastructure for the Internet. 
I.e. The first document should be named:

"The Internet X.509 Public Key Infrastructure Operational Protocols..."

and the second:

"The Internet X.509 Public Key Infrastructure Representation of ..."

Can we do this please?

                              -Jeff

At 06:33 PM 10/23/97 -0700, Warwick Ford wrote:
>Please consider the following I-D as being issued for 2-week WG last call
>for progression to a Proposed Draft Standard:
>
>>	Title		: Internet Public Key Infrastructure 
>>                          Operational Protocols:  FTP and HTTP
>>	Author(s)	: R. Housley
>>	Filename	: draft-ietf-pkix-opp-ftp-http-01.txt
>>	Pages		: 5
>>	Date		: 22-Oct-97
>
>Please consider the following I-D as being issued for 2-week WG last call
>prior to publication as an Informational RFC:
>
>>	Title		: Internet Public Key Infrastructure   
>>                          Representation of Key Exchange Algorithm 
>>                          (KEA) Keys in Internet Public Key 
>>                          Infrastructure Certificates
>>	Author(s)	: R. Housley, W. Polk
>>	Filename	: draft-ietf-pkix-ipki-kea-01.txt
>>	Pages		: 6
>>	Date		: 15-Oct-97
>
>Warwick
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>---------------------------------------------------------------------
> 
>

Date: Wed, 29 Oct 1997 09:01:58 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: comments on part1-06
Status:

> From: "David Solo" <[email-masked]>
> 
> Comments on PKIX Part 1-06
> Below are a number of comments, edits, and questions on the latest
> draft (some may have been raised in the past but I've lost part of my
> archive). 

Agree with items 1-7.

> 8) Section 4.1.1.3 and 5.1.1.3 - rather than talking about encrypting
> hashes, I would suggest stating that the signature value is computed in
> accordance with the algorithm specified in section 7.2.

Agree.  Nick Pope suggested that the wording in X.509 section 9 clarify
that the word "encrypted" is intended to include non-encryption signature
algorithms.  I believe it would be clearer just to not use the word
encrypted at all, and sent some suggested replacement text to Nick.
This has probably been discussed (beaten to death :-) before, so it's
probably not worth rocking the X.509 boat over.  But PKIX should certainly
use more correct terminology, regardless of the text used in X.509.

Agree with items 9-13.

> 14) Section 4.2.1.5 - Do we want to suggest carrying only a single policy
> ID?  What does it mean if there are multiple policy IDs to me as a
> relying party, especially if one is on my list and one isn't.
> 15) Section 4.2.1.5 - I still think the CPSuri should include an
> (optional) date or hash or version to handle updates to the CPS.  It
> should be clear what CPS was the basis for the issuance of the cert.

Good points!  Agree.

Agree with items 16-20.

> 21) Section 4.2.2.1 - does it make sense to move the last part of this
> section on http fetches to some document in part 2?

Yes!  This text on how to encode certificate extensions as PKCS 7 attributes,
forming filenames by hashing cert fields, using HTTP GET retrievals, etc
is all completely out of place in Part 1.  Move the bulk of section
4.2.2.1 beginning with

  "The authorityInfoAccess extension may be included in a PKCS 7
  encapsulation ..."

to some other document.

> All for now,
> Dave

Good suggestions all.  Hope you will be able to get them into the next
draft.

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Wildcards in rfc822Name
Date: Tue, 28 Oct 1997 15:31:12 -0800
Status:

Offline there has been some discussion in the S/MIME community about
wildcard use in certificates for email.  Specifically, in looking at the
subjectAltName extension, we have come to the consensus that there is a
useful case that has not been accommodated in the current PKIX Part 1
draft.  In the event that a certificate represents a domain that can
sign email on behalf of any of its users, or decrypt mail on behalf of
any of its users, there is no evident way to relay this using current
subjectAltName constructs.  Specifically:

1. The rfc822Name allows wildcards on the right side of the atsign, but
not on the left side.
2. The dNSName seems to refer to particular computers or domains, NOT to
end users, and the semantics would be corrupted in an email environment.

Now, for rfc822Name, If the left side of the atsign could be the single
character "*", then this would work.  For instance:

*@*.deming.com -- "This certificate represents all users whose email
address is at any domain that ends with .deming.com"
[email-masked] -- "This certificate represents all users whose email
address is at the exact domain deming.com"
*@mail*.deming.com -- you get the point

This would be the required change to PKIX Part 1.  Certainly feel free
to chime in with any changes:

>From section 4.2.1.7:

"Where the subjectAltName extension contains an rfc822Name, this name
may also include the wildcard character. Use of the wildcard is limited
to the host name."

would be changed to:

"Where the subjectAltName extension contains an rfc822Name, this name
may also include the wildcard character. The wildcard can be used both
in the host name and as a substitute for the entire local part of the
email address (the left-hand side of the atsign)."

Any comments?

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

From: "David Solo" <[email-masked]>
To: "IETF PKIX working group" <[email-masked]>
Subject: comments on part1-06
Date: Tue, 28 Oct 1997 16:50:14 -0500
Status:

Comments on PKIX Part 1-06
Below are a number of comments, edits, and questions on the latest
draft (some may have been raised in the past but I've lost part of my
archive). 
1) general - need to clean up conformance language to match RFC on
MUST/SHOULD/... I've tried to catch these, but there are lots of
ambiguous statements.
2) Section 1, par 2 - Suggest adding "Internet PKI refers to the
general use of X.509 certificate technology within internet
applications, not to the creation of a concrete infrastructure."
3) Section 3.3, par 2 - an entry needs to remain on the CRL past
expiration (at least one CRL cycle, perhaps longer).  Change last
sentence to ...may be removed at some period after expiration."
4) Section 3.3, par 7 - online methods may be an alternative or
supplement to CRLs.  Even with online status checks to improve
timeliness and/or client efficiency, a CRL continues to serve as an
archival record of changes in cert status.
5) Section 3.5f - remove "abnormal".
6) Section 4.1.1 "are" is repeated.
7) Section 4.1.1.2 (and 4.1.2.3, 5.1.1.2, 5.1.2.2) algorithm ID in
signatureAlgorithm and signature MUST be the same.
8) Section 4.1.1.3 and 5.1.1.3 - rather than talking about encrypting
hashes, I would suggest stating that the signature value is computed in
accordance with the algorithm specified in section 7.2. 
9) Section 4.1.1.3, par 2 - by generating the signature, the CA
certifies that it has performed the actions described in its CPS (rather
than stating that it certifies the validity of info in the cert).
10) Section 4.1.2.6 and 4.2.1.7 - may want to include a statement that
where the same name form occurs in both the subject and altName fields,
the values represent a list of identities (i.e., they may be
different).  This could occur with email addresses, although I'm not
sure we need to state this.
11) Section 4.2, par 3,4,5 "CAs MUST support the basic Constraints...."
"Applications MUST support key usage, ...." "Applications SHOULD support
key identifiers...."  Support for CAs means enabling the inclusion of
the extension within certificates.  Support for applications means
recognizing and processing the extension.
12) Section 4.2.1.1 - it occurs to me that since the cert/serial option
for AuthorityKeyID names a cert, and key ID names a key; the cert/serial
option may be more useful in some certification tree environments
(multiple issuer certs for a single CA).  Do we want to soften the
statement on use of keyID vs.  cert/serial? 
13) Section 4.2.1.3 (and 6) - do we want to make it clearer that the
keyCertSign and crlSign bits MUST be set for CAs and this MUST be
checked during cert path validation if this extension is present.
14) Section 4.2.1.5 - Do we want to suggest carrying only a single policy
ID?  What does it mean if there are multiple policy IDs to me as a
relying party, especially if one is on my list and one isn't.
15) Section 4.2.1.5 - I still think the CPSuri should include an
(optional) date or hash or version to handle updates to the CPS.  It
should be clear what CPS was the basis for the issuance of the cert.
16) Section 4.2.1.7, par 3 - delete "a subnet or"
17) Section 4.2.1.9 "extension MUST be non-critical"
18) Section 4.2.1.10 - to clarify "...requires use of this extension
and it MUST be included in all certificates (CA and end entity)."  Note
that for an end entity, the value of the extension is an empty
sequence.
19) Section 4.2.1.12 - I assume this is a typo on the syntax and it
meant to be PolicyConstraintsSyntax ::= PolicyConstraints (more or
less, I don't have the 509 doc at hand).
20) Section 4.2.1.14 - This is a misuse of the critical extension (we
fought this battle long ago on key usage).  Either the extension is
mandatory or advisory.  The critical flag indicates whether you can
process the cert if you don't understand the extension, not if its
important.  If we want to support both mandatory and advisory extended
key usage, we need to either add a new extension or include an explicit
flag in the extension.
21) Section 4.2.2.1 - does it make sense to move the last part of this
section on http fetches to some document in part 2?
22) Section 5.1.1 - repeated "are".
23) Section 5.2.3 - are we allowing skipping a number?
24) Section 5.2.6 - shouldn't this be part of section 5.3.
25) Section 6, par 3 - I'd suggest we replace this with the language on
roots from section 1.2.2 of part 3.
26) Page 88 - do you want to include the names of the OIDs not used in
this specification (actually not really important, except that I was
trying to look one up and couldn't find the source).
27) I'll get you new author info for me soon.
All for now,
Dave

To: IETF-Announce:;;@tandem.com
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Internet Public Key Infrastructure Operational Protocols - LDAPv2 to Proposed Standard
Reply-to: [email-masked]
Date: Tue, 28 Oct 1997 07:34:13 -0500
Sender: [email-masked]
Status:

The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider Internet Public Key Infrastructure
Operational Protocols - LDAPv2 <draft-ietf-pkix-ipki2opp-04.txt> as a
Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by November 10, 1997.

Files can be obtained via 
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki2opp-04.txt

Date: Tue, 28 Oct 1997 20:47:46 +0800
To: [email-masked]
From: Incheon Paik <[email-masked]>
Subject: subscribe
Status:

subscribe

From: Ingmar Camphausen <[email-masked]>
Date: Mon, 27 Oct 97 15:32:22 +0100
To: [email-masked] (PKIX working group)
Subject: European shadow directory for IETF drafts
Reply-To: [email-masked]
Organization: GMD - German National Research Center for Information Technology
Priority: normal
Status:

[This is just a small editorial correction, but as most of the recent  
PKIX drafts are concerned, I thought it appropriate to send this to the  
list]

The introductory paragraphs of the PKIX drafts are supposed to contain  
the pointer to the Internet-Drafts Shadow Directories. The drafts do  
contain that introduction, but for the shadow directory for Europe most  
(all?) of them point to 'nic.nordu.net', a host that does no longer  
provide this service.

The actual address should read 'ftp.nordu.net' instead, which would also  
be in line with what is suggested in the recent version of the  
"Guidelines to Authors of Internet-Drafts".

	Ingmar Camphausen

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki2opp-04.txt
Date: Fri, 24 Oct 1997 09:37:18 -0400
Sender: [email-masked]
Status:

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

	Title		: Internet Public Key Infrastructure  
                          Operational Protocols - LDAPv2
	Author(s)	: T. Howes, S. Boeyen, P. Richard
	Filename	: draft-ietf-pkix-ipki2opp-04.txt
	Pages		: 11
	Date		: 23-Oct-97
	
     The protocol described in this document is designed to satisfy some
     of  the  operational  requirements  within  the Internet Public Key
     Infrastructure  (IPKI).   Specifically,  this  document   addresses
     requirements  to  provide access to Public Key Infrastructure (PKI)
     repositories for the purposes of  retrieving  PKI  information  and
     managing  that  same  information.  The mechanism described in this
     document is based on  the  Lightweight  Directory  Access  Protocol
     (LDAP) v2, defined in RFC 1777, defining a profile of that protocol
     for use within the IPKI and updates encodings for certificates  and
     revocation  lists  from  RFC 1778. Additional mechanisms addressing
     PKIX operational requirements are specified in separate documents.
      
     The key words  'MUST',  'REQUIRED',  'SHOULD',  'RECOMMENDED',  and
     'MAY'  in  this  document are to be interpreted as described in RFC
     2119.
      
     Please send comments on this document to  the  [email-masked]
     mail list.

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

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get I-D ACTION-draft-ietf-pk 10 (EuSn/CSOm) (0001C503)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki2opp-04.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-ipki2opp-04 (AURL/Arch) (0001C504)
Content-Type: text/plain
Content-ID:	<[email-masked]>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ocsp-00.txt
Date: Fri, 24 Oct 1997 09:37:32 -0400
Sender: [email-masked]
Status:

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

	Title		: Internet Public Key Infrastructure Online 
                          Certificate Status Protocol - OCSP
	Author(s)	: M. Myers
	Filename	: draft-ietf-pkix-ocsp-00.txt
	Pages		: 8
	Date		: 23-Oct-97
	
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure
(PKI).  This document specifies an HTTP-based application protocol use-
ful in determining the current status of a digital certificate without
the use of CRLs.  Additional mechanisms addressing PKIX operational re-
quirements are specified in separate documents.
 
Please send comments on this document to the [email-masked] 
mail list.

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

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get I-D ACTION-draft-ietf-pki 9 (EuSn/CSOm) (0001C501)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocsp-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-ocsp-00.txt (AURL/Arch) (0001C502)
Content-Type: text/plain
Content-ID:	<[email-masked]>

To: IETF-Announce:;;@tandem.com
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Internet Public Key Infrastructure Certificate Management Protocols to Proposed Standard
Reply-to: [email-masked]
Date: Fri, 24 Oct 1997 09:27:09 -0400
Sender: [email-masked]
Status:

The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider Internet Public Key Infrastructure
Certificate Management Protocols <draft-ietf-pkix-ipki3cmp-05.txt> as a
Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by November 7, 1997.

Files can be obtained via
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki3cmp-05.txt

Date: Fri, 24 Oct 1997 08:28:34 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: PKIX I KEA OID
Status:

All,

In PKIX Part I, Appendix A, "id-keyEncryptionAlgorithm" should be changed to
"id-keyExchangeAlgorithm" to be consistent with the Internet Draft Internet
Public Key Infrastructure Representation of Key Exchange Algorithm (KEA)
Keys in Internet Public Key                Infrastructure Certificates.

==============================================================
John Pawling                               (301) 953-3600
J.G. Van Dyke & Associates, Inc.           (410) 880-6095
141 National Business Pkwy, Suite 210      FAX: (301) 953-2901
Annapolis Junction, MD  20701              [email-masked]

Date: Thu, 23 Oct 1997 18:33:20 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Last Calls
Status:

Please consider the following I-D as being issued for 2-week WG last call
for progression to a Proposed Draft Standard:

>	Title		: Internet Public Key Infrastructure 
>                          Operational Protocols:  FTP and HTTP
>	Author(s)	: R. Housley
>	Filename	: draft-ietf-pkix-opp-ftp-http-01.txt
>	Pages		: 5
>	Date		: 22-Oct-97

Please consider the following I-D as being issued for 2-week WG last call
prior to publication as an Informational RFC:

>	Title		: Internet Public Key Infrastructure   
>                          Representation of Key Exchange Algorithm 
>                          (KEA) Keys in Internet Public Key 
>                          Infrastructure Certificates
>	Author(s)	: R. Housley, W. Polk
>	Filename	: draft-ietf-pkix-ipki-kea-01.txt
>	Pages		: 6
>	Date		: 15-Oct-97

Warwick

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-opp-ftp-http-01.txt
Date: Thu, 23 Oct 1997 09:34:08 -0400
Sender: [email-masked]
Status:

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

	Title		: Internet Public Key Infrastructure 
                          Operational Protocols:  FTP and HTTP
	Author(s)	: R. Housley
	Filename	: draft-ietf-pkix-opp-ftp-http-01.txt
	Pages		: 5
	Date		: 22-Oct-97
	
   The protocol conventions described in this document satisfy some of
   the operational requirements of the Internet Public Key
   Infrastructure (PKI).  This document specifies the conventions for
   using the File Transfer Protocol (FTP) and the Hypertext Transfer
   Protocol (HTTP) to obtain certificates and certificate revocation
   lists (CRLs) from PKI repositories.  Additional mechanisms addressing
   PKIX operational requirements are specified in separate documents.
 
   Please send comments on this document to the [email-masked]
   mail list.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-opp-ftp-http-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-opp-ftp-http-01.txt

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get I-D ACTION-draft-ietf-pki 8 (EuSn/CSOm) (0001C4FF)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-opp-ftp-http-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-opp-ftp-h 1 (AURL/Arch) (0001C500)
Content-Type: text/plain
Content-ID:	<[email-masked]>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-kea-01.txt
Date: Thu, 23 Oct 1997 09:55:19 -0400
Sender: [email-masked]
Status:

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

	Title		: Internet Public Key Infrastructure   
                          Representation of Key Exchange Algorithm 
                          (KEA) Keys in Internet Public Key 
                          Infrastructure Certificates
	Author(s)	: R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ipki-kea-01.txt
	Pages		: 6
	Date		: 15-Oct-97
	
   This is the second draft of a profile for specification of Key
   Exchange Algorithm (KEA) keys in Internet Public Key Infrastructure
   X.509 certificates. Please send comments on this document to the
   [email-masked] mail list.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki-kea-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-kea-01.txt

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get I-D ACTION-draft-ietf-pki 7 (EuSn/CSOm) (0001C4FC)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-kea-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-ipki-kea-01 (AURL/Arch) (0001C4FD)
Content-Type: text/plain
Content-ID:	<[email-masked]>

From: <[email-masked]>
Date: Wed, 22 Oct 1997 08:41:22 +0100
Subject: Searching_for_representatives
To: [email-masked]
Status:

Dear Friend!

We are offering an exclusive, unprecedented opportunity to earn money,
and even start your own marketing business in the field of online gambling.

We are a legitimate highly regarded firm, which has now developed a
technologically advanced web product that is a completely unique and 
new introduction to the Internet - the first 3D multi-player on line casino.

We are searching for representatives, who are well connected and have
proven marketing abilities, to cooperate with us in marketing our unique product.

Get more information at : http://www.casino-on.net/market

Best Regards,

Casino On Net
Marketing Department 
CASSAVA ENTERPRISES LTD.

-----------------------------------------------------
This email is for adults only! It concerns you only
if the Internet qambling is legal in your country.
-----------------------------------------------------

Date: Tue, 21 Oct 1997 16:08:13 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Component to use to build a certificate chain?
Cc: [email-masked] (IETF PKIX working group)
Status:

Ingmar,

>as I did not receive _any_ response/reaction on the question I raised
>ten days ago, I would like to shortly reiterate on the issue of building
>certificate chains *without* X.500 support.
>
>There had been two statement on this list from Peter Williams and Tim
>Polk that somewhat contradict each other, IMHO:
>
> * Peter wrote that the "AuthorityKeyId" extension was the extension
>   of choice to signal the parent cert's chain of certificates.
>   (My understanding of this extension was that its purpose was to
>   distinguish between multiple signing keys a single CA might hold,
>   but not to help in locating further parent certificates, no?)

I agree with this characterization, i.e., this extension allows one to
select among multiple certificates for a CA, to make deterministic the
process of validating the subject certificate.  It does not necessarily
provide a pointer for retrieving the right CA certificate. In fact, only
one of the three options might be useful as a real pointer, i.e., the
authorityCertIssuer, and it need not be so.

> * In contrast to that, Tim wrote in some notes he sent along
>   with PKIX Part1 draft 4 that the "issuerAltName" extension was
>   meant to point to "certificates whose subject is the issuer of
>   this certificate" and would be "used to build paths."

This extension allows a CA to have a name that is other than a DN.  That
name does not necessarily imply a path for retrieval of the CA cert.
However, one can loosely interpret this extension as necessary for
"building a cert path" in that it provides the back pointer in a cert path
validation sense.
>
>Should these statements (only) be seen within their "historical context"
>;), i.e. draft 4 and draft 5 of PKIX Part 1 ? -- If not, how can the
>contradiction between them be resolved? And wouldn't the
>"authorityInfoAccess" extension be used to achieve the goal of
>certificate chaining?

I don't see a contradiction here.  If the cert in question has an
issuerAltName extension and a null issuer field, then thie extension
provides the same basic back pointer function as the Issuer DN would have
provided.  The AuthorityKeyID is still appropriate to distinguish among
multiple certs associated with the CA, irrespective of the name form used
to identify the CA.

The authorityInfoAccess extension is used as a pointer to info that can aid
in the validation of a cert, e.g., the CA cert location and the CRL
location.  It is a true pointer in terms of directing a query to a specific
network site and specifying the protocol used for retrieval from that site;
the other two extensions provide IDs that may allow one only to confirm
that the right CA cert has been found, but that may not provide enough info
to actually locate the CA cert.

For example, the issuerAltName could be a DNS name, but that would not
necessarily indicate that the CA cert could be retrieved from the DNS.  The
AuthorityKeyID could be a hash of the CA public key, which provides no help
in retrieval in most instances.  However, the authorityInfoAccess could
specify use of HTTP and contain a URL, which would indiacte where to go
find the CA cert, which can then be validated as the right CA cert by using
the other two extensions.

Steve

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Mark Wahl'" <[email-masked]>
Subject: PKIX LDAP end of WG last call
Date: Tue, 21 Oct 1997 15:51:06 -0400
Status:

The PKIX WG last call on draft-ietf-pkix-ipki2opp-03.txt is now over and
the revised I-D will be published and forwarded to the IESG for
IETF-wide last call.

As a result of comments received, a few minor edits have been made to
clarify that this is a profile of LDAP v2, not to be confused with LDAP
v3 and to highlight the fact that the encoding used for certificates and
crls is an update of the encoding scheme defined in RFC 1778.

The changes include the document title, a new sentence in the abstract
and a new sentence at the end of section 7. The document header may also
be changed. 

No other comments were received.

Thanks to everyone who contributed and commented on this I-D. It's nice
to be able to conclude this activity less than a year after it was
started.

Sharon

------------------
Sharon Boeyen                  
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181 
http://www.entrust.com          Fax: (613) 247-3690 
         Orchestrating Enterprise Security

From: Dean Povey <[email-masked]>
To: Hal Lockhart <[email-masked]>
Cc: [email-masked]
Subject: Re: Constraints on wildcard matching in host names? 
Date: Tue, 21 Oct 97 12:23:25 +1000
Status:

>At 08:56 AM 10/20/97 +1000, you wrote:
>
>>There are some cases where wildcarding in certificates has legitimate
>uses, and some 
>>CAs will want to issue certs containing them.  Others will not issue
>wildcarded certs, 
>>this is all up to the policy of the individual CA. However my point was
>that you should 
>>NEVER be able to issue a certificate with a name like *.com etc.  This is
>of course 
>>quite obvious, but I think it should an explicit statement should be made
>in the 
>>Certificate and CRL profile.
>
>My point was twofold:
>
>1. First to emphasize the fact that IMHO, the IETF PKI does not specify
>enough to provide any kind of interoperability and the *real* standard will
>be created by Microsoft, Netscape, etc., and
>

In light of the fact that this is what the working group is designed to do, I 
am somewhat perturbed by this statement.  What to do you think is lacking in
the proposed specifications that does not specify everything necessary for 
interoperability within the scope of the PKIX charter?

>2. I don't think your suggestion is practical, because there is no "right"
>place to draw the line.  Certainly *soft.com should not be allowed, but
>someone will not doubt argue that test*.austin.ibm.com should be permitted.
> Clearly *.com is NG, but I can imagine that even
>*.derivative.trading.jpmorgan.com might be dangerous.  The root problem is
>that there is no relationship between CA scope and naming scope.  Verisign,
>for example will issue a cert to any domain (I don't think they use
>wildcards.) This harkens back to the old X.500 debate, PEM, etc.

Someone may indeed decided that these particular examples are dangerous.  
However, it is down to the individual CAs policies to decide whether they will
issue certs of these types.  If the PKIX profile is going to include
a requirement for wildcarding support, then we should at least mandate some
constraints.  My approach was to go for the minimalist set. Others can
specify more stringent constraints in their individual implementations.

>By the way, I admit not having looked at this in the spec.  How general is
>the wildcarding?  Do they allow regular expressions?
>

>From the draft:

   Where the subjectAltName extension contains a dNSName, this name may
   contain the wildcard character. An "*" is the wildcard character.
   Where a dNSName includes a wildcard, the subject of this certificate
   is a subnet or a collection of hosts. Examples include *.bar.com and
   www*.bar.com.

   Where the subjectAltName extension contains an rfc822Name, this name
   may also include the wildcard character. Use of the wildcard is
   limited to the host name.

   Where the subjectAltName extension contains a
   uniformResourceIdentifier, the URI is a pointer to a sequence of
   certificates issued by this CA (and optionally other CAs) to this
   subject. The URI may not contain the wildcard character in the host
   name.

So regular expressions are not allowed, only wildcarding.
-- 
+----------------------------------------+-------------------------------+
| Dean Povey,                            |  Email: [email-masked]     |
| Research Scientist, Security Unit,     |  Phone: +61 7 3864 2799       | 
| CRC for Distributed Systems Technology |  Fax:   +61 7 3864 1282       |
+----------------------------------------+-------------------------------+

From: <[email-masked]>
Date: Mon, 20 Oct 1997 18:04:32 -0400 (EDT)
To: <[email-masked]>
Subject: Computer Geeks
Reply-To: [email-masked]
Comments: Authenticated Sender is <[email-masked]>
Status:

Our Apologies for the intrusion, but a  friend referred you as someone who 
might be interested in a web site offering some of the hottest computer
hardware deals on the internet.

Where are these deals?

......................... http://www.compgeeks.com .......................

What are these deals?

Hard drives...Modems...Sound cards...CD-ROM drives...Video Cards...Scanners...and
more!

Computer Geeks Discount Outlet, Inc. offers unbelievable prices on popular and 
interesting computer parts, and we feature FULLY-SECURE online ordering directly 
from our virtual storefront which is SAFER and more CONVENIENT than ordering
by phone, US Mail, or in a store.

All products listed on our site are in stock and ready to ship directly 
from our warehouse.  Most orders ship within 24 hours, and we pass our UPS 
volume discount rates along to YOU!

For the rest of 1997, first-time customers may take advantage of a 10%
discount on their first web order simply by placing the following
code in the Comment field of our electronic order form: SP101.

Our site is updated daily, and our inventory changes frequently.

Please take a moment to pay us a visit-we think you'll be glad you did.

Thank you for your time!

The Geeks @ Computer Geeks Discount Outlet, Inc.

From: <[email-masked]>
Date: Mon, 20 Oct 1997 09:45:34 -0600
To: [email-masked]
Subject: OCSP request date
Status:

All--

I would like to propose that OCSP requests contain a date field.  It seems
this is an essential requirement for validating aged signed content.  It
also neatly does away with the somewhat artificial distinction of "current
revocation status" vs. "historical revocation status."  Queries concerned
with current status simply use the current date.

Comments?

--Mike

Date: Mon, 20 Oct 1997 10:02:34 -0400
To: <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Certificate Authority or Certification Authority ?
Cc: [email-masked]
Status:

Fabio,

	The term "Certification Authority" is preferred.

Steve

Date: Mon, 20 Oct 1997 19:53:34 +0800
To: [email-masked]
From: Incheon Paik <[email-masked]>
Subject: unsubscribe
Status:

unsubscribe

Date: Mon, 20 Oct 1997 10:19:42 +0200
To: [email-masked] (David P. Kemp)
From: [email-masked] (Olivier Onimus)
Subject: Re: CRL empty list syntax
Cc: [email-masked]
Status:

The DER-coding rules do NOT specify (X.690) how to encode an empty optional
SEQUENCE OF:
nothing or empty SEQUENCE ?
-> well, what can we do to encode such an element in a unambiguous way ?

IMHO, the encoding of an empty optional SEQUENCE OF should be: nothing
This would be in "accordance" with DER-rules, which specify (among other
things),
that the DEFAULT elements in a SEQUENCE should not be encoded, and that the
length of the
elements should be encoded with the minimum number of octets.

Nevertheless, the best solution would be to define in a recommendation (X.690)
the non ambiguous coding of an empty optional SEQUENCE OF .

Olivier

>
>Both X.509 and PKIX part1-06 define the list part of a CRL as:
>
>
>   revokedCertificates  SEQUENCE OF SEQUENCE {
>       userCertificate     CertificateSerialNumber,
>       revocationDate      Time,
>       crlEntryExtensions  Extensions OPTIONAL
>   } OPTIONAL,
>
>
>This admits the possibility of two encodings of a CRL containing
>no certificate entries: an empty SEQUENCE, or nothing (since
>revokedCertificates is OPTIONAL).
>
>Would it be better to eliminate this ambiguity by constraining
>the list size to contain at least one entry?
>
>    revokedCertificates  SEQUENCE SIZE (1..MAX) OF SEQUENCE {
>
>
>Consider this an "informal defect report" against X.509.
>
>

Date: Sun, 19 Oct 1997 21:33:51 -0400
From: Steve Schrump <[email-masked]>
Reply-To: [email-masked]
Organization: Cebra Inc.
To: [email-masked]
Subject: unsubscribe
Status:

unsubscribe

Date: Sat, 18 Oct 1997 12:42:42 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: CRL empty list syntax
Status:

In a new industry, IMHO, there may be a time that there are no legitimate CRL entries to be made, but that one would need to issue CRL's on a schedule according to the CA's CPS so that all reliant parties know that one CRL did not get "lost" .

Michael
>>> David P. Kemp <[email-masked]> 10/17/97 02:05PM >>>

Both X.509 and PKIX part1-06 define the list part of a CRL as:

   revokedCertificates  SEQUENCE OF SEQUENCE {
       userCertificate     CertificateSerialNumber,
       revocationDate      Time,
       crlEntryExtensions  Extensions OPTIONAL
   } OPTIONAL,

This admits the possibility of two encodings of a CRL containing
no certificate entries: an empty SEQUENCE, or nothing (since
revokedCertificates is OPTIONAL).

Would it be better to eliminate this ambiguity by constraining
the list size to contain at least one entry?

    revokedCertificates  SEQUENCE SIZE (1..MAX) OF SEQUENCE {

Consider this an "informal defect report" against X.509.

From: <[email-masked]>
To: [email-masked]
Date: Sat, 18 Oct 1997 10:38:04 +0200
Subject: Certificate Authority or Certification Authority ?
Status:

Hi all,

I am new on this list. Sorry if the question is not very interesting for
you.
Which is the righ term for CA ? Certificate Authority (used in SET) or
Certification Authority (used in PKIX documents) ?
Thanks in advance.
Fabio Omenigrandi
SSB s.p.a.

Date: Fri, 17 Oct 1997 16:05:35 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: CRL empty list syntax
Status:

Both X.509 and PKIX part1-06 define the list part of a CRL as:

   revokedCertificates  SEQUENCE OF SEQUENCE {
       userCertificate     CertificateSerialNumber,
       revocationDate      Time,
       crlEntryExtensions  Extensions OPTIONAL
   } OPTIONAL,

This admits the possibility of two encodings of a CRL containing
no certificate entries: an empty SEQUENCE, or nothing (since
revokedCertificates is OPTIONAL).

Would it be better to eliminate this ambiguity by constraining
the list size to contain at least one entry?

    revokedCertificates  SEQUENCE SIZE (1..MAX) OF SEQUENCE {

Consider this an "informal defect report" against X.509.

Date: Fri, 17 Oct 1997 13:52:26 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: DirectoryString in PKIX-1
Status:

I would agree that the teletexString option is needlessly complicated and
unnecessary. In addition, I question whether it is at all necessary or
desirable to require a dynamic, run-time evaluation of the particular
characters which make up a string before deciding what representation to
use.

If I have an application which uses BMPString for all of its internal
operations, in order to facilitate internationalization (nut just European
languages, but Asian languages as well, it should be perfectly acceptable to
use BMPString as the output regardless of the character set that requires. 
In other words, I shouldn't have to scan my double-byte enabled internal
representation of a name for an umlaut, c-cedilla, etc., before deciding
what output representation to use. I should be able to use BMPString on the
output and forget about it.

The options are needless complex.

Bob

>Hi all,
>
>It is good that the latest draft of part 1 has added BMPString
>to the DirectoryString definition.
>
>However, since teletexString is still present, the following
>sentences (see below) declares that any certificate that includes
>characters (e.g. any europeen language except english) that isn't
>included in the 7-bit ASCII format (A-Z, a-z) have to be encoded in
>T.61/teletexString.
>
>This is just not acceptable.
>
>As Peter Gutman poited out in the X.509 Guide, T.61 is one of the
>"peculiar and strange oddball encodings". His recommendation
>is (again quoted): "Avoid this one.  Anyway: Avoid this one".
>
>So, as long as ISO doesn't give us a tag for ISO 8859-1, I guess
>we europeans have to live with BMPString encoding. But please:
>don't force us to use T.61/teletexString. Take away that option
>(or redefine the meaning of "sufficient" below), please!!!
>
>>   The directoryString is defined as a choice of PrintableString,
>>   TeletexString, BMPString and UniversalString.  Conforming CAs shall
>>   choose from these options as follows:
>>
>>      (a) if the character set is sufficient, the string will be
>>      represented as a PrintableString;
>>
>>      (b) failing (a), if the teletexString character set is sufficient,
>>      the string will be represented as a TeletexString;
>>
>>      (c) failing (a) and (b), if the bMPString character set is
>>      sufficient the string shall be represented as a BMPString; and
>>
>>      (d) failing (a), (b) and (c), the string shall be represented as a
>>      UniversalString.
>
>Regards,
>/Lars Johansson
>Sweden Post
>

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are tring to get to the moon, climbing a tree, 
although a step in the right direction, will not prove 
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

From: Ingmar Camphausen <[email-masked]>
Date: Fri, 17 Oct 97 19:14:59 +0200
To: [email-masked] (PKIX working group)
Subject: 2 points re: URI form of 'AccessDescription' in draft#6 of part 1
Reply-To: [email-masked]
Priority: normal
Status:

I have come across two other issue with draft#6 of part 1:

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

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

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

   2.  Append a filename to the URL.

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

(1) This is a little bit _too_ much fixed on HTTP as transport service,
IMHO. As the URI form is not limited to HTTP-URLs but might also include
FTP, LDAP etc., I would like to suggest a more generic description a la

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

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

   2.  Append a filename to the URI.
 
   3.  Use the result to retrieve a file containing the requested
   certificate.
   ..."

BTW: Shouldn't the words `authorityInfo field' from the second sentence
of the quoted section rather read `accessLocation field'?

The field was called `authorityInfo' in draft #4 of PKIX part 1 as
part of the definition

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

within that version of part 1, but this was replaced (in draft #5)
by the more flexible and generic

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

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

(2) The mentioned paragraph of section 4.2.2.1 (Authority Information
Access) on page 36 of draft 6 continues:

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

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

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

[...hexadecimal... would be correct, I suppose.]
       =

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

What made me wonder: I would rather have expected this "restriction"
on filenames to be described (or mentioned) in the PKIX part covering 
FTP and HTTP as operational protocols (i.e. in 
draft-ietf-pkix-opp-ftp-http-00.txt)?

	Ingmar

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

From: <[email-masked]>
Date: Fri, 17 Oct 97 14:21:21 +0200
Subject: DirectoryString in PKIX-1
To: [email-masked]
Status:

Hi all,

It is good that the latest draft of part 1 has added BMPString
to the DirectoryString definition.

However, since teletexString is still present, the following
sentences (see below) declares that any certificate that includes
characters (e.g. any europeen language except english) that isn't
included in the 7-bit ASCII format (A-Z, a-z) have to be encoded in
T.61/teletexString.

This is just not acceptable.

As Peter Gutman poited out in the X.509 Guide, T.61 is one of the
"peculiar and strange oddball encodings". His recommendation
is (again quoted): "Avoid this one.  Anyway: Avoid this one".

So, as long as ISO doesn't give us a tag for ISO 8859-1, I guess
we europeans have to live with BMPString encoding. But please:
don't force us to use T.61/teletexString. Take away that option
(or redefine the meaning of "sufficient" below), please!!!

>   The directoryString is defined as a choice of PrintableString,
>   TeletexString, BMPString and UniversalString.  Conforming CAs shall
>   choose from these options as follows:
>
>      (a) if the character set is sufficient, the string will be
>      represented as a PrintableString;
>
>      (b) failing (a), if the teletexString character set is sufficient,
>      the string will be represented as a TeletexString;
>
>      (c) failing (a) and (b), if the bMPString character set is
>      sufficient the string shall be represented as a BMPString; and
>
>      (d) failing (a), (b) and (c), the string shall be represented as a
>      UniversalString.

Regards,
/Lars Johansson
Sweden Post

Sender: [email-masked]
Date: Fri, 17 Oct 1997 11:55:41 +0200
From: Petra Gloeckner <[email-masked]>
To: Peter Whittaker <[email-masked]>, [email-masked], [email-masked]
Subject: Re: CrlDistributionPoint extension
Status:

Peter Whittaker wrote:
> 
> At the risk of proposing a solution without having thought about it too
> deeply, it doesn't seem like a great problem.  The cRLDistributionPoint
> extension names the directory entry that would contain the RL that would
> indicate whether the certificate had been revoked.  There is no reason
> why such an entry could not contain multiple values of the revocation
> list in question, that is, multiple values of the
> authorityRevocationList attribute (since these are CA certificates).
> 
> (OK, this may seem like it defeats the point of cRLDistributionPoints,
> but when faced with thorny problems sometimes a little pragmatism is
> needed.)
> 
> The top-level CA could revoke the national CA certificates, creating
> appropriate ARLs, and writing each of these ARLs to the each national
> CA's cRLDistributionPoint entry.  It would then issue new certificates,
> referencing the correct cRLDistributionPoint entry.
> 
> This would mean that in the authorityRevocationList attribute of each
> national CA's cRLDistributionPoint entry, there would be two revocation
> list values, at least until the original national CA certificates had
> expired:  one would be the ARL issued by the top-level CA, and
> containing only the national CA's old certificate, the other would be
> the national CA's current authority revocation list.
> 
> That's where the pragmatism comes in:  the idea of a
> cRLDistributionPoint entry is to allow RLs to broken into more
> manageable chunks (either for reasons of size or revocation reason, or
> what-have-you).  Having two RLs as values of the same attribute in a
> single cRLDistributionPoint entry would seem to violate this idea, but
> the ARL issued by the top-level CA would be small (would only contain
> the national CA's original certificate, and would never grow, as the
> top-level CA has started using its own cRLDistributionPoint entry) and
> this ARL would eventually be removed, that is, once the national CA's
> original certificate expires and need no longer be listed on the ARL;
> the ARL becomes obsolete and is removed.  Note that this ARL will have
> to be long-lived.
> 
> Clients retrieving the ARL from the national CA's cRLDistributionPoint
> entry would find two values, and would have to deal with this, but one
> of those values would be quite small, and would be ignored in most
> cases, as the clients would be looking for an ARL issued by the national
> CA in question.
> 
> Note that the national CA, if it uses the potential maximum size of the
> RL as a criteria for deciding when to create a new cRLDistributionPoint
> entry (for example, to accommodate clients with memory limitations),
> would have to adjust its size criteria accordingly (memory limit -
> (safety factor + sizeof("the little ARL"))).
> 
> >This would require that for the duration of this operation the top-level CA
> >be given write-access to each national CA's cRLDistributionPoint entry;  once
> >the operation completes, this access could be revoked; alternatively, the
> >ARLs could be transferred to the national CAs in some out-of-band manner, and
> >they would write them into the directory themselves, thereby avoiding any
> >potential problems with opening their directory access permissions.
> >
> >Maybe it's not such a bad idea after all to change the meaning of
> >this extension in a way that a CA certificate really contains its OWN
> >CrlDistributionPoint instead of the issuing CA's CrlDistributionPoint !
> >Then this extension would be used in CA certificates only.
> 
> No, this would cause interoperability problems, grief, and churn for
> those who used the cRLDistributionPoint as it was intended (I suspect
> that this is a large-and-getting-larger percentage of the
> V3-cert-and-V2-RL-using community).  Furthermore, it would require that
> the issuer CA always have write access to the subject's
> cRLDistributionPoint entry, something which may be unpopular with the
> managers of the subject's directory (they may be willing to allow it for
> a single operation, but probably not on an ongoing basis).
> 
> pww

No, it wouldn't require that the issuer CA has write access to the 
subject's cRLDistributionPoint entry.
Each CA publishs his CRL at his own cRLDistributionPoint. Only the 
verification procedure will be different because a certificate user 
won't find the respective cRLDistributionPoint in the user certificate 
but one level above in the issuing CA's certificate.
So the certificate extension cRLDistributionPoint wouldn't contain the  
CRL which might contain this certificate, but the CRL issued by this CA
which might contain certificates issued by this CA.

But I agree with you that probably too many people have already 
implemented the X.509v3 extensions, so there would be great 
interoperability problems.

Thank you very much for the detailed answer. I will recommend to our top 
level CA to follow the proposed procedure.

Best regards, Petra

Sender: [email-masked]
Date: Fri, 17 Oct 1997 11:55:55 +0200
From: Petra Gloeckner <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: CrlDistributionPoint extension
Status:

Francisco Jordan wrote:
> 
> Petra,
> 
> in your proposal you are forgetting CRL partition
> along the live of a CA certificate. For instance:
> ICE-TEL TLCA has signed the Spanish CA but I don't want the TLCA
> hard-sign
> my CRLDistributionPoint in my cert, since I want to be free to
> create as many CRLs as I need to accommodate all my community,
> all the revocation reasons, etc. and put such a CRL in my
> issuing certs just to tell the issued where to get the
> suitable CRL. Of course, including user certificates.

Hi Francisco,

yes, you are right. That's a good reason not to put the own
cRLDistributionPoints in the certificate but the ones of the
issuing CA.

> So, I think the standard is perfectly adjusted to the PKI needs.
> 

Yes, I just wanted to point out the problem we came across and was
looking for a solution. Peter Whittaker gave a pragmatic good solution
how to overcome the problem. Thanks, Peter !

Regards, Petra

Date: Fri, 17 Oct 1997 08:56:36 +0200
From: Francisco Jordan <[email-masked]>
Reply-To: [email-masked]
Organization: UPC
To: Petra Gloeckner <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: CrlDistributionPoint extension
Status:

Petra,

in your proposal you are forgetting CRL partition
along the live of a CA certificate. For instance:
ICE-TEL TLCA has signed the Spanish CA but I don't want the TLCA
hard-sign
my CRLDistributionPoint in my cert, since I want to be free to 
create as many CRLs as I need to accommodate all my community, 
all the revocation reasons, etc. and put such a CRL in my
issuing certs just to tell the issued where to get the 
suitable CRL. Of course, including user certificates.
So, I think the standard is perfectly adjusted to the PKI needs.

Regards,
Francisco Jordan

> 
> Hello,
> 
> we have build up (and still do) an European certification
> infrastructure ( http://www.darmstadt.gmd.de/ice-tel ).
> Now we came across a problem concerning the X.509v3 certificate
> extension CrlDistributionPoint.
> 
> Our top level CA has issued certificates to national CAs containing
> the national CA's CrlDistributionPoint rather than its own
> CrlDistributionPoint.
> Well, this was not the way they were supposed to do it, at least not
> the way the X.509v3 standard defines this extension. But what do we
> do now ?
> 
> If the top level CA revokes all these certificates nobody will know
> that they are revoked because the respective certificates contain
> the wrong CrlDistributionPoint.
> 
> Maybe it's not such a bad idea after all to change the meaning of
> this extension in a way that a CA certificate really contains its OWN
> CrlDistributionPoint instead of the issuing CA's CrlDistributionPoint !
> Then this extension would be used in CA certificates only.
> A certificate user has to obtain the issuing CA's certificate anyhow
> to check the signature of the certificate. Now he will additionally
> retrieve the CRL specified in the CrlDistributionPoint extension of
> the CA certificate.
> 
> Any opinions ?
> 
> Petra Gloeckner
> 
>     ---------------------------------------------------------------
> 
>                            Name: smime.p7s
>          Part 1.2          Type: application/x-pkcs7-signature
>                        Encoding: base64
>                     Description: S/MIME Cryptographic Signature

Date: Thu, 16 Oct 1997 12:27:09 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
Reply-To: Marc Branchaud <[email-masked]>
To: PKIX <[email-masked]>
Subject: Latest draft (#6) of part 1
Status:

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

I have two issues with the latest draft of part 1.  The first I stated
just before this last draft came out, so I'm re-stating it since it still
applies.  The other is just a nit.

(1) In 4.2.1.12 (Policy Constraints), one page 31, the ASN.1 for this
extension includes these lines:

	CertificatePoliciesSyntax ::=
		SEQUENCE SIZE (1..MAX) OF PolicyInformation

The ASN.1 in the appendices, however, doesn't have any such thing.  Is
this extension supposed to include a bunch of PolicyInformation
structures?  (BTW, the ASN.1 in appendix B has a space in
"PolicyConstraints Syntax" near the top of page 85, which I don't think
should be there.)

In reading through the draft, I was wondering _which_ policies this
extension's requireExplicitPolicy field would refer to.  The draft says:

	An acceptable policy identifier is the identifier of a
	policy required by the user of the certification path or the
	identifier of a policy which has been declared equivalent through
	policy mapping.

This seems to indicate that the extension itself should not have anything
that identifies a policy.  I wonder, though, if that's wise.  Wouldn't it
make sense for the issuer to use the certificate to state which policies
are acceptable?  If so, a list of policy OIDs should be adequate rather
than a list of PolicyInformation structures.

(2) Shouldn't the Certificate Issuer CRL entry extension be in section 5.3
(CRL entry extensions) instead of 5.2 (CRL extensions)?

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6210x227      www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

From: Ingmar Camphausen <[email-masked]>
Date: Thu, 16 Oct 97 20:11:38 +0200
To: [email-masked] (IETF PKIX working group)
Subject: Re: Component to use to build a certificate chain?
Reply-To: [email-masked]
Priority: normal
Status:

Dear PKIX readers,

as I did not receive _any_ response/reaction on the question I raised
ten days ago, I would like to shortly reiterate on the issue of building  
certificate chains *without* X.500 support.

There had been two statement on this list from Peter Williams and Tim
Polk that somewhat contradict each other, IMHO:

 * Peter wrote that the "AuthorityKeyId" extension was the extension
   of choice to signal the parent cert's chain of certificates.
   (My understanding of this extension was that its purpose was to
   distinguish between multiple signing keys a single CA might hold,
   but not to help in locating further parent certificates, no?)

 * In contrast to that, Tim wrote in some notes he sent along
   with PKIX Part1 draft 4 that the "issuerAltName" extension was
   meant to point to "certificates whose subject is the issuer of
   this certificate" and would be "used to build paths."

Should these statements (only) be seen within their "historical context"  
;), i.e. draft 4 and draft 5 of PKIX Part 1 ? -- If not, how can the  
contradiction between them be resolved? And wouldn't the  
"authorityInfoAccess" extension be used to achieve the goal of  
certificate chaining?

I understand that you are probably all very busy getting the drafts  
through "last
call" stage, nevertheless I would really very much appreciate it if some kind  
soul would comment on this issue.

Thanks,
	Ingmar

--------------------------------------------------------------------------------
Ingmar Camphausen <[email-masked]>
GMD FOKUS (Research Institute for Open Communication Systems)
Phone: ++49-30-3463-7357  *  Fax: -8357

> From: Ingmar Camphausen <[email-masked]>
> Date: Mon,  6 Oct 97 17:35:05 +0200
> To: IETF PKIX mailinglist <[email-masked]>
> Subject: Component to use to build a certificate chain?
>
> Having read the recent versions of Part I and Part II, I am still in
> doubt about the component(s) to use for the (automatic) construction of a  
> certificate chain from within an application that does not have X.500 or  
> LDAP support.
>
> Suppose I have a PKIX conformant certificate issued by a CA that does  
> not use the X.500 directory service as distribution medium for its
> certificates but, e.g., HTTP instead. Suppose further that I simply want  
> to build a certificate chain to the "toplevel" issuing CA.
>
> I have encountered three different components that -- at least in my
> perception -- might then serve for the construction of certificate chains  
> for the verification of a certificate. I am not sure whether the drafts  
> are ambiguous in this regard or whether I have missed a point somewhere  
> (the latter being probably more likely ;-), so I would really welcome  
> your comments on this.
>
>
> My three "candidates" for the "links" within a certificate chain from a  
> given certificate to a (possibly trusted) top-level CA's self-signed
> certificate are:
>
>
> * the `authorityKeyId extension'
>
>   as Peter Williams, in response to another question from me, pointed out:
>
>   > The ability in X.509 to signal the cert's parent's chain
>   > of certs was surely given over to the authorityKeyId
>   > extension. A GeneralName there can also be a URI, and
>   > could sensibly be a URL to a collection of certs for
>   > that CA party (one for cert issuing, another for CRL
>   > issuing, another for auth-cert issuing; and each of
>   > which can be supported by its own path.)
>
>
> * issuerAltName (despite Peter Williams' reply to my respective question)
>
>   The following comment Tim Polk mailed in his note accompanying the
>   PKIX Part1 draft 4:
>
>   > I've attached an ASCII table summarizing the pointers to external
>   > information in the PKIX certificate for this draft. The table
>   > does not appear in the draft. It is intended to assist you as you
>   > review draft 4. I think we can provide all the information needed
>   > to validate a path through the certificate - can you think of
>   > anything I've missed?
>   [...]
>   > Summary of "pointers to external information" in Part 1 certificate.
>   [...]
>   > |------------------------------------------------------------------|
>   > | issuerAltName  |   certificates whose subject is the issuer of   |
>   > |                |   this certificate; used to build paths. URI    |
>   > |                |  specifies scheme and object (object implied    |
>   > |                |  for mailto)                                    |
>   > |------------------------------------------------------------------|
>
>
> * the `authorityInfoAccess' extension
>
>   as described in the second half of 4.2.2.1 in
>   draft-ietf-pkix-ipki-part5-00.txt)
>
>   > This profile defines an object identifier to obtain a description of
>   > the CAs that have issued certificates superior to the CA that issued
>   > the certificate containing this extension.  The referenced CA Issuers
>   > description is intended to aid certificate users in the selection of
>   > a certification path that terminates at a point trusted by the
>   > certificate user.  The syntax of the referenced CA Issuers
>   > description will be defined in PKIX Part 2. [...]
>   [...]
>   > The authorityInfoAccess extension may be included in a PKCS 7
>   > encapsulation as an X.501 ATTRIBUTE. This attribute can then be
>   > used to locate certificates automatically rather than include
>   > the certificates directly.
>
>
> So which component of an X.509v3 certificate would a PKIX-conformant CA  
> use to help all those implementations build the certification path that  
> do neither support X.500 nor LDAP and hence must rely on certificate
> retrieval via, e.g. HTTP or FTP?
>
>
> BTW: The 3rd paragraph of 4.2.2.1 contains:
>
> >    This profile defines an object identifier for the On-line Certificate
> >    Status Protocol (OCSP) that will be defined in PKIX Part 2.  When
>                       ~~~~                                ~~~~~~
>
> Isn't that reference outdated? draft-ietf-pkix-ipki2opp-03 does not
> contain the OCSP any more as far as I could see.
>
> (Maybe either the "PKIX Part <n>" titles could be added to *all* of the
> PKIX drafts, or the references within the drafts be made more precise?)
>
>
> 	Ingmar Camphausen
>
> __________________________________________________________________
> Internet : [email-masked]
> Phone    : ++49 / (0)30 / 34 63 - 73 57
> Fax      : ++49 / (0)30 / 34 63 - 83 57
> Address  : Research Institute for Open Communication Systems
>            GMD FOKUS, Kaiserin-Augusta-Allee 31, D-10589 Berlin, Germany
>

Date: Thu, 16 Oct 1997 11:45:37 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: CRL "Not Activated" Reason Code
Status:

David, I completely agree with your analysis, but would offer a slightly
different scenario which I believe makes the case even more compelling.
perhaps its what you had in mind in any case.

One of the questions I am sometimes asked is, "What is the effective
difference between an RA and a CA?  If the RA is going to digitally sign a
request that a certificate be issued and the CA is going to blindly comply,
then why not have the RA just mint the certificate in the first place? Where
is the value-add that the CA provides?"

The answer, I believe, is that the RA is morally, and probably legally,
responsible for the validation of attributes in the certificate, including
the subject's identity, and binding those attributes with the subject's
public key, although either the RA or the CA might carry out the mechanistic
verification of proof of possession of the corresponding private key.

So far, this sounds a lot like a CA. But what the CA is responsible for that
the RA is not, I believe, and the essential difference between them, is the
legal requirement for confirmation of issuance of the certificate to and its
acceptance by the subscriber or subject, whether the certificate is
published or kept private.  (They may also be a difference of legal
responsibility for CRL acceptance and publishing, but arguments could be
made for a RA, a CA, or a repository carrying out that function, so I won't
get into that right now. Clearly the CA is required to be able to issue
CRLs, but whether it needs to , or whether some other component could carry
out that function is a different issue.)

In some case the subscriber may act in his own capacity as a RA, and
essentially self-certify the validity of the attributes in a prototype
certificate to a CA, and request that a certificate be issued.  In other
cases, particularly involving the use of an organization name, and
especially in the case of an organizational agent or role, a formal RA may
be required.

But it will often be the case that face-to-face issuance or certificates is
neither desirable nor practical.  How then can the CA perform its duty of
assuring the proper issuance and acceptance function?

One way is to go though the certificate minting process on-line, returning
the newly signed certificate to the subscriber immediately upon request, or
only a short time later. If the certificate was going to be published, the
CA could simply delay posting the certificate to the directory until
confirmation of acceptance had been received (and the check cleared). 
However, there is no obligation on either the CA or the subscriber to
publish the certificate, and considering the fact that it may contain
somewhat sensitive information (e.g., the person's address), the subscriber
may choose not to list the certificate in a public directory, but instead
deliver it only to those with a need-to-know.

In this case, the user can run away with the newly minted certificate, and
until or unless the CA decides to revoke it, can use the certificate without
appropriate authority and perhaps impersonate someone else.

The way to control this situation is to go ahead and issue the certificate
to the purported subscriber, but to mark the certificate with a temporary
"pending", "not confirmed", or 'suspended" flag so that it is not considered
to be valid, but not revoked either.

Then the CA can send out an appropriate legal notice, perhaps using
Certified Mail, Return Receipt Requested, Address Confirmation Requested,
Restricted Delivery, to ensure that the notice of issuance reaches the
correct individual (and by the way invoking two different (US) federal
felony statutes if the recipient misidentifies himself and/or uses the
invalid certificate to defraud someone).  By including a PIN in the
certified mail letter, the CA can provide the user with a legally binding
way of indicating his acceptance of the certificate and its contents, as
well as the legal notice putting the user on record as to his duties and
obligations to protect his private key.

When the user dials in to the AVR unit and correctly enters his PIN, the
loop has been closed and the certificate can be taken off the pending or
suspended status, and everything is now perfectly valid and acceptable.

Assuming that the certificate suspend function is implemented, it wouldn't
matter terribly whether a specific reason code for "Not yet Activated" was
assigned or not. However, some state statutes suggest or imply that a
suspension per se is for a specific, limited amount of time, e.g., 72 hours,
after which the certificate must either be declared valid, or revoked. 
since the logic behind that (not wishing to have certificates remain in a
suspended state for too long) doesn't apply when the certificate is first
issued, and before it has been accepted or activated, a separate reason code
for "Not Yet Activated" would be a Good Thing.

And BTW, although I haven't stayed close enough to the issue to know the
current status, I would hope that the initial feeling that a suspended state
should be deprecated has since been reversed, and that it is now a
well-accepted, if not mandatory, mode of operation under the PKIX
guidelines.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

     

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki3cmp-05.txt
Date: Thu, 16 Oct 1997 12:56:30 -0400
Sender: [email-masked]
Status:

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

	Title		: Internet Public Key Infrastructure     
                          Certificate Management Protocols
	Author(s)	: C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-ipki3cmp-05.txt
	Pages		: 69
	Date		: 15-Oct-97
	
This is a draft of the Internet Public Key Infrastructure (X.509)
Certificate Management Protocols. Protocol messages are defined for all
relevant aspects of certificate creation and management.

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

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get I-D ACTION-draft-ietf-pki 6 (EuSn/CSOm) (0001C443)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki3cmp-05.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-ipki3cmp-05 (AURL/Arch) (0001C444)
Content-Type: text/plain
Content-ID:	<[email-masked]>

From: Peter Whittaker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Petra Gloeckner'" <[email-masked]>
Subject: RE: CrlDistributionPoint extension
Date: Thu, 16 Oct 1997 13:05:22 -0400
Status:

>Our top level CA has issued certificates to national CAs containing
>the national CA's CrlDistributionPoint rather than its own 
>CrlDistributionPoint. 
>Well, this was not the way they were supposed to do it, at least not
>the way the X.509v3 standard defines this extension. But what do we
>do now ? 
>
>If the top level CA revokes all these certificates nobody will know
>that they are revoked because the respective certificates contain
>the wrong CrlDistributionPoint.

At the risk of proposing a solution without having thought about it too
deeply, it doesn't seem like a great problem.  The cRLDistributionPoint
extension names the directory entry that would contain the RL that would
indicate whether the certificate had been revoked.  There is no reason
why such an entry could not contain multiple values of the revocation
list in question, that is, multiple values of the
authorityRevocationList attribute (since these are CA certificates).

(OK, this may seem like it defeats the point of cRLDistributionPoints,
but when faced with thorny problems sometimes a little pragmatism is
needed.)

The top-level CA could revoke the national CA certificates, creating
appropriate ARLs, and writing each of these ARLs to the each national
CA's cRLDistributionPoint entry.  It would then issue new certificates,
referencing the correct cRLDistributionPoint entry.

This would mean that in the authorityRevocationList attribute of each
national CA's cRLDistributionPoint entry, there would be two revocation
list values, at least until the original national CA certificates had
expired:  one would be the ARL issued by the top-level CA, and
containing only the national CA's old certificate, the other would be
the national CA's current authority revocation list.

That's where the pragmatism comes in:  the idea of a
cRLDistributionPoint entry is to allow RLs to broken into more
manageable chunks (either for reasons of size or revocation reason, or
what-have-you).  Having two RLs as values of the same attribute in a
single cRLDistributionPoint entry would seem to violate this idea, but
the ARL issued by the top-level CA would be small (would only contain
the national CA's original certificate, and would never grow, as the
top-level CA has started using its own cRLDistributionPoint entry) and
this ARL would eventually be removed, that is, once the national CA's
original certificate expires and need no longer be listed on the ARL;
the ARL becomes obsolete and is removed.  Note that this ARL will have
to be long-lived.

Clients retrieving the ARL from the national CA's cRLDistributionPoint
entry would find two values, and would have to deal with this, but one
of those values would be quite small, and would be ignored in most
cases, as the clients would be looking for an ARL issued by the national
CA in question.

Note that the national CA, if it uses the potential maximum size of the
RL as a criteria for deciding when to create a new cRLDistributionPoint
entry (for example, to accommodate clients with memory limitations),
would have to adjust its size criteria accordingly (memory limit -
(safety factor + sizeof("the little ARL"))).

>This would require that for the duration of this operation the top-level CA
>be given write-access to each national CA's cRLDistributionPoint entry;  once
>the operation completes, this access could be revoked; alternatively, the
>ARLs could be transferred to the national CAs in some out-of-band manner, and
>they would write them into the directory themselves, thereby avoiding any
>potential problems with opening their directory access permissions.
>
>Maybe it's not such a bad idea after all to change the meaning of 
>this extension in a way that a CA certificate really contains its OWN
>CrlDistributionPoint instead of the issuing CA's CrlDistributionPoint !
>Then this extension would be used in CA certificates only.

No, this would cause interoperability problems, grief, and churn for
those who used the cRLDistributionPoint as it was intended (I suspect
that this is a large-and-getting-larger percentage of the
V3-cert-and-V2-RL-using community).  Furthermore, it would require that
the issuer CA always have write access to the subject's
cRLDistributionPoint entry, something which may be unpopular with the
managers of the subject's directory (they may be willing to allow it for
a single operation, but probably not on an ongoing basis).

pww

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-06.txt
Date: Thu, 16 Oct 1997 12:55:58 -0400
Sender: [email-masked]
Status:

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

	Title		: Internet Public Key Infrastructure   
                          X.509 Certificate and CRL Profile
	Author(s)	: D. Solo, R. Housley, W. Ford, T. Polk
	Filename	: draft-ietf-pkix-ipki-part1-06.txt
	Pages		: 110
	Date		: 15-Oct-97
	
This is the sixth draft of the Internet Public Key Infrastructure
   X.509 Certificate and CRL Profile.  This draft is a complete
   specification.  This text includes minor modifications over the
   previous draft.  Please send comments on this document to the ietf-
   [email-masked] mail list.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki-part1-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-part1-06.txt

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get I-D ACTION-draft-ietf-pki 5 (EuSn/CSOm) (0001C441)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-part1-06.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-ipki-part1- (AURL/Arch) (0001C442)
Content-Type: text/plain
Content-ID:	<[email-masked]>

Sender: [email-masked]
Date: Thu, 16 Oct 1997 15:24:16 +0200
From: Petra Gloeckner <[email-masked]>
To: [email-masked], [email-masked]
Subject: CrlDistributionPoint extension
Status:

Hello,

we have build up (and still do) an European certification 
infrastructure ( http://www.darmstadt.gmd.de/ice-tel ). 
Now we came across a problem concerning the X.509v3 certificate 
extension CrlDistributionPoint.

Our top level CA has issued certificates to national CAs containing
the national CA's CrlDistributionPoint rather than its own 
CrlDistributionPoint. 
Well, this was not the way they were supposed to do it, at least not
the way the X.509v3 standard defines this extension. But what do we
do now ? 

If the top level CA revokes all these certificates nobody will know
that they are revoked because the respective certificates contain
the wrong CrlDistributionPoint.

Maybe it's not such a bad idea after all to change the meaning of 
this extension in a way that a CA certificate really contains its OWN
CrlDistributionPoint instead of the issuing CA's CrlDistributionPoint !
Then this extension would be used in CA certificates only.
A certificate user has to obtain the issuing CA's certificate anyhow 
to check the signature of the certificate. Now he will additionally 
retrieve the CRL specified in the CrlDistributionPoint extension of 
the CA certificate.

Any opinions ? 

Petra Gloeckner
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 9 (????/----) (0001C43F)

Date: Wed, 15 Oct 1997 21:36:52 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: Hal Lockhart <[email-masked]>
cc: Dean Povey <[email-masked]>, [email-masked]
Subject: Re: Constraints on wildcard matching in host names?
Status:

> Personally I think wildcards are extremely dangerous and create lots of
> threat scenarios.

A wildcard cert (well constructed) could only ever harm the domain that it
was limited to.  If the admins for a particular domain abuse a wildcard
cert, and it's compromised, then that cert can only ever be used to create
a non-genuine site under their domain. 

So wildcards are no more dangerous than a well-constructed certificate
chain that is properly constrained.

Now a really dangerous beast is an IP based cert, because users switch
into blind faith mode when they see an IP address in the URL, and
routing tables are not that hard to fool...

--
Mark Shuttleworth
Thawte Consulting

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: End of Last Call...
Date: Wed, 15 Oct 1997 13:34:30 -0400
Status:

All,

Well, the Working Group Last Call period has ended for PKIX-CMP.  The
only significant issue raised was that of "mandatory" versus "strongly
recommended" for proof-of-possession.  After all the votes were counted
it was clear that rough consensus was on the side of "mandatory" (with
the clarification suggested by Denis Pinkas) and so the document has
been revised to reflect this.  Other, more minor, issues raised both on
the list and privately to me (e.g., typos and requests for
clarification) have also been incorporated.

I have just submitted the revised document to the Internet-Drafts
address; it should be available at the usual repositories soon.  Once it
shows up I would ask again that all of you that submitted comments check
to ensure that they were incorporated.  The 2-week IETF-wide Last Call
period should begin soon.

Thanks to everyone for the significant interest in, and assistance with,
this specification!

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

Date: Wed, 15 Oct 1997 12:27:23 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: CRL "Not Activated" Reason Code
Status:

Recently the following operational scenario was discussed:

  1. CA issues an unsolicited certificate to an End Entity (perhaps using
     the same public key as a pre-existing certificate for that EE, or
     perhaps using a new public key, with the CA-generated private key
     sent encrypted to the EE.)

  2. The new certificate is not valid until the EE responds to the CA
     with an acceptance/confirmation message.

Even before the certificate is valid, it may be "out there" because the
CA may have published it, the EE may attempt to use it in a transaction
before activating it, or it may be intercepted in transit between the
CA and the EE.  Because activation is event-driven, the certificate
validity period cannot be used to make the cert valid only after
activation.

This requirement sounds like a valid use for the CRL reasonCode
extension with CRLReason = "certificateHold", even to those who think
there is no other justification for certificateHold (temporary
revocation) to exist at all :-).

Assuming that unsolicited issuance of certificates (or any issuance
that requires acceptance/activation by the user prior to the cert
becoming valid) is a reasonable scenario, the following questions
arise:

 * Is a "Not Yet Activated" HoldInstruction OID needed for use in the
   id-ce-InstructionCode CRL extension?

 * Have any HoldInstruction OIDs already been assigned anywhere?

 * If not, should one be assigned under PKIX?

Date: Wed, 15 Oct 1997 11:49:33 -0400
To: Dean Povey <[email-masked]>, [email-masked]
From: Hal Lockhart <[email-masked]>
Subject: Re: Constraints on wildcard matching in host names?
Status:

At 09:47 AM 10/15/97 +1000, Dean Povey wrote:
>PKIX1 allows host names as used in DNS names and email addresses in the 
>Subject and Issuer Alt Name extensions to use wildcards.
>
>While wildcards are certainly useful, I'd like to vote for some
constraints on 
>their usage being put into PKIX1.

...

>I think we should add a requirement that the host names contain a TLD
(where a 
>TLD is something like .com, .org or .edu.au) AND at least one sub-domain
which 
>does not contain patterns (ie. *.dstc.edu.au and *.ietf.org is valid, but
not 
>*dstc.edu.au, www.dstc.edu.au* or www.ietf*.org).
>
>Any thoughts?

Personally I think wildcards are extremely dangerous and create lots of
threat scenarios.  If I was a CA I would not issue certs with them.

However, it is my understanding that the stance of PKIX is that a CA can
put anything it likes in a cert, as long as it conforms to:

1. the PKIX defined syntax, and
2. the CA's published policies.

I gather the idea is: if you don't like it, get another CA.

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum Solutions Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (617)273-6406              Fax: (617)229-2969
=================================================================

Date: Tue, 14 Oct 1997 17:45:36 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
To: PKIX <[email-masked]>
Subject: Authority Information Access ASN.1
Status:

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

More apologies if this, too, has already been covered...

The ASN.1 for AuthorityInfoAccessSyntax in 4.2.2.1 is completely different
than that in Appendix B.  My guess is that the version in 4.2.2.1 is more
correct.

Still, 4.2.2.1's ASN.1 states:

	AuthorityInfoAccessSyntax  ::=  SEQUENCE OF AccessDescription

	AccessDescription  ::=  SEQUENCE SIZE (1..MAX) {
		accessMethod          OBJECT IDENTIFIER,
		accessLocation        GeneralName  }

I'm no ASN.1 guru, but shouldn't it be:

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

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

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6210x227      www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date: Tue, 14 Oct 1997 16:35:51 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
To: PKIX <[email-masked]>
Subject: Syntax of Policy Constraints in Part 1
Status:

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

My apologies if this issue has been raised already...

In 4.2.1.12 (Policy Constraints), at the bottom of page 30, the ASN.1 for
this extension includes these lines:

	CertificatePoliciesSyntax ::=
		SEQUENCE SIZE (1..MAX) OF PolicyInformation

The ASN.1 in Appendix B, however, doesn't have any such thing.  Is this
extension supposed to include a bunch of PolicyInformation structures?

In reading through the draft, I was wondering _which_ policies this
extension's requireExplicitPolicy field would refer to.  The draft says:

	An acceptable policy identifier is the identifier of a
	policy required by the user of the certification path or the
	identifier of a policy which has been declared equivalent through
	policy mapping.

This seems to indicate that the extension itself should not have anything
that identifies a policy.  I wonder, though, if that's wise.  Wouldn't it
make sense for the issuer to use the certificate to state which policies
are acceptable?  If so, a list of policy OIDs should be adequate rather
than a list of PolicyInformation structures.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6210x227      www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

From: Dean Povey <[email-masked]>
To: [email-masked]
Subject: Constraints on wildcard matching in host names?
Date: Wed, 15 Oct 97 09:47:22 +1000
Status:

PKIX1 allows host names as used in DNS names and email addresses in the 
Subject and Issuer Alt Name extensions to use wildcards.

While wildcards are certainly useful, I'd like to vote for some constraints on 
their usage being put into PKIX1.

Specifically, you should not be able to issue certs with DNS or email 
addresses containing hostnames with the following form:

*.com
*.com.au
*soft.com
www.microsoft.com*

For obvious reasons.  

I think we should add a requirement that the host names contain a TLD (where a 
TLD is something like .com, .org or .edu.au) AND at least one sub-domain which 
does not contain patterns (ie. *.dstc.edu.au and *.ietf.org is valid, but not 
*dstc.edu.au, www.dstc.edu.au* or www.ietf*.org).

Any thoughts?

-- 
+----------------------------------------+-------------------------------+
| Dean Povey,                            |  Email: [email-masked]     |
| Research Scientist, Security Unit,     |  Phone: +61 7 3864 2799       | 
| CRC for Distributed Systems Technology |  Fax:   +61 7 3864 1282       |
+----------------------------------------+-------------------------------+

Date: Tue, 14 Oct 1997 15:02:31 -0400
To: "Sheedy, E.C.C." <[email-masked]>
From: Santosh Chokhani <[email-masked]>
Subject: Re: Certificate policy
Cc: "[email-masked]'" <[email-masked]>
Status:

At 07:44 PM 10/14/97 +0100, Sheedy, E.C.C. wrote:
>Hi,
>I have yet another question concerning Part IV: Certificate Policy and
>Certification Practices Framework. 
>The link to this document is outdated and a search of the ietf site
>resulted in nothing thus i must direct
>the questions at this list, apologising in advance for any
>inconvenience. I have three questions.
>
>1. Could any of you please explain the exact meaning behind the CRL
>checking requirements. Is this merely
>    the checking of the CA signature or is there more to it.

This relates to what obligations and efforts the relying party has to check
whether a certificate is on CRL before accepting the certificate as valid.

>2. Revocation request grace period. This seems contradictory in the
>light of revocation thus could someone 
>    explain the true meaning.
>and finally

This is stating how much a subscriber can wait before notifying of need for
revocation, be it for key compromise or other reasons.

>3. How does one in act in the case of a CA key being compromised. I have
>found very little information\
>    on this and hoped someone in this group could shed some light on the
>area.

If it is a trusted CA key compromise, one has use the out of band means to
notify the subscribers of compromise.  The CA new key may have to be
communicated using trusted, out of band means, unless something akin to SET
root CA hash scheme was used and the subcribers know that the current key
was compromised after they received the current certificate.  The CA should
revoke all the certificate (although that may not be as critical since the
susbcribers will have the new key and for others the CA is in a trust chain
and hence the certificate will be revoked; but it is safer).  The CA needs
to reissue the certificates to susbcribers by signing the information with
the new key.  If the susbcriber information is also corrupted, they may have
to reregister.

I am being brief intensionly.  I hope this gives you the ideas of issues and
how to resolve them.

>
>Thanks in advance
>Colm Sheedy
>
>

-------------------------------------------------
Santosh Chokhani
CygnaCom Solutions, Inc.
Suite 100 West
7927 Jones Branch Drive
McLean, Virginia 22102-3305
(703) 848 - 0883
[email-masked]

Date: Tue, 14 Oct 1997 19:44:50 +0100
From: "Sheedy, E.C.C." <[email-masked]>
Subject: Certificate policy
To: "[email-masked]'" <[email-masked]>
Status:

Hi,
I have yet another question concerning Part IV: Certificate Policy and
Certification Practices Framework. 
The link to this document is outdated and a search of the ietf site
resulted in nothing thus i must direct
the questions at this list, apologising in advance for any
inconvenience. I have three questions.

1. Could any of you please explain the exact meaning behind the CRL
checking requirements. Is this merely
    the checking of the CA signature or is there more to it.
2. Revocation request grace period. This seems contradictory in the
light of revocation thus could someone 
    explain the true meaning.
and finally
3. How does one in act in the case of a CA key being compromised. I have
found very little information\
    on this and hoped someone in this group could shed some light on the
area.

Thanks in advance
Colm Sheedy

Date: Mon, 13 Oct 1997 10:50 -0500
From: "Simonetti David" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: SHA-1 With RSA
Status:

PKIX-1 refers to the following OID:

       sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
            iso(1) identified-organization(3) oiw(14)
            secsig(3) algorithm(2) 29  }

I can't find anything named "sha-1WithRSAEncryption".  The identifier should 
be "sha1WithRSASignature".  I am assuming that the algorithm number is 
correct.

Please let me know if this is not the case.

Dave Simonetti

Reply-To: "Peter Williams" <[email-masked]>
From: "Peter Williams" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: Last Call (CMP proof-of-possession)
Date: Fri, 10 Oct 1997 09:17:39 -0700
Status:

 >> Whether the language says "required with Denis' qualifications",
>> or "strongly recommended", I could not care. The net
>> effect is the same.
>
>The net effect is quite different; it's the difference between saying:
>
> "the PKI (CAs and/or RAs) must do PoP in some manner before a certificate
>  can be considered valid", and
>
> "the PKI really ought to do PoP, but doesn't absolutely have to if it's
>  inconvenient for a particular business scenario"

So its understood that the decision to adopt your resolution will
affect the scope of applicability of PKIX, and the class of
certificate-based
key management applications which can claim to conform to, or
therefore commercially use, our IETF work.

The affect will be to ban commercial reliance, as used in practice
currently, on
operational protocols (versus management protocols) and second parties
ensuring POP. (recall, more generically, POP represents the primary
responsiblity
for the decision to remotely activate a key/card/token, once physically
issued)

In order to use an IETF key management standard in a conformant manner
all operational protocols must cede control over the usage of keying
material
by end-entities to a trusted third party management system. Cert
issuing or validity becomes an mandatory enforcement tool, not a
authentication
reliability measure.

I really do not like where this may be leading...I do not wish to
be alarmist, but this looks like the Royal Holloway concept
of operations for TTPs; conformance conditions causing
centralised, highly regulated use of crypto keys, etc. to be
required in the base software.

There are perfectly legitimate scenarios where centralised
and even online control policies via crypto-enforcement are to mandatory
for mere use of keys, or reliance on certificates/signature etc.
I fail to see why al IETF apps should be **forced** to design operational
systems in this mandatory controlling mould, or cede operational
control of security at any phase to third party management systems.

. Why is IETF (!) seeking to make TTPs enforcement
agents, versus merely set standards for CA-based authentication, onem ight
ask?

I now see that the move to impose POP on CAs/RAs may well be motivated
to force remove from EE the option to use of keys regardless
of a CA's involvement or mandatory policy.
David,

David, is this campaign to move strongly recommended POP (which is
nominally about authentication quality)  really about key escrow, or
creating
a mandatory control system governing the use of crypto mechanisms by EE's?

Alternaitvely, could PKIX, when conformatntly implmented, be a
 mechanism be used to institute  Royal Holloway?

Peter.

Date: Fri, 10 Oct 1997 09:10:38 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

I wrote:

>  IETF procedure requires Working Group Last Calls to
>last for a finite period of time, generally four weeks.

Spelling correction:  the digit 2 (as in "2 week last call") should be
spelled "t-w-o", not "f-o-u-r".

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

> From: "Peter Williams" <[email-masked]>
> 
> [1] Nothing in PKIX should mandate a mechanism for POP that **all** conforming
> PKIX3.CAs must implement and all operators must deploy and respond
> to if the appropriate packet happened to arrive. Of course, by
> one means of another, a useful CA supporting dig sigs will do it on the
> whole.

> [2] Some
> circumstances may well mean that POP is not a pre-condition
> to the issuance or validity of a cert, and its delivery to, or use by,
> the user process, however. The demonstation of POP to a third-party
> will often be a pre-condition for any possible reliance on dig sigs, one
> notes.

I'm glad we are making progress toward reaching agreement, and enabling
the intent of PKIX to become clear enough solely by reference to the
text of the documents that no misinterpretation is possible.

My intent (although my wording could surely be improved) is that your
situation [1] above is allowed, while situation [2] is forbidden.

> Whether the language says "required with Denis' qualifications",
> or "strongly recommended", I could not care. The net
> effect is the same.

The net effect is quite different; it's the difference between saying:

 "the PKI (CAs and/or RAs) must do PoP in some manner before a certificate
  can be considered valid", and

 "the PKI really ought to do PoP, but doesn't absolutely have to if it's
  inconvenient for a particular business scenario"

> Policy-independent PKI technology is our goal, recall.

Quite right!

Comments: Authenticated sender is <[email-masked]>
From: Nick Pope <[email-masked]>
To: Carlisle Adams <[email-masked]>
Date: Fri, 10 Oct 1997 11:51:44 +0000
Subject: RE: GenAnnContent and GenConfContent
CC: "'IETF-PXIX'" <[email-masked]>
Priority: normal
Status:

Carlisle 

In reply to your message of  8 Oct 97, 14:23:

We can get by with using GenMsgContent and GenRepContent as you 
propose.

I would however, request that you add text to clarifying 
that both these messages may pass in either direction between the End 
Entity and the CA / RA.

Also, I would suggest that these are encoded as:
  SEQUENCE OF InfoTypeAndValue
rather than SET OF as this avoids an implemementation possibly having 
to re-order the data to comply with DER which requires the elements to 
be placed in ascending order after being encoded.

Nick
> >
> >I am working with a user client on the design of a key management system
> >which extends PKIX to meet additional functional requirements.
> >
> >The recent inclusion of GenReqContent and GenRepContent in the protocol
> >make it possible to cleanly extend the protocol without danger of
> >conflict with future versions or other extensions to PKIX.
> >
> >However, the additional functions to be supported by our key management
> >system also require the capability to carry additional types of Announce
> >messages, as well as Confirm messages with parameters.
> >
> >It is it possible to include a GenAnnContent and GenConfContent to
> >PKIX-3 before it becomes an RFC?
> >
> >Otherwise we may have to resort to using GenReqContent and GenRepContent
> >to carry the Announce and Confirm messages and leaving it to the poor
> >supplier to handle requests that may go in either direction.
> 
> My intention (after consulting with those who originally requested
> this extensibility) is to change the name "GenReqContent" to
> "GenMsgContent".
>  This removes the connotation of a "request" and allows arbitrary
> general messages (hopefully having something to do with certificate
> management!) to be sent, so your Announce messages should fit in here
> perfectly well.
> 
> "GenRepContent" (no name change) is meant to be used for a response to
> a GenMsgContent, wherever this is required.  Therefore, I think that
> your GenConfContent (which I assume carries more than the PKIConfirm
> message, otherwise why not use that?) could fit in here.
> 
> The bottom line is that with the name change I don't think we need to
> add GenAnnContent and GenConfContent.  Let me know if you disagree.
> 
> 
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> [email-masked]
> --------------------------------------------
> 
> 

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

Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.

Tel: +44 1245 495018
Fax: +44 1245 494517

From: "Arsenault, Al W." <[email-masked]>
To: "'Arsenault, Al W.'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Subject: RE: Last Call (CMP proof-of-possession)
Date: Fri, 10 Oct 1997 06:37:01 -0400
Status:

Okay, as usual, the following are *personal opinions* only.

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Thursday, October 09, 1997 3:22 PM
>To: 	Arsenault, Al W.; [email-masked]
>Subject: 	Re: Last Call (CMP proof-of-possession)
>
>Here is the situation Id like PKIX-CMP to allow. Tell us perhaps
>if PKIX-CMP allows or disallows the scenario. My reading is that
>IETF is about to prevent conforming PKIX-CMP systems engaging in this
>issuing policy and scenario, by requiring the CA (B below)  to check PoP:-
>
>There are two CAs, A and B.
>
>A issues Peter a valid certificate, placing it in its repository. (Peter
>physically visits A's LRA to do PoP, as a pre-condition in A's policy)
>
>B may or may not have an agreement with A to offer commercial added-value
>to A's subscribers, as an option to them: extended warranties, offers of
>free things,
>customer support folk who speak Korean...not only English, etc.
>
>B access A's repository and resigns the cert etc, and sends it
>(via signed PKIX-CMP Cert messages) to Peter. Lets say Peter
>agreed to a "reasonable amount" of such solicitations, when subscribing
>to A.
>
>Peter acknowledges the "added-value" of the cert issuer B, and accepts
>the cert, replacing that of A for use in his favorite email client. Perhaps
>Peter pays
>some more money and also offers more authentication evidence under B's
>requirements
>for id confirmation.
>
>B notes Peter's accepting event and publishes the cert in B's repository.
>
>A maintains the original cert until it expires. Perhaps A and B share
>the money paid to B, or the legal obligations. Perhaps not.
>
>------
>
>Now, my reading of PKIX-3 (which I have read very carefully indeed) was
>that such a scenario is entirely within the applicability of its messeging
>protocol.
>My belief is that by requiring PoP in the manner being suggested,
>this scenario (particularly when A and B have no relationship) built
>using PKIX-3 CMP messages and using the operations described is no
>longer supported.

In my opinion, there are at least three cases:

(1) A and B have an agreement in which A agrees to act as an RA for B.

I believe this meets all the necessary requirements.  PoP was done (I'll
presume) by A before it issued the initial certificate.  Acting as an
RA, A vouches for this PoP to B.  PoP has been done.

(2) A and B do not have an RA agreement, but B's "acceptance" procedure
requires that PoP be done before B's certificate can be used.

This is also okay.  The certificate issued by B to Peter is not usable
until such time as PoP has been done by B.  Notwithstanding my own
personal views on "unsolicited business offer", this is still something
PKIX should allow.

(3) A and B do not have an RA agreement, and B's "acceptance" procedure
does not require PoP before Peter can use the cert issued by B.

This should not be supported.  B is supposed to be a "certification
authority", yet B is actually purporting to certify something about
which he knows nothing.  He does not have any reason to believe that the
public key he put in the certificate is actually Peter's public key -
and A will not likely defend B should the question go to court, since
there's no agreement.  

As the recipient of a message sent by Peter using the certificate from
B, quite frankly I'd like to know that there was no basis whatsoever for
B to have "certified" anything, so that I can properly reject the
transaction out of hand.

>> Al Arsenault
>>
>> - I speak only for myself; my opinions do not necessarily represent
>>those of my employer
>>>
>>>
>>
>
>

Date: Thu, 9 Oct 1997 19:33:59 -0400 (EDT)
From: [email-masked] (Bede McCall)
To: [email-masked]
Subject: RE: RE: Last Call (CMP proof-of-possession)
Status:

   From: "Arsenault, Al W." <[email-masked]>
   Subject: RE: RE: Last Call (CMP proof-of-possession)
   Date: Thu, 9 Oct 1997 15:18:07 -0400

   [ . . . ]                       I don't think that the user needs to
   request that the certificate be reissued.  I don't request my credit
   card issuers to send me new cards when the old ones expire; they simply
   send them.  I see no reason to change that model.  Again, I believe that
   the CA or RA must have revalidated the user's information, but I don't
   see a need for an explicit PoP action.    [ . . . ]

Credit card companies do perform a revalidation for their cards when
they're reissued --- merely having possession of the new card or even
forging a signature on the back isn't enough to make it usable.  Most
cards can't be used until you call the company and revalidate yourself
(mother's maiden name, zip code, date-of-birth, PIN, etc.).  In some
cases, PoP of the card itself figures in, as with debit cards where
the first successful use at an ATM is "validation".

-- 
  Bede McCall   <[email-masked]>
  The MITRE Corporation                    Tel: (617) 271-2839
  202 Burlington Road,  M/S K321           FAX: (617) 271-2423
  Bedford, Massachusetts  01730-1420

Date: Thu, 9 Oct 1997 19:04:27 -0400 (EDT)
From: [email-masked] (Bede McCall)
To: [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

   From: "Peter Williams" <[email-masked]>
   Date: Thu, 9 Oct 1997 11:01:25 -0700

   [ . . . ]           These mail exchanges indicate the intended
   ambiguous meaning of the text, for future reference. Its understood
   here that policy statement will fill in the gaps,    [ . . . ]

I have a quibble with this, Peter:  these email exchanges are very
unlikely to carry much weight as future reference WRT the "real" intent
behind the text.  If we're intentionally embedding an ambiguity in the
spec or deferring to a policy which is being left up to the implementor
or an end user, this fact should in some way be made explicit.

-- 
  Bede McCall   <[email-masked]>
  The MITRE Corporation                    Tel: (617) 271-2839
  202 Burlington Road,  M/S K321           FAX: (617) 271-2423
  Bedford, Massachusetts  01730-1420

From: "Arsenault, Al W." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>
Subject: RE: RE: Last Call (CMP proof-of-possession)
Date: Thu, 9 Oct 1997 15:18:07 -0400
Status:

Bob Jueneman wrote:
>>These two arguments taken together lead me to believe that certificates
>>should have a sunset clause associated with them, i.e., a finite lifetime,
>>and that a new certificate should be issued and affirmatively accepted by
>>the subscriber at the end of that period.
>
>>Granted, that does not conclusively say that a new certificate should >never
contain the same public key that was contained in the old one, but >the
fact (as Denis pointed out) that a digital signature in general does
>>not >bind a
>>particular certificate to the signature, but only a particular key, means
>>that it may be very difficult to determine which certificate was supposed to
>>be used to validate a given signature, and/or to know what set of identity
>>or other attributes were supposed to be claimed.
>
>>Unless the CA has independently reconfirmed the validity of all of the
>>information in the certificate, and obtained the subscriber's consent to and
>>acceptance of the new certificate, I think this is a potentially dangerous
>>practice.

We agree completely, Bob.  But remember that:

	1 - quite often keys will be longer-lived than will certificates.  One
reason for making certificates have somewhat short lifetimes is the
recognition that in today's society, items in the certificate may have a
short half-life, particularly if they include things like an
rfc822address or similar.  The CA can't possibly be expected in the real
world to keep track of all users' name changes, address changes,
privilege changes, e-mail address changes, etc.  So, you make the
certificates expire periodically. If something about the user has
changed without the CA's knowledge, then the cert will expire and the CA
will not issue a new one without either the CA or RA  having validated
all of the information again.  Keys, on the other hand, have lifetimes
relating to other properties.  So, I would expect that in many cases we
will issue new certificates with the same-old-public-key.

	2 - an underlying assumption of my earlier message - which I probably
should have been explicit about - was that it takes some positive action
on the part of the CA and/or the RA to recertify the user's information
prior to issuance of the renewed cert.

>>
>>If the user's private keys are stored on a hardware token, I as the CA
>>would like to create a certificate and send it to the user in a
>>CertRepContent message.  (I don't want her to have to physically bring
>>her token back to me - that's an inconvenience for which many users will
>>not stand.)  This would not have been preceded by a CertReqContent
>>message - I don't want the user to have to take any positive action to
>>get a renewed certificate, I just want it to show up.  
>
>Is your assumption that (1) the certificate has to be stored on the token? 
>Is that in fact a common or current practice? And (2), are you assuming that
>the user would have to physically present herself to some central point in
>order to have the certificate loaded onto her token -- in other words the
>device which normally reads the token could not also load it with a
>certificate?

(1) it is likely stored on the token; it may also be cached on the
workstation for performance reasons.  It doesn't matter to me.  (2) no,
generally I assume that the user can put her own cert on her own token.
Thus, the reason for just having the CA send the CertRepContent message.
 The user can receive and process the message, and write it wherever she
needs it.

>>I agree that having to physically return (or return with) the token would be
>>a considerable inconvenience, but it isn't yet clear to me that such as
>>>step
>>would be necessary.
>
>>As far as the user not having to take any positive step to get a renewed
>>certificate, I tend to disagree on a policy basis.  For her own protection,
>>the user needs to request that the certificate be reissued, and for the
>>protection of any relying parties the POP needs to be reconfirmed.

This is where we may disagree.  I don't think that the user needs to
request that the certificate be reissued.  I don't request my credit
card issuers to send me new cards when the old ones expire; they simply
send them.  I see no reason to change that model.  Again, I believe that
the CA or RA must have revalidated the user's information, but I don't
see a need for an explicit PoP action.

>>
>>>Question:  given that this is a case where "Certificate Management
>Protocol
>>messages are used to issue certificates", how do I do PoP?  Is the
>>alternative to say that I cannot do something like this - the new cert
>>can ONLY be issued if the user first sends a CertReqContent?
>>Personally, I don't like that - it's an unnecessary inconvenience on the
>>user, and it doesn't really buy any extra security.  (I know that the
>>user originally had the right private key, and I'm already confident
>>that she still has it, or I wouldn't have made the conscious choice to
>>issue her a renewed certificate.)
>
>In other words, outside of a strictly controlled regime (and maybe even the
>military might not count), I have serious reservations as to the ability of
>the CA to really know what is going on, to the point of being able to issue
>a new certificate without any prompting or approval. That smacks me as being
>a bit too hierarchical and authoritarian for most applications.

Subject to an acceptable level of risk, as defined in a CPS, I don't
think that it's  necessary for the CA to know exactly what's going on.
Even in the military the CA doesn't know that much about his users -
quite often, he knows less. The point is that the "prompting and
approval" is being done by mechanisms external to PKIX -CMP.

>And rather than continuing to use the old key for an extended period of
>time, good key hygiene would suggest that it be replaced periodically to
>minimize the risk (as of course you know, having often been responsible for
>writing such policies!)
>
>So I would much prefer a scenario where the token has the ability to
>securely generate a new public/private key on the token, sign the new
>prototype certificate with the new key, and then countersign that
>certificate reissue request using the old private key, to confirm that the
>same person who physically possessed the old key is now in control of the
>new one.

We can do that, too.  Some users like this locally-generated key stuff
better; some like the centrally generated stuff.  I just want to make
sure that both are supported in PKIX, so that I can force certain
commercial folks to move to PKIX-conformant stuff.

		Al Arsenault

>- I speak only for myself; my opinions do not necessarily represent
>those of my employer
>
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                      
>

From: "Arsenault, Al W." <[email-masked]>
To: "'Simonetti David'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Peter Williams'" <[email-masked]>
Subject: RE: Last Call (CMP proof-of-possession)
Date: Thu, 9 Oct 1997 15:30:13 -0400
Status:

Peter Williams wrote:

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Thursday, October 09, 1997 2:01 PM
>To: 	Simonetti David; [email-masked]
>Subject: 	Re: Last Call (CMP proof-of-possession)
>
>At least some in the MISSI world have some commercial sense
>and sensibility. 

That's nice.  Who?

<snip>
>
>I understand that RA-POP may not be how MISSI intends
>to deploy itself in the environments for which
>it  designs its key management systems, but that aint our concern in
>this trans-national group. 

Actually, it's a major part of our deployment strategy.  But you're
right, it shouldn't be a major part of PKIX - just one input.

>So long as MISSI can do what it wants/needs
>with the conforming products,  without imposing its management culture or
>operational policy on the rest of the world, this is a nice outcome.

I agree completely.  When I put on my college-professor hat, I just want
PKIX to include the "right stuff" - a minimally-acceptable set of
features that provides adequate security and interoperation among
various CA-related products, in support of a wide variety of security
policies, desired qualities of service, etc.  When I put on my MISSI
hat, I just want to ensure that reasonable design decisions we made
based on operational experience are factored in.  I want MISSI solutions
to be PKIX-compliant, not the least because I want to get out of the
"MISSI solution" business and into using PKIX-compliant stuff.  So far,
it looks pretty good.  As you note, this is a nice outcome.

>Policy-independent PKI technology is our goal, recall.
>

And mine!

		Al Arsenault

- I speak only for myself; my opinions do not necessarily represent
those of my employer

Reply-To: "Peter Williams" <[email-masked]>
From: "Peter Williams" <[email-masked]>
To: "Arsenault, Al W." <[email-masked]>, <[email-masked]>
Subject: Re: Last Call (CMP proof-of-possession)
Date: Thu, 9 Oct 1997 12:22:57 -0700
Status:

Here is the situation Id like PKIX-CMP to allow. Tell us perhaps
if PKIX-CMP allows or disallows the scenario. My reading is that
IETF is about to prevent conforming PKIX-CMP systems engaging in this
issuing policy and scenario, by requiring the CA (B below)  to check PoP:-

There are two CAs, A and B.

A issues Peter a valid certificate, placing it in its repository. (Peter
physically visits A's LRA to do PoP, as a pre-condition in A's policy)

B may or may not have an agreement with A to offer commercial added-value
to A's subscribers, as an option to them: extended warranties, offers of
free things,
customer support folk who speak Korean...not only English, etc.

B access A's repository and resigns the cert etc, and sends it
(via signed PKIX-CMP Cert messages) to Peter. Lets say Peter
agreed to a "reasonable amount" of such solicitations, when subscribing
to A.

Peter acknowledges the "added-value" of the cert issuer B, and accepts
the cert, replacing that of A for use in his favorite email client. Perhaps
Peter pays
some more money and also offers more authentication evidence under B's
requirements
for id confirmation.

B notes Peter's accepting event and publishes the cert in B's repository.

A maintains the original cert until it expires. Perhaps A and B share
the money paid to B, or the legal obligations. Perhaps not.

------

Now, my reading of PKIX-3 (which I have read very carefully indeed) was
that such a scenario is entirely within the applicability of its messeging
protocol.
My belief is that by requiring PoP in the manner being suggested,
this scenario (particularly when A and B have no relationship) built
using PKIX-3 CMP messages and using the operations described is no
longer supported.

Recall that this is a sketch to test PKIX-3 conformance design, and its
policy independence - not a complete specification of the scenario. I
recognise
this is not what centralised or DMS-type military key management systems
have
done over the last 5-10 years. It is a very real deployment scenario,
however.

Peter.

-------

-----Original Message-----
From: Arsenault, Al W. <[email-masked]>
To: [email-masked]' <[email-masked]>; [email-masked]'
<[email-masked]>
Date: Thursday, October 09, 1997 9:01 AM
Subject: RE: Last Call (CMP proof-of-possession)

>Dave, et alia:
>
>I agree with the thought, but I think that your wording below needs to
>be clarified somewhat:
>
>>
>>>To clarify the questions raised by the straw poll respondents, here
>>>is a restatement of the question:
>>
>> >"If Certificate Management Protocol messages are used to issue
>> >certificates, then Proof-of-Possession is REQUIRED to be demonstrated
>> >by the sender and checked by the recipient of those messages."
>
>
>Here's a scenario I want to support.  A user is issued a certificate
>valid for a finite period - let's say one year for argument's sake.  At
>the conclusion of one year, I as a CA want to "renew" that certificate.
>That is, I as the CA decide that all information in that certificate is
>still valid, the public/private keys can still be used, etc.  All I want
>to do is issue a new certificate, with a new certificate serial number
>and new validity period (and signature value of course :-),  and
>everything else the same.
>
>If the user's private keys are stored on a hardware token, I as the CA
>would like to create a certificate and send it to the user in a
>CertRepContent message.  (I don't want her to have to physically bring
>her token back to me - that's an inconvenience for which many users will
>not stand.)  This would not have been preceded by a CertReqContent
>message - I don't want the user to have to take any positive action to
>get a renewed certificate, I just want it to show up.
>
>>Question:  given that this is a case where "Certificate Management
Protocol
>messages are used to issue certificates", how do I do PoP?  Is the
>alternative to say that I cannot do something like this - the new cert
>can ONLY be issued if the user first sends a CertReqContent?
>Personally, I don't like that - it's an unnecessary inconvenience on the
>user, and it doesn't really buy any extra security.  (I know that the
>user originally had the right private key, and I'm already confident
>that she still has it, or I wouldn't have made the conscious choice to
>issue her a renewed certificate.)
>
>Based on that, an alternative suggestion for the wording is something
>along the lines of:
>
> "If certificates are issued in CMP response messages sent in response
>>to CMP request messages that contain public keys, then then
>>Proof-of-Possession is REQUIRED to be demonstrated by the end-entity and
>checked by the CA."
>
>where CMP request messages are taken to include InitReqContent,
>CertReqContent, CertificationRequest, KeyUpdReqContent, and
>CrossCertReqContent; and CMP response messages includes the response
>messages corresponding to these.
>
>This seems to me to require PoP in instances where a bunch of (but maybe
>not all :-) IETF technologists think it's needed (i.e., when the user is
>presenting a locally-generated key and asking that it be put into a
>certificate), while allowing people providing PoP through other (e.g.,
>physical means) to avoid unnecessary work.
>
>Thoughts?
>
> Al Arsenault
>
> - I speak only for myself; my opinions do not necessarily represent
>those of my employer
>>
>>
>

Reply-To: "Peter Williams" <[email-masked]>
From: "Peter Williams" <[email-masked]>
To: "Simonetti David" <[email-masked]>, <[email-masked]>
Subject: Re: Last Call (CMP proof-of-possession)
Date: Thu, 9 Oct 1997 11:01:25 -0700
Status:

At least some in the MISSI world have some commercial sense
and sensibility. I too agree with Denis, if it was not obvious in my
message. But
lets be clear, how and where and under what policy POP occurs is
not standardized, or mandated through IETF-agreed
conformance presciptions.

Nothing in PKIX should mandate a mechanism for POP that **all** conforming
PKIX3.CAs must implement and all operators must deploy and respond
to if the appropriate packet happened to arrive. Of course, by
one means of another, a useful CA supporting dig sigs will do it on the
whole. Some
circumstances may well mean that POP is not a pre-condition
to the issuance or validity of a cert, and its delivery to, or use by,
the user process, however. The demonstation of POP to a third-party
will often be a pre-condition for any possible reliance on dig sigs, one
notes.

Whether the language says "required with Denis' qualifications",
or "strongly recommended", I could not care. The net
effect is the same. These mail exchanges indicate the intended
ambiguous meaning of the text, for future reference. Its understood
here that policy statement will fill in the gaps, and that considerable
variation may occur in mechanism, strength and location of POP validation.

One might reassert that in the PKIX3 architecture, POP
may be established by the RA, not the CA. The language
must not force **CAs** to perform the check, as the original
argument established. RAs may well have full
delegated authority to perform this check, and indeed
only they may the means to verify/record the fact at the (policy-specific)
strength and assurance.

I understand that RA-POP may not be how MISSI intends
to deploy itself in the environments for which
it  designs its key management systems, but that aint our concern in
this trans-national group. So long as MISSI can do what it wants/needs
with the conforming products,  without imposing its management culture or
operational policy on the rest of the world, this is a nice outcome.

Policy-independent PKI technology is our goal, recall.

-----Original Message-----
From: Simonetti David <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: Thursday, October 09, 1997 9:39 AM
Subject: Re: Last Call (CMP proof-of-possession)

>Most of the specifications I've reviewed or contributed to seem to cross
>that fine line into policy territory.  So why should this specification be
>any different?
>
>The notion of POP is important enough that it should be a requirement
>captured somewhere, be it in a specification or policy statement.  Given
>Denis' proposed restatement which allows unlimited latitude on *how* to
>verify POP (where "how" is specified in a policy statement!), you can count
>me as a vote for "REQUIRED".
>
>Dave Simonetti
> ----------
>From: David P. Kemp
>To: ietf-pkix
>Subject: Re: Last Call (CMP proof-of-possession)
>Date: Thursday, October 09, 1997 11:36AM
>
>> From: "Peter Williams" <[email-masked]>
>>
>> I judge things at 4 = 4 actually. One can throw in the authors
>> and bias the count, I suppose. But perhaps that is not fair
>> as they represented the comments and concensus, not their own
>> opinions.
>>
>> But this posturing is purile. The material arguments were made last time
>> we debated this issue and came to a concensus represented
>> by the next several versions of the draft.
>
>
>Achieving "rough consensus" is puerile?  Following IETF procedure for
>working group Last Call is improper?
>
>The concensus that was reached was that the PKIX documents were dragging
>on for far too long in Internet Draft stage.  I was present at the meeting
>where the change was made, and I believe that the document editor will
>confirm that the RECOMMENDED wording was inserted not because consensus
>was achieved on the merits, but out of a desire to avoid a fillibuster
>by a small number of individuals.
>
>
>By my count, the Last Call tally is:
>
>REQUIRED      RECOMMENDED    Unknown
> --------      -----------    ----------
>Kemp          Williams       Shuttleworth
>Beattie       Povey          Simonetti
>Lockhart      mfSmith        mfSmith (req'd for initial, rec'd for reissue)
>Parker                       Warner (not strongly opposed to required PoP)
>Housley
>Jueneman
>Lowry
>Pinkas (qualified "by other means")
>Arsenault
>
>
>That's a pretty solid consensus, and that doesn't include those who
>might be expected to strengthen it further.  Counting the document
>editor(s) is "biasing" the vote???  The duty of an editor is to reflect
>WG decisions in the document, but should that invalidate the editors'
>rights to participate in those decisions by expressing their own opinions?
>
>
>> What **new** issue is there to discuss which was
>> not discussed last time, which would give
>> a valid rationale for a change in the document back
>> to the previous position?
>
>The issue is that IETF procedure requires Working Group Last Calls to
>last for a finite period of time, generally four weeks.  After that period,
>a decision is reached one way or another.  With "rough consensus" or
better,
>the document will reflect that consensus.  If opinion is "halved" (to
>use Ryder Cup terminology), the status quo is preserved.
>
> -----------------------------
>
>
>We are all agreed that policy issues are properly addressed in
>individual CAs' Certification Practice Statements, as framed
>by Part 4.
>
>But most people (as counted above) believe that Proof of Possession is
>not a policy issue, it is a fundamental component of any meaningful
>Public Key Infrastructure.  You might as well argue that the use of
>digital signatures on certificates is a policy issue - that CAs should
>be free to set their own policy on whether certs are signed, as long
>as that policy is described in the CPS.
>
>To clarify the questions raised by the straw poll respondents, here
>is a restatement of the question:
>
> "If Certificate Management Protocol messages are used to issue
> certificates, then Proof-of-Possession is REQUIRED to be demonstrated
> by the sender and checked by the recipient of those messages."
>
>
>This acknowledges that PKI management functions will often be accomplished
>by means other than CMP messages, such as other protocols, out-of-band
>procedures, or physical delivery of tokens.  In these non-CMP scenarios,
>the procedures followed by the CA, including assurance "by other means"
>that the certified end entity can use the private key, should be
>documented in the CPS.
>
>But in scenarios where CMP messages are used, the CPS can be simplified
>by claiming that Proof of Possession is demonstrated "in accordance with
>the Certificate Management Protocol", augmented with a description
>of the scheme ("centralized", "basic authenticated", other)
>and the algorithms used.
>
>I'll repeat the question that Peter dodged:  does making PoP REQUIRED
>in the case where CMP messages are used negatively impact any usage
>scenarios?
>
>The only negative consequence brought up so far was Michael Warner's
>granting of power of attorney, in which he said requiring PoP would
>"make some things a little more inconvenient".  Others thought that
>this usage (intentionally issuing certs to non-keyholders) was a
>Bad Idea.
>

Date: Thu, 09 Oct 1997 10:57:50 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: RE: Last Call (CMP proof-of-possession)
Status:

>Here's a scenario I want to support.  A user is issued a certificate
>valid for a finite period - let's say one year for argument's sake.  At
>the conclusion of one year, I as a CA want to "renew" that certificate.
>That is, I as the CA decide that all information in that certificate is
>still valid, the public/private keys can still be used, etc.  All I want
>to do is issue a new certificate, with a new certificate serial number
>and new validity period (and signature value of course :-),  and
>everything else the same.

Al, your suggested scenario makes me somewhat uncomfortable, but at a soft
level of discomfort, one which I would accept could validly be handled as a
matter of policy, and not a fundamental technology issue. In particular, I
can see that in certain environments, especially in the military, sufficient
external controls would exist to mitigate some of my concerns.  

Nonetheless, I'll discuss my legal/policy concerns in the more general
commercial environment.

Generally speaking, a CA's duty and obligation to accurately report the
facts that are relevant to the binding of a user's identity and his public
key terminate at the instant that the certificate is issued. That is, a CA
is not generally viewed as having an enduring responsibility for providing
continuing awareness of the subject's status with respect to change of
address, change of association, change of name, or even death. (some CAs
might take on more responsibility in these regards as a value-added
function, but this is probably not going to be the norm.)

Likewise, the prevailing legal view is that the subscriber (subject) has a
positive duty to correct affirmative misrepresentations, ambiguities,
vagueness resulting in error, and omissions that are misleading. But
liability of the subscriber to the CA for any misrepresentations attaches at
the time the subscriber accepts the certificate.

These two arguments taken together lead me to believe that certificates
should have a sunset clause associated with them, i.e., a finite lifetime,
and that a new certificate should be issued and affirmatively accepted by
the subscriber at the end of that period.

Granted, that does not conclusively say that a new certificate should never
contain the same public key that was contained in the old one, but the fact
(as Denis pointed out) that a digital signature in general does not bind a
particular certificate to the signature, but only a particular key, means
that it may be very difficult to determine which certificate was supposed to
be used to validate a given signature, and/or to know what set of identity
or other attributes were supposed to be claimed.

Unless the CA has independently reconfirmed the validity of all of the
information in the certificate, and obtained the subscriber's consent to and
acceptance of the new certificate, I think this is a potentially dangerous
practice.
>
>If the user's private keys are stored on a hardware token, I as the CA
>would like to create a certificate and send it to the user in a
>CertRepContent message.  (I don't want her to have to physically bring
>her token back to me - that's an inconvenience for which many users will
>not stand.)  This would not have been preceded by a CertReqContent
>message - I don't want the user to have to take any positive action to
>get a renewed certificate, I just want it to show up.  

Is your assumption that (1) the certificate has to be stored on the token? 
Is that in fact a common or current practice? And (2), are you assuming that
the user would have to physically present herself to some central point in
order to have the certificate loaded onto her token -- in other words the
device which normally reads the token could not also load it with a
certificate?

I agree that having to physically return (or return with) the token would be
a considerable inconvenience, but it isn't yet clear to me that such as step
would be necessary.

As far as the user not having to take any positive step to get a renewed
certificate, I tend to disagree on a policy basis.  For her own protection,
the user needs to request that the certificate be reissued, and for the
protection of any relying parties the POP needs to be reconfirmed.
>
>>Question:  given that this is a case where "Certificate Management
Protocol
>messages are used to issue certificates", how do I do PoP?  Is the
>alternative to say that I cannot do something like this - the new cert
>can ONLY be issued if the user first sends a CertReqContent?
>Personally, I don't like that - it's an unnecessary inconvenience on the
>user, and it doesn't really buy any extra security.  (I know that the
>user originally had the right private key, and I'm already confident
>that she still has it, or I wouldn't have made the conscious choice to
>issue her a renewed certificate.)

In other words, outside of a strictly controlled regime (and maybe even the
military might not count), I have serious reservations as to the ability of
the CA to really know what is going on, to the point of being able to issue
a new certificate without any prompting or approval. That smacks me as being
a bit too hierarchical and authoritarian for most applications.

And rather than continuing to use the old key for an extended period of
time, good key hygiene would suggest that it be replaced periodically to
minimize the risk (as of course you know, having often been responsible for
writing such policies!)

So I would much prefer a scenario where the token has the ability to
securely generate a new public/private key on the token, sign the new
prototype certificate with the new key, and then countersign that
certificate reissue request using the old private key, to confirm that the
same person who physically possessed the old key is now in control of the
new one.

Your thoughts?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Thu, 09 Oct 1997 12:27
From: "Simonetti David" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

Most of the specifications I've reviewed or contributed to seem to cross 
that fine line into policy territory.  So why should this specification be 
any different?

The notion of POP is important enough that it should be a requirement 
captured somewhere, be it in a specification or policy statement.  Given 
Denis' proposed restatement which allows unlimited latitude on *how* to 
verify POP (where "how" is specified in a policy statement!), you can count 
me as a vote for "REQUIRED".

Dave Simonetti
 ----------
From: David P. Kemp
To: ietf-pkix
Subject: Re: Last Call (CMP proof-of-possession)
Date: Thursday, October 09, 1997 11:36AM

> From: "Peter Williams" <[email-masked]>
>
> I judge things at 4 = 4 actually. One can throw in the authors
> and bias the count, I suppose. But perhaps that is not fair
> as they represented the comments and concensus, not their own
> opinions.
>
> But this posturing is purile. The material arguments were made last time
> we debated this issue and came to a concensus represented
> by the next several versions of the draft.

Achieving "rough consensus" is puerile?  Following IETF procedure for
working group Last Call is improper?

The concensus that was reached was that the PKIX documents were dragging
on for far too long in Internet Draft stage.  I was present at the meeting
where the change was made, and I believe that the document editor will
confirm that the RECOMMENDED wording was inserted not because consensus
was achieved on the merits, but out of a desire to avoid a fillibuster
by a small number of individuals.

By my count, the Last Call tally is:

REQUIRED      RECOMMENDED    Unknown
 --------      -----------    ----------
Kemp          Williams       Shuttleworth
Beattie       Povey          Simonetti
Lockhart      mfSmith        mfSmith (req'd for initial, rec'd for reissue)
Parker                       Warner (not strongly opposed to required PoP)
Housley
Jueneman
Lowry
Pinkas (qualified "by other means")
Arsenault

That's a pretty solid consensus, and that doesn't include those who
might be expected to strengthen it further.  Counting the document
editor(s) is "biasing" the vote???  The duty of an editor is to reflect
WG decisions in the document, but should that invalidate the editors'
rights to participate in those decisions by expressing their own opinions?

> What **new** issue is there to discuss which was
> not discussed last time, which would give
> a valid rationale for a change in the document back
> to the previous position?

The issue is that IETF procedure requires Working Group Last Calls to
last for a finite period of time, generally four weeks.  After that period,
a decision is reached one way or another.  With "rough consensus" or better,
the document will reflect that consensus.  If opinion is "halved" (to
use Ryder Cup terminology), the status quo is preserved.

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

We are all agreed that policy issues are properly addressed in
individual CAs' Certification Practice Statements, as framed
by Part 4.

But most people (as counted above) believe that Proof of Possession is
not a policy issue, it is a fundamental component of any meaningful
Public Key Infrastructure.  You might as well argue that the use of
digital signatures on certificates is a policy issue - that CAs should
be free to set their own policy on whether certs are signed, as long
as that policy is described in the CPS.

To clarify the questions raised by the straw poll respondents, here
is a restatement of the question:

 "If Certificate Management Protocol messages are used to issue
 certificates, then Proof-of-Possession is REQUIRED to be demonstrated
 by the sender and checked by the recipient of those messages."

This acknowledges that PKI management functions will often be accomplished
by means other than CMP messages, such as other protocols, out-of-band
procedures, or physical delivery of tokens.  In these non-CMP scenarios,
the procedures followed by the CA, including assurance "by other means"
that the certified end entity can use the private key, should be
documented in the CPS.

But in scenarios where CMP messages are used, the CPS can be simplified
by claiming that Proof of Possession is demonstrated "in accordance with
the Certificate Management Protocol", augmented with a description
of the scheme ("centralized", "basic authenticated", other)
and the algorithms used.

I'll repeat the question that Peter dodged:  does making PoP REQUIRED
in the case where CMP messages are used negatively impact any usage
scenarios?

The only negative consequence brought up so far was Michael Warner's
granting of power of attorney, in which he said requiring PoP would
"make some things a little more inconvenient".  Others thought that
this usage (intentionally issuing certs to non-keyholders) was a
Bad Idea.

From: <[email-masked]>
X400-Received: by mta bath.mail.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Thu, 9 Oct 1997 18:16:32 +0100
X400-Received: by mta fel01m2 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Thu, 9 Oct 1997 18:16:11 +0100
X400-Received: by mta bra01c1 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Thu, 9 Oct 1997 18:16:02 +0100
X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5-text); Relayed; Thu, 9 Oct 1997 18:17:38 +0100
Date: Thu, 9 Oct 1997 18:17:38 +0100
X400-Originator: [email-masked]
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;win0199 0000008800013259]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 13259
Alternate-Recipient: Allowed
To: Michael Warner <[email-masked]>
Cc: [email-masked]
Subject: RE(4): Last Call (CMP proof-of-possession)
Status:

>> Without POP, all the certificate 
>> says is: "This name wishes to be associated with the public key in the
>> certificate; the corresponding private key may however belong to someone 
>> else" - very useful :-(. 
>
>An example of where this precise meaning may be useful is for granting 
>power of attorney.   

You would need to elaborate on this for me to comment on it. One way of
handling power of attorney with POP might be to generate a private public 
key pair, to ask for a "power of attorney" policy to be associated with the
certificate, and then to pass the private key to the subject who is to be
given the power of attorney. Power of attornety is thus actually granted by
passing the subject a "power of attorney" key.

>> I'm also concerned that individuals might be spoofed into
>> presenting the wrong public key value to the CA when requesting a
>> certificate, or the request may be tampered with en route, so that the
>> malicious private key owner who substituted his/her own public key can 
>> then masquerade as the individual. 
>
>This represents a very significant problem with the certification 
protocol.
>POP does nothing to overcome this threat, since anything signed with the 
>private key could also be signed by an attacker with her own private key.

Yes, I suppose that once we allow that the request might be tampered with, 
the signed part of it could also be tampered with :-(. The answer would
seem to lie in providing data origin authentication in the request 
protocol.

> 
>> If you (a CA) are making a guaranteed binding between two values, both 
>> need to be authenticated for the guarantee to be worth anything.
>
>I would rephrase it as you have to make clear what the binding is, that 
you are guaranteeing.

But what binding *are* you guaranteeing?

>Not withstanding the above, I am not strongly opposed to POP - it might 
>just
>make some things a little more inconvenient.

And I'm not wanting to start a long discussion either, so just treat my
response as a dying gasp of a dilettante standardiser if you like!

Regards,

Tom Parker

From: "Arsenault, Al W." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Last Call (CMP proof-of-possession)
Date: Thu, 9 Oct 1997 11:43:10 -0400
Status:

Dave, et alia:

I agree with the thought, but I think that your wording below needs to
be clarified somewhat:

>
>>To clarify the questions raised by the straw poll respondents, here
>>is a restatement of the question:
>
> >"If Certificate Management Protocol messages are used to issue
> >certificates, then Proof-of-Possession is REQUIRED to be demonstrated
> >by the sender and checked by the recipient of those messages."

Here's a scenario I want to support.  A user is issued a certificate
valid for a finite period - let's say one year for argument's sake.  At
the conclusion of one year, I as a CA want to "renew" that certificate.
That is, I as the CA decide that all information in that certificate is
still valid, the public/private keys can still be used, etc.  All I want
to do is issue a new certificate, with a new certificate serial number
and new validity period (and signature value of course :-),  and
everything else the same.

If the user's private keys are stored on a hardware token, I as the CA
would like to create a certificate and send it to the user in a
CertRepContent message.  (I don't want her to have to physically bring
her token back to me - that's an inconvenience for which many users will
not stand.)  This would not have been preceded by a CertReqContent
message - I don't want the user to have to take any positive action to
get a renewed certificate, I just want it to show up.  

>Question:  given that this is a case where "Certificate Management Protocol
messages are used to issue certificates", how do I do PoP?  Is the
alternative to say that I cannot do something like this - the new cert
can ONLY be issued if the user first sends a CertReqContent?
Personally, I don't like that - it's an unnecessary inconvenience on the
user, and it doesn't really buy any extra security.  (I know that the
user originally had the right private key, and I'm already confident
that she still has it, or I wouldn't have made the conscious choice to
issue her a renewed certificate.)

Based on that, an alternative suggestion for the wording is something
along the lines of:

	"If certificates are issued in CMP response messages sent in response
>to CMP request messages that contain public keys, then then
>Proof-of-Possession is REQUIRED to be demonstrated by the end-entity and
checked by the CA."

where CMP request messages are taken to include InitReqContent,
CertReqContent, CertificationRequest, KeyUpdReqContent, and
CrossCertReqContent; and CMP response messages includes the response
messages corresponding to these.

This seems to me to require PoP in instances where a bunch of (but maybe
not all :-) IETF technologists think it's needed (i.e., when the user is
presenting a locally-generated key and asking that it be put into a
certificate), while allowing people providing PoP through other (e.g.,
physical means) to avoid unnecessary work.

Thoughts?

				Al Arsenault

	- I speak only for myself; my opinions do not necessarily represent
those of my employer
>
>

Date: Thu, 9 Oct 1997 10:47:51 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

> From: "Peter Williams" <[email-masked]>
> 
> I judge things at 4 = 4 actually. One can throw in the authors
> and bias the count, I suppose. But perhaps that is not fair
> as they represented the comments and concensus, not their own
> opinions.
> 
> But this posturing is purile. The material arguments were made last time
> we debated this issue and came to a concensus represented
> by the next several versions of the draft.

Achieving "rough consensus" is puerile?  Following IETF procedure for
working group Last Call is improper?

The concensus that was reached was that the PKIX documents were dragging
on for far too long in Internet Draft stage.  I was present at the meeting
where the change was made, and I believe that the document editor will
confirm that the RECOMMENDED wording was inserted not because consensus
was achieved on the merits, but out of a desire to avoid a fillibuster
by a small number of individuals.

By my count, the Last Call tally is:

REQUIRED      RECOMMENDED    Unknown
--------      -----------    ----------
Kemp          Williams       Shuttleworth
Beattie       Povey          Simonetti
Lockhart      mfSmith        mfSmith (req'd for initial, rec'd for reissue)
Parker                       Warner (not strongly opposed to required PoP)
Housley
Jueneman
Lowry
Pinkas (qualified "by other means")
Arsenault

That's a pretty solid consensus, and that doesn't include those who
might be expected to strengthen it further.  Counting the document
editor(s) is "biasing" the vote???  The duty of an editor is to reflect
WG decisions in the document, but should that invalidate the editors'
rights to participate in those decisions by expressing their own opinions?

> What **new** issue is there to discuss which was
> not discussed last time, which would give
> a valid rationale for a change in the document back
> to the previous position?

The issue is that IETF procedure requires Working Group Last Calls to
last for a finite period of time, generally four weeks.  After that period,
a decision is reached one way or another.  With "rough consensus" or better,
the document will reflect that consensus.  If opinion is "halved" (to
use Ryder Cup terminology), the status quo is preserved.

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

We are all agreed that policy issues are properly addressed in
individual CAs' Certification Practice Statements, as framed 
by Part 4.

But most people (as counted above) believe that Proof of Possession is
not a policy issue, it is a fundamental component of any meaningful
Public Key Infrastructure.  You might as well argue that the use of
digital signatures on certificates is a policy issue - that CAs should
be free to set their own policy on whether certs are signed, as long
as that policy is described in the CPS.

To clarify the questions raised by the straw poll respondents, here
is a restatement of the question:

 "If Certificate Management Protocol messages are used to issue
 certificates, then Proof-of-Possession is REQUIRED to be demonstrated
 by the sender and checked by the recipient of those messages."

This acknowledges that PKI management functions will often be accomplished
by means other than CMP messages, such as other protocols, out-of-band
procedures, or physical delivery of tokens.  In these non-CMP scenarios,
the procedures followed by the CA, including assurance "by other means"
that the certified end entity can use the private key, should be
documented in the CPS.

But in scenarios where CMP messages are used, the CPS can be simplified
by claiming that Proof of Possession is demonstrated "in accordance with
the Certificate Management Protocol", augmented with a description
of the scheme ("centralized", "basic authenticated", other)
and the algorithms used.

I'll repeat the question that Peter dodged:  does making PoP REQUIRED
in the case where CMP messages are used negatively impact any usage
scenarios?

The only negative consequence brought up so far was Michael Warner's
granting of power of attorney, in which he said requiring PoP would
"make some things a little more inconvenient".  Others thought that
this usage (intentionally issuing certs to non-keyholders) was a
Bad Idea.

Date: Wed, 8 Oct 1997 06:37:07 -0400
To: Dwight Arthur <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Comments on [MANDATORY cert discovery capabiity]
Cc: [email-masked], George Capehart <[email-masked]>, PKIX List <[email-masked]>
Status:

Dwight,

	Your concern cited in the example is valid, but it also is outside
of th scope of PKIX.

Steve

From: Dean Povey <[email-masked]>
To: "Peter Williams" <[email-masked]>
Cc: [email-masked]
Subject: Re: Last Call (CMP proof-of-possession) 
Date: Thu, 09 Oct 97 13:47:17 +1000
Status:

I agree with Peter.  I think this comes down to a policy issue.  I think we 
should mandate support for PoP in implementations, but leave the actual 
decision of whether it is required to be used up to the policy of the 
organisation managing the CA.  I vote for STRONGLY RECOMMENDED.

-- 
+----------------------------------------+-------------------------------+
| Dean Povey,                            |  Email: [email-masked]     |
| Research Scientist, Security Unit,     |  Phone: +61 7 3864 2799       | 
| CRC for Distributed Systems Technology |  Fax:   +61 7 3864 1282       |
+----------------------------------------+-------------------------------+

Reply-To: "Peter Williams" <[email-masked]>
From: "Peter Williams" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>
Subject: Re: Last Call (CMP proof-of-possession)
Date: Wed, 8 Oct 1997 16:25:20 -0700
Status:

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: Wednesday, October 08, 1997 2:16 PM
Subject: Re: Last Call (CMP proof-of-possession)

>Peter, I would assume that the purpose of a final call is to take one more
>look as what is being proposed -- otherwise, why have them?> So far, your
>arguments haven't
>>convinced me, nor, apparently, any of the others who have responded.

I judge things at 4 = 4 actually. One can throw in the authors
and bias the count, I suppose. But perhaps that is not fair
as they represented the comments and concensus, not their own
opinions.

But this posturing is purile. The material arguments were made last time
we debated this issue and came to a concensus represented
by the next several versions of the draft.

What **new** issue is there to discuss which was
not discussed last time, which would give
a valid rationale for a change in the document back
to the previous position?

Why must "strongly recommended" suddenly be vitally
replaced by "mandatory"?

Whose axe is being ground, to use a Juenemanism?

>So please answer my question -- why is a statement of policy expressed in a
>standard, even though written by technologists wearing proverbial white
>socks, necessarily inferior to policies that might be written by people who
>are much less knowledgeable about the issues?

Because we agreed in the charter that certificate policy issues go
into part IV, and that this would consist of recommendations and
schematic advice concerning the very new area of certificate
policy and practice.

Have you or David read the document?

It is for the people who you evidently view as less knowledgeable
about policy to decide how they run their domains, not
a software vendor. Its for govts, corporations and associations
to set policy; not IETF. Its for IETF to lay out the framework,
which Santosh and Warwick have done to the
credit of themselves and their sponsors.

How one filsl in the policy dots is up to that CA operator. Hire a
specialised policy
consultant is my advice. They tend to be in profesional
services companies rather than software vendors,
is my experience -  bankers, accountants, management
policy types, auditors, etc. Even lawyers and CA/Repository
specialists. (Being a commercial CA has little to do with
using and conforming to PKIX 1-3 I might note; this is just
interworking technology.)

As I have said before, I can imagine a user area WG actually
specialising part IV and coming up with a specific
recommendation for operating PKIX-1-3 in a domain- and
policy-specific manner likely to further the goals of the Internet perhaps
more
directly than if we leave it to the market and competition
for mindshare.

 >
>
>
>Robert R. Jueneman
>Security Architect
>Novell, Inc.
>Network Services Division
>122 East 1700 South
>Provo, UT 84604
>801/861-7387
>[email-masked]
>

Reply-To: "Peter Williams" <[email-masked]>
From: "Peter Williams" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: Last Call (CMP proof-of-possession)
Date: Wed, 8 Oct 1997 15:43:35 -0700
Status:

<html><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META content='"MSHTML 4.71.1712.3"' name=GENERATOR>
</HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>-----Original Message-----<BR>From: David P. Kemp 
&lt;<A href="mailto:[email-masked]">[email-masked]</A>&gt;<BR>To: 
<A href="mailto:[email-masked]">[email-masked]</A> &lt;<A 
href="mailto:[email-masked]">[email-masked]</A>&gt;<BR>Date: 
Wednesday, October 08, 1997 1:23 PM<BR>Subject: Re: Last Call (CMP 
proof-of-possession)<BR><BR></DIV>
<DIV></FONT>&gt;&gt; From: &quot;Peter Williams&quot; &lt;<A 
href="mailto:[email-masked]">[email-masked]</A>&gt;<BR>&gt;&gt;<BR>&gt;&gt; 
Should a CA wish to take a cert from the VeriSign<BR>&gt;&gt; directory and 
reissue it to Fred, and send<BR>&gt;&gt; Fred an email saying - replace your 
VeriSign<BR>&gt;&gt; low-assurance $1000 cert with this cert with 
$10000<BR>&gt;&gt; protection plan warranties, there should be 
nothing<BR>&gt;&gt; ***in PKIX** which prevents this commercial practice. 
It<BR>&gt;&gt; is not for some IETF techie&nbsp; types to set/limit business 
rules<BR>&gt;&gt; or limit the scope of available policies through 
rigged<BR>&gt;&gt; conformance rules.<BR>&gt;<BR>&gt;I'm afraid I don't 
understand this argument.&nbsp; Nothing in PKIX prevents<BR>&gt;this practice, 
in part because no CMP messages are used.&nbsp; Fred doesn't<BR>&gt;request a 
new cert at all - VeriSign is just issuing a new one with<BR>&gt;(presumably) 
the old public key and publishing and/or delivering it by<BR>&gt;some non-CMP 
means.&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE>
    <DIV>Let me help you with understanding the argument by asking:.</DIV>
    <DIV>&nbsp;</DIV>
    <UL>
        <LI>Why are no CMP messages used, as you assert? (given this is a 
        PKIX-CMP thread, discussing</LI>
        <LI>final call CMP issues concerning POP?)</LI>
        <LI></LI>
        <LI>What caused you to assume this? Why can &quot;take a cert&quot;</LI>
        <LI>and &quot;send an email&quot; not be CMP messages, as one</LI>
        <LI>might expect in a thread entitled CMP proof-or-possession?</LI>
        <LI></LI>
        <LI>Are you alluding to a prevailing design interpretation that CMP 
        prevents</LI>
        <LI>such a reissuance practice? Or language in **CMP* which prevents 
        CMP<BR>messages and conforming implementations from providing this 
        type</LI>
        <LI>of service?</LI>
        <LI></LI>
        <LI>Is the move to make POP mandatory an attempt to ensure that</LI>
        <LI>conforming CMP end-systems cannot be used in the mode which the 
        scenario</LI>
        <LI>addresses? This is what Bob Jueneman seems to assert (and I note 
        none of</LI>
        <LI>the proposer's of the change openly argued such as a 
        rationale.)</LI>
        <LI></LI>
        <LI>Are you attempting to prevent minimal, PKIX-3 conforming systems 
        from</LI>
        <LI>engaging in such practices through **CMP exchanges**?</LI></UL>
    <DIV>&nbsp;</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>I hope these open question lead understanding, without forcing you into 
    any particular</DIV>
    <DIV>analysis. Perhaps recall we are discussing in this sub-thread PKIX-3 
    CMP,</DIV>
    <DIV>not some other matter. By and large, we want to use the actual</DIV>
    <DIV>CMP formats for interworking, not the option to use proprietary 
    stuff</DIV>
    <DIV>or custom CMP extensions which prevent generalised interworking, 
    surely?</DIV></BLOCKQUOTE>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;<BR>&gt;I would second Carlisle's suggestion that you read the 
document<BR>&gt;under discussion and address concerns with the contents of that 
document,<BR>&gt;instead of creating issues out of thin air and then arguing 
against<BR>&gt;them.&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>No comment. Its offensive. calls for **mandatory** conformance</DIV>
<DIV>are often a signal that someone has a specific policy agenda</DIV>
<DIV>they want to get enforced by the standard, if</DIV>
<DIV>the issue is not one of minimum interworking.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Do recall that we had a long debate on this POP issue once before, 
and</DIV>
<DIV>you accepted the concensus outcome then. When</DIV>
<DIV>the PKIX-3 was changed, I can find nowhere where you</DIV>
<DIV>then objected to the change, until suddenly now.</DIV>
<DIV>&nbsp;</DIV>
<DIV>This POP thing not a new item; its an item which those who</DIV>
<DIV>lost the postiion last time seem now to be attempting</DIV>
<DIV>to force back into the standard, and seem to</DIV>
<DIV>have no hesitation to use personal attacks.</DIV>
<DIV>&nbsp;</DIV>
<DIV>It must be really important to someone for</DIV>
<DIV>such tactics are being used. My curiosity is</DIV>
<DIV>rising.</DIV>
<DIV><BR>&gt;<BR>&gt;Specifically, can you provide an example where:<BR>&gt; 1) 
an on-line certification request is used,<BR>&gt; 2) the private key first 
appears at the End Entity*, and<BR>&gt; 3) requiring the certification request 
to include the PoP field<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; would be a 
hardship?<BR><BR>&gt;<BR>&gt;(* CMP says: &quot;key generation may also occur 
elsewhere, but for the<BR>&gt;&nbsp;&nbsp; purposes of PKI management we can 
regard key generation as occurring<BR>&gt;&nbsp;&nbsp; wherever the key is first 
present: at an end entity, RA or CA.&quot;)<BR>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>I do not understand.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>First you retort :Peter you are not even talking about CMP. Then</DIV>
<DIV>you say; CMP can be implemented using offline or online</DIV>
<DIV>means. Then you ask questions about online CMP protocol 
examples.</DIV></BODY></HTML>

</html>

Date: Thu, 9 Oct 1997 08:53:47 +1000
From: Michael Warner <[email-masked]>
To: [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Cc: [email-masked]
Status:

From: Bob Jueneman <[email-masked]>
> Michael Warner said:
> 
> >> Without POP, all the certificate 
> >> says is: "This name wishes to be associated with the public key in the
> >> certificate; the corresponding private key may however belong to someone 
> >> else" - very useful :-(. 
> 
> >An example of where this precise meaning may be useful is for granting 
> >power of attorney.   
> 
> This would be a particularly BAD idea, for it would make it impossible to
> revoke the power of attorney without revoking the user's right to use his
> own name.>                                                                             

Easy - just limit the validity dates of the certificate, or revoke the certificate.

By the way, I'm not saying there ARE going to be schemes exactly like this -
I think it would need a LOT more thought - just that we should be careful to
dismiss the usefulness of issuing certificates without POP.

Cheers,

Michael

Date: Wed, 08 Oct 1997 15:15:35 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

Peter, I would assume that the purpose of a final call is to take one more
look as what is being proposed -- otherwise, why have them?> So far, your
arguments haven't 
>convinced me, nor, apparently, any of the others who have responded.

>Should a CA wish to take a cert from the VeriSign
>directory and reissue it to Fred, and send
>Fred an email saying - replace your VeriSign
>low-assurance $1000 cert with this cert with $10000
>protection plan warranties, there should be nothing
>***in PKIX** which prevents this commercial practice. It
>is not for some IETF techie  types to set/limit business rules
>or limit the scope of available policies through rigged
>conformance rules.

I disagree with all three premises you have expressed in that paragraph:

1.  I believe that as part of establishing a standard, which is supposed to
contain the best thinking on the subject, we have an obligation to examine
such scenarios, and to reject them if they are too dangerous.  And I believe
that later in your message you indicate that no reputable  CA would issue
such unsolicited certificates.  "Rolling" certificates in that way would add
nothing whatsoever to the confidence that a relying party has or should have
for such a certificate, since the new CA has not undergone any due diligence
with respect to the subscriber's identity, nor has it confirmed the
subscriber's possession of the private key.  There is nothing, therefore,
that would prevent that CA from issuing a certificate containing my public
key and Frank Sinatra's identity. That is potentially quite harmful to me,
to ol' Blue Eyes, and of course to any relying parties, and as the
knowledgeable experts in this area we ought to take appropriate, proactive,
action to limit such shenanigans wherever possible.

2. Your hidden presumption seems to be that the collective wisdom of the
IETF member "techies" should be completely ignored, and that omnipotent,
all-knowing "business" people should be allowed to operate in a completely
unfettered manner.  Sorry, but I don't buy that argument. That brand of
laissez faire capitalism went out of style back around the time of the
silent movies, when the monopolists were still throwing widows and orphans
in front of trains. I also don't buy the implication that everyone in the
IETF is totally devoid of any business sense, or a captive of the
military-industrial complex.

3.  Your insinuation that any conformance rules contrary to your position
must have been "rigged," with all of the conspiratorial connotations of that
word, is even more objectionable.  But I would note that IETF RFC's, AKA
standards, are not mandatory -- the IETF doesn't maintain a police force,
and anyone who chooses to ship a non-conforming product is free to do so. 
Of course, buyers may take some convincing as to why this particular product
is non-conforming in this area.

>
>Should VeriSign decide to upgrade its class 1 protections
>"free" to Class 2 protections (having used some out of band means
>to improve the user authentication an) it may invite its subscribers to
>replace its OWN certs by sending them a (n invitation to
>downloada ) replacement cert.
>
This, of course, is a complete red herring, since VeriSign would have
(presumably) already adequately verified the subscriber's control over the
private key when the first certificates were issued.  Having said that, I
would note that I am still opposed to (re-)issuing certificates containing
public keys previously listed in some other certificate, except in such
extraordinary circumstances as a change of name or ownership of a CA, which
would require the resissuance of millions of certificates.

>This is known as unsolicited cert issuance. PKIX must
>not interfere with( commercial) use of such practices.
>Safeguards on appropriate and safe use of such
>may be built into policy, versus technology, where
>it belongs.

But the question is, who is to build such safeguards into what policies?

Are you looking for the CAs to be so completely above-board and honest that
they would always self-regulate themselves? 

Are you assuming that every CA that ever goes into business will write their
own 80+ page policy statement and Certification Practice Statement, and that
every relying party will read and heed eery word of such documents every
time they accept a signature?  Come on -- VeriSign is to be commended for
making a valiant stab at the problem, but I would hope that such a practice
wouldn't become the norm, for it is completely impractical.

Or perhaps you are assuming that the various legislators in the 50 states,
not to mention all the various non-US countries, will somehow come up to
speed and address these questions on a timely and effective basis?  At that
point, having tried to work with a number of such efforts in various states,
I am overcome with the giggles.

So please answer my question -- why is a statement of policy expressed in a
standard, even though written by technologists wearing proverbial white
socks, necessarily inferior to policies that might be written by people who
are much less knowledgeable about the issues?

>
>Of course a reputable CA will not issue *valid* certs of
>this form, as validity of the unsolicited cert requires
>that the user accept the invitation/cert, and the CA
>maintain records that the "accepting event" took place.
>Publication of the cert in a repository does not
>take place in accreditable ABA DSG conforming
>CA until the cert is valid. No one can rely
>on a cert which has yet to be published in the issuing
>repository, note, in such policy control regimes.

On that I think we agree.
>
>Finally, note that this situation is more readily understandable
>if one considers smartcards. The banks send the replacement
>smartcard (with centrally generated RSA key and signed cert) without
>user request. The user and obligated party makes **NO** POP
>prior to cert issuance, though s/he does essentially
>attest to POP conditions/assurances during acceptance of the card, by
>use or (in
>some banks first contact procedures) activation of the card
>through a required phone call etc.

Again, you have several untested assertions.  First, that the RSA(?) keys
are centrally generated, rather than being generated on the card itself.
Second, that the card necessarily contains the already signed certificate at
the time it is sent to the subscriber -- why does the smart card have to
contain a certificate at all?  Wouldn't it make more sense to send out the
card containing a public/private key and a card number to a designated
subscriber, and then have the subscriber explicitly request that a
certificate be issued (after validating the contents) by signing a prototype
certificate containing the card serial number?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Wed, 08 Oct 1997 14:09:57 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

well stated, Peter.

Michael

>>> "Peter Williams" <[email-masked]> 10/08/97 12:13PM >>>
1. As agreed, and previously argued, there should be
no mandatory status for POP. The disadvantages
outweigh the advanages.

2. Those that are at final call (!) seeking to change
previous agreements should at least have
the decency to state the pro and con
arguments previously declared, if
they wish to have the "court change the
decision on appeal."

------

Should a CA wish to take a cert from the VeriSign
directory and reissue it to Fred, and send
Fred an email saying - replace your VeriSign
low-assurance $1000 cert with this cert with $10000
protection plan warranties, there should be nothing
***in PKIX** which prevents this commercial practice. It
is not for some IETF techie  types to set/limit business rules
or limit the scope of available policies through rigged
conformance rules.

Should VeriSign decide to upgrade its class 1 protections
"free" to Class 2 protections (having used some out of band means
to improve the user authentication an) it may invite its subscribers to
replace its OWN certs by sending them a (n invitation to
downloada ) replacement cert.

This is known as unsolicited cert issuance. PKIX must
not interfere with( commercial) use of such practices.
Safeguards on approprate and safe use of such
may be built into policy, versus technololgy, where
it belongs.

Of course a reputable CA will not issue *valid* certs of
this form, as validity of the unsolicited cert requires
that the user accept the invitation/cert, and the CA
maintain records that the "accepting event" took place.
Publication of the cert in a repository does not
take place in accreditable ABA DSG conforming
CA until the cert is valid. Noone can rely
on a cert which has yet to be published in the issuing
repository, note, in such policy control regimes.

Finally, note that this situation is more readily understandabe
if one considers smartcards. The banks send the replacement
smartcard (with centrally generated RSA key and signed cert) without
user request. The user and obligated party makes **NO** POP
prioir to cert issuance, though s/he does essentially
attest to POP conditions/assurances during acceptance of the the card, by
use or (in
some banks first contact procedures) activation of the card
through a required phone call etc.

I suspect this is what you Denis are getting at, and as always
I would agree with such perpectives based on the reality of
commercial vs merely military key management designs.

-----Original Message-----
From: Denis Pinkas <[email-masked]>
To: IETF-PXIX <[email-masked]>
Date: Wednesday, October 08, 1997 12:56 AM
Subject: Re: Last Call (CMP proof-of-possession)

>David, Tom , Bob, and all others ...
>
>Since I have been involved in the thread along PoP, here is my position.
>
>The text in section 2.3 currently says :
>
>" In order to prevent certain attacks and to allow a CA/RA to properly
>check the validity of the binding between an end entity and a key pair,
>the PKI management operations specified here make it possible for an end
>entity to prove that it has possession of (i.e., is able to use) the
>private key corresponding to the public key for which a certificate is
>requested.  A given CA/RA is free to choose whether or not to enforce
>POP in its certification exchanges (i.e., this may be a policy issue).
>However, it is STRONGLY RECOMMENDED that CAs/RAs enforce POP because
>there are currently many non-PKIX operational protocols in use (various
>electronic mail protocols are one example) which do not explicitly check
>the binding between the end entity and the private key."
>
>I have no problem to change in the last sentence "STRONGLY RECOMMENDED"
>by "REQUIRED" provided that we say that this must be done by whatever
>means. In particular, when the key pair is generated by the CA, PoP is
>not required in the certification exchanges.
>
>So I would propose to reformulate that last sentence along something
>like the following:
>
>" However, it is REQUIRED that CAs/RAs verify POP by whatever means
>(i.e. using certification exchanges and/or procedural means) because
>there are currently many non-PKIX operational protocols in use (various
>electronic mail protocols are one example) which do not explicitly check
>the binding between the end entity and 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: Wed, 8 Oct 1997 16:27:48 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

> From: "Simonetti David" <[email-masked]>
> 
> If one agrees with the content of the recently distributed Cert Policy and 
> Cert Practices Framework, it serves to support Peter's statement that this 
> should be covered in the policy...
> 
> Section 4.3.1, Initial Registration, "If and how the subject must prove 
> possession of the companion private key for the public key being registered 
> (9);"
> 
> Dave Simonetti

I assume that the Framework is intended to be useful as guidance for
all CAs, not just those who implement the minimum required subset of the
PKIX Certificate Management Protocol.

If they don't do CMP at all (all management operations are handled by
out-of-band means), or if they do a superset of CMP (perhaps including
message sequences in addition to the Basic Authenticated scheme
(section 2.2.2.2, the only CMP scheme now required for PKIX conformance),
then section 4.3.1 of the Framework is useful.

Date: Wed, 8 Oct 1997 15:54:00 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

> From: "Peter Williams" <[email-masked]>
>
> Should a CA wish to take a cert from the VeriSign
> directory and reissue it to Fred, and send
> Fred an email saying - replace your VeriSign
> low-assurance $1000 cert with this cert with $10000
> protection plan warranties, there should be nothing
> ***in PKIX** which prevents this commercial practice. It
> is not for some IETF techie  types to set/limit business rules
> or limit the scope of available policies through rigged
> conformance rules.

I'm afraid I don't understand this argument.  Nothing in PKIX prevents
this practice, in part because no CMP messages are used.  Fred doesn't
request a new cert at all - VeriSign is just issuing a new one with
(presumably) the old public key and publishing and/or delivering it by
some non-CMP means.

Moreover, if the old cert had been issued with PoP, the new one
inherits that PoP if the old public key is reused.  (No need to consider
the case where Fred used to possess the private key but has now
lost it :-).  If it was compromised, the CA had better not issue a
new cert for it.  If it was just forgotten, the new certificate is
useless, but no harm is done.)

If VeriSign takes it upon itself to issue the new cert with a *new* public
key (without a request from Fred), what CMP messages are used, and how does
VeriSign know what public key to put in the cert in the first place?
This situation doesn't fall under the Basic Authenticated scheme, and
the Centralised scheme uses out-of-band protection for the private key.

> This is known as unsolicited cert issuance. PKIX must
> not interfere with( commercial) use of such practices.

How would a requirement that CMP cert solicitations use PoP interfere
with unsolicited cert issuance?

> Finally, note that this situation is more readily understandabe
> if one considers smartcards. The banks send the replacement
> smartcard (with centrally generated RSA key and signed cert) without
> user request.

The CMP specification says:

   "Note that on-line protocols are not the only way of implementing
   the above [PKI Management] operations.  For all operations there are
   off-line methods of achieving the same result, and this
   specification DOES NOT MANDATE use of on-line protocols.
                 ----------------
   For example, when hardware tokens are used, many of the operations
   may be achieved as part of the physical token delivery."

(emphasis mine)

I would second Carlisle's suggestion that you read the document
under discussion and address concerns with the contents of that document,
instead of creating issues out of thin air and then arguing against
them.

Specifically, can you provide an example where:
 1) an on-line certification request is used,
 2) the private key first appears at the End Entity*, and
 3) requiring the certification request to include the PoP field
     would be a hardship?

(* CMP says: "key generation may also occur elsewhere, but for the
   purposes of PKI management we can regard key generation as occurring
   wherever the key is first present: at an end entity, RA or CA.")

Date: Wed, 08 Oct 1997 15:15 -0500
From: "Simonetti David" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

If one agrees with the content of the recently distributed Cert Policy and 
Cert Practices Framework, it serves to support Peter's statement that this 
should be covered in the policy...

Section 4.3.1, Initial Registration, "If and how the subject must prove 
possession of the companion private key for the public key being registered 
(9);"

Dave Simonetti
 ----------
From: Peter Williams
To: D.Pinkas; IETF-PXIX
Subject: Re: Last Call (CMP proof-of-possession)
Date: Wednesday, October 08, 1997 2:43PM

1. As agreed, and previously argued, there should be
no mandatory status for POP. The disadvantages
outweigh the advanages.

2. Those that are at final call (!) seeking to change
previous agreements should at least have
the decency to state the pro and con
arguments previously declared, if
they wish to have the "court change the
decision on appeal."

 ------

Should a CA wish to take a cert from the VeriSign
directory and reissue it to Fred, and send
Fred an email saying - replace your VeriSign
low-assurance $1000 cert with this cert with $10000
protection plan warranties, there should be nothing
***in PKIX** which prevents this commercial practice. It
is not for some IETF techie  types to set/limit business rules
or limit the scope of available policies through rigged
conformance rules.

Should VeriSign decide to upgrade its class 1 protections
"free" to Class 2 protections (having used some out of band means
to improve the user authentication an) it may invite its subscribers to
replace its OWN certs by sending them a (n invitation to
downloada ) replacement cert.

This is known as unsolicited cert issuance. PKIX must
not interfere with( commercial) use of such practices.
Safeguards on approprate and safe use of such
may be built into policy, versus technololgy, where
it belongs.

Of course a reputable CA will not issue *valid* certs of
this form, as validity of the unsolicited cert requires
that the user accept the invitation/cert, and the CA
maintain records that the "accepting event" took place.
Publication of the cert in a repository does not
take place in accreditable ABA DSG conforming
CA until the cert is valid. Noone can rely
on a cert which has yet to be published in the issuing
repository, note, in such policy control regimes.

Finally, note that this situation is more readily understandabe
if one considers smartcards. The banks send the replacement
smartcard (with centrally generated RSA key and signed cert) without
user request. The user and obligated party makes **NO** POP
prioir to cert issuance, though s/he does essentially
attest to POP conditions/assurances during acceptance of the the card, by
use or (in
some banks first contact procedures) activation of the card
through a required phone call etc.

I suspect this is what you Denis are getting at, and as always
I would agree with such perpectives based on the reality of
commercial vs merely military key management designs.

 -----Original Message-----
From: Denis Pinkas <[email-masked]>
To: IETF-PXIX <[email-masked]>
Date: Wednesday, October 08, 1997 12:56 AM
Subject: Re: Last Call (CMP proof-of-possession)

>David, Tom , Bob, and all others ...
>
>Since I have been involved in the thread along PoP, here is my position.
>
>The text in section 2.3 currently says :
>
>" In order to prevent certain attacks and to allow a CA/RA to properly
>check the validity of the binding between an end entity and a key pair,
>the PKI management operations specified here make it possible for an end
>entity to prove that it has possession of (i.e., is able to use) the
>private key corresponding to the public key for which a certificate is
>requested.  A given CA/RA is free to choose whether or not to enforce
>POP in its certification exchanges (i.e., this may be a policy issue).
>However, it is STRONGLY RECOMMENDED that CAs/RAs enforce POP because
>there are currently many non-PKIX operational protocols in use (various
>electronic mail protocols are one example) which do not explicitly check
>the binding between the end entity and the private key."
>
>I have no problem to change in the last sentence "STRONGLY RECOMMENDED"
>by "REQUIRED" provided that we say that this must be done by whatever
>means. In particular, when the key pair is generated by the CA, PoP is
>not required in the certification exchanges.
>
>So I would propose to reformulate that last sentence along something
>like the following:
>
>" However, it is REQUIRED that CAs/RAs verify POP by whatever means
>(i.e. using certification exchanges and/or procedural means) because
>there are currently many non-PKIX operational protocols in use (various
>electronic mail protocols are one example) which do not explicitly check
>the binding between the end entity and 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
>

Comments: Authenticated sender is <[email-masked]>
From: Nick Pope <[email-masked]>
To: Carlisle Adams <[email-masked]>
Date: Wed, 8 Oct 1997 17:46:33 +0000
Subject: GenAnnContent and GenConfContent
CC: IETF-PXIX <[email-masked]>
Return-receipt-to: "Nick Pope" <[email-masked]>
Priority: normal
Status:

I am working with a user client on the design of a key management system
which extends PKIX to meet additional functional requirements.

The recent inclusion of GenReqContent and GenRepContent in the protocol
make it possible to cleanly extend the protocol without danger of
conflict with future versions or other extensions to PKIX.

However, the additional functions to be supported by our key management
system also require the capability to carry additional types of Announce
messages, as well as Confirm messages with parameters.

It is it possible to include a GenAnnContent and GenConfContent to
PKIX-3 before it becomes an RFC?

Otherwise we may have to resort to using GenReqContent and GenRepContent
to carry the Announce and Confirm messages and leaving it to the poor
supplier to handle requests that may go in either direction.

Thanks

Nick Pope

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

Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Carlisle Adams <[email-masked]>
To: "'Nick Pope'" <[email-masked]>
Cc: "'IETF-PXIX'" <[email-masked]>
Subject: RE: GenAnnContent and GenConfContent
Date: Wed, 8 Oct 1997 14:23:23 -0400
Status:

Hi Nick,

>----------
>From: 	Nick Pope[SMTP:[email-masked]]
>Sent: 	Wednesday, October 08, 1997 1:46 PM
>To: 	Carlisle Adams
>Cc: 	IETF-PXIX
>Subject: 	GenAnnContent and GenConfContent
>
>I am working with a user client on the design of a key management system
>which extends PKIX to meet additional functional requirements.
>
>The recent inclusion of GenReqContent and GenRepContent in the protocol
>make it possible to cleanly extend the protocol without danger of
>conflict with future versions or other extensions to PKIX.
>
>However, the additional functions to be supported by our key management
>system also require the capability to carry additional types of Announce
>messages, as well as Confirm messages with parameters.
>
>It is it possible to include a GenAnnContent and GenConfContent to
>PKIX-3 before it becomes an RFC?
>
>Otherwise we may have to resort to using GenReqContent and GenRepContent
>to carry the Announce and Confirm messages and leaving it to the poor
>supplier to handle requests that may go in either direction.

My intention (after consulting with those who originally requested this
extensibility) is to change the name "GenReqContent" to "GenMsgContent".
 This removes the connotation of a "request" and allows arbitrary
general messages (hopefully having something to do with certificate
management!) to be sent, so your Announce messages should fit in here
perfectly well.

"GenRepContent" (no name change) is meant to be used for a response to a
GenMsgContent, wherever this is required.  Therefore, I think that your
GenConfContent (which I assume carries more than the PKIConfirm message,
otherwise why not use that?) could fit in here.

The bottom line is that with the name change I don't think we need to
add GenAnnContent and GenConfContent.  Let me know if you disagree.

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

From: Greg Carter <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SA payloads and Next payload
Date: Wed, 8 Oct 1997 13:53:44 -0400
Status:

I had asked for this awhile back, but think it was only in a private
email.  Whatever the case I'll second the request now.
Thanks. 
----
Greg Carter, Entrust Technologies
[email-masked]
Get FREE FIPS-140-1 Validated Crypto for the desktop
http://www.entrust.com/solo.htm

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Wednesday, October 08, 1997 10:39 AM
>To: 	[email-masked]
>Cc: 	[email-masked]; [email-masked]
>Subject: 	Re: SA payloads and Next payload
>
>Doug,
>
>I've had a request from a customer to add the capability to transmit
>X.509 Attribute Certificates within the ISAKMP Certificate payload.
>Attribute Certs allow authorization information (which may change
>frequently) to be attached to base certs (which are normally updated
>much less frequently), and they allow the authorization administrator
>to operate independently of the Certificate Authority.
>
>Attribute Certificates are defined in the ISO/ITU X.509 standard, but
>have not yet been profiled in the PKIX document series.  There is
>support for doing so, but no one has yet volunteered to do the
>writing :-).
>
>I propose adding the following line to the Cert Encoding field of the
>ISAKMP Certificate payload:
>
>                __________Certificate_Type___________Value___
>                X.509 Certificate - Attribute         10
>
>

Reply-To: "Peter Williams" <[email-masked]>
From: "Peter Williams" <[email-masked]>
To: <[email-masked]>, "IETF-PXIX" <[email-masked]>
Subject: Re: Last Call (CMP proof-of-possession)
Date: Wed, 8 Oct 1997 11:13:24 -0700
Status:

1. As agreed, and previously argued, there should be
no mandatory status for POP. The disadvantages
outweigh the advanages.

2. Those that are at final call (!) seeking to change
previous agreements should at least have
the decency to state the pro and con
arguments previously declared, if
they wish to have the "court change the
decision on appeal."

------

Should a CA wish to take a cert from the VeriSign
directory and reissue it to Fred, and send
Fred an email saying - replace your VeriSign
low-assurance $1000 cert with this cert with $10000
protection plan warranties, there should be nothing
***in PKIX** which prevents this commercial practice. It
is not for some IETF techie  types to set/limit business rules
or limit the scope of available policies through rigged
conformance rules.

Should VeriSign decide to upgrade its class 1 protections
"free" to Class 2 protections (having used some out of band means
to improve the user authentication an) it may invite its subscribers to
replace its OWN certs by sending them a (n invitation to
downloada ) replacement cert.

This is known as unsolicited cert issuance. PKIX must
not interfere with( commercial) use of such practices.
Safeguards on approprate and safe use of such
may be built into policy, versus technololgy, where
it belongs.

Of course a reputable CA will not issue *valid* certs of
this form, as validity of the unsolicited cert requires
that the user accept the invitation/cert, and the CA
maintain records that the "accepting event" took place.
Publication of the cert in a repository does not
take place in accreditable ABA DSG conforming
CA until the cert is valid. Noone can rely
on a cert which has yet to be published in the issuing
repository, note, in such policy control regimes.

Finally, note that this situation is more readily understandabe
if one considers smartcards. The banks send the replacement
smartcard (with centrally generated RSA key and signed cert) without
user request. The user and obligated party makes **NO** POP
prioir to cert issuance, though s/he does essentially
attest to POP conditions/assurances during acceptance of the the card, by
use or (in
some banks first contact procedures) activation of the card
through a required phone call etc.

I suspect this is what you Denis are getting at, and as always
I would agree with such perpectives based on the reality of
commercial vs merely military key management designs.

-----Original Message-----
From: Denis Pinkas <[email-masked]>
To: IETF-PXIX <[email-masked]>
Date: Wednesday, October 08, 1997 12:56 AM
Subject: Re: Last Call (CMP proof-of-possession)

>David, Tom , Bob, and all others ...
>
>Since I have been involved in the thread along PoP, here is my position.
>
>The text in section 2.3 currently says :
>
>" In order to prevent certain attacks and to allow a CA/RA to properly
>check the validity of the binding between an end entity and a key pair,
>the PKI management operations specified here make it possible for an end
>entity to prove that it has possession of (i.e., is able to use) the
>private key corresponding to the public key for which a certificate is
>requested.  A given CA/RA is free to choose whether or not to enforce
>POP in its certification exchanges (i.e., this may be a policy issue).
>However, it is STRONGLY RECOMMENDED that CAs/RAs enforce POP because
>there are currently many non-PKIX operational protocols in use (various
>electronic mail protocols are one example) which do not explicitly check
>the binding between the end entity and the private key."
>
>I have no problem to change in the last sentence "STRONGLY RECOMMENDED"
>by "REQUIRED" provided that we say that this must be done by whatever
>means. In particular, when the key pair is generated by the CA, PoP is
>not required in the certification exchanges.
>
>So I would propose to reformulate that last sentence along something
>like the following:
>
>" However, it is REQUIRED that CAs/RAs verify POP by whatever means
>(i.e. using certification exchanges and/or procedural means) because
>there are currently many non-PKIX operational protocols in use (various
>electronic mail protocols are one example) which do not explicitly check
>the binding between the end entity and 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: Wed, 08 Oct 1997 11:38:51 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

I agree, should be required for initial certificates.  However, in cases where a CA would want to issue a cross certificate to "honor" a respected CA's certificates within their own domain of trust, then that CA should be able to issue that cross-certiticate without a "signed" request or PoP from the "respected" CA.  Example:  I set up an electronic commerce server and wish to service customers with certificates issued from my corporation's bank's CA without having to authenticate them again, myself (since I know my bank's policies and they meet or exceed my own).

Michael

>>> Russ Housley <[email-masked]> 10/07/97 08:30AM >>>
I stongly believe that Proof-of-Possession should be REQUIRED!

Russ

>>Now that we are in last call, I'd like a straw poll to measure the
>>degree of consensus for REQUIRING Proof-of-Possession for PKIX-compliant
>>CAs.  If there is general agreement, PoP can be returned to its
>>original REQUIRED status without delaying the RFC.
>
>I'd like to support him in his proposal to make POP mandatory. As I've 
>already emailed, I believe that the CA should be considered to be 
>actually making a binding between the owner and the private key. The
>certificate should be saying: "this name owns the private key corresponding
>to the public key in this certificate". Without POP, all the certificate 
>says is: "This name wishes to be associated with the public key in the
>certificate; the corresponding private key may however belong to someone 
>else" - very useful :-(. 
>
>I'm also concerned that individuals might be spoofed into
>presenting the wrong public key value to the CA when requesting a
>certificate, or the request may be tampered with en route, so that the
>malicious private key owner who substituted his/her own public key can 
>then masquerade as the individual. 
>
>If you (a CA) are making a guaranteed binding between two values, both 
>need to be authenticated for the guarantee to be worth anything.
>
>Tom Parker
>ICL
>UK.
>

Date: Wed, 08 Oct 1997 09:48:48 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

Denis,

>So I would propose to reformulate that last sentence along something
>like the following:
>
>" However, it is REQUIRED that CAs/RAs verify POP by whatever means
>(i.e. using certification exchanges and/or procedural means) because
>there are currently many non-PKIX operational protocols in use (various
>electronic mail protocols are one example) which do not explicitly check
>the binding between the end entity and the private key."
>
>Denis

The above wording sounds acceptable, but so that I can be sure we are on the
same page, would you explain further what you mean by the non-PKIX protocols
"which do not explicitly check the binding between the end entity and the
private key?"

Are you suggesting that there are systems which would allow a user to sign
using a private key, and then attach a different certificate containing a
public key that would not match? Seems pretty dumb, but I'm not sure what
harm would be caused -- the signature wouldn't verify. I must be missing
something -- could you explain?

A couple of comments on other input to this discussion:

Michael Warner said:

>> Without POP, all the certificate 
>> says is: "This name wishes to be associated with the public key in the
>> certificate; the corresponding private key may however belong to someone 
>> else" - very useful :-(. 

>An example of where this precise meaning may be useful is for granting 
>power of attorney.   

This would be a particularly BAD idea, for it would make it impossible to
revoke the power of attorney without revoking the user's right to use his
own name.  I know of no suggestions within the legal community that would
implement a POA in this manner.  Invariably, the attorney signs his OWN
name, and then indicates the power of attorney under his signature. 
Obviously digital signatures could be used to facilitate this practice -- as
in the case of delegation by a manager to a subordinate. Users could
conceivably issue their own certificates to such individuals, or use an
attribute certificate (best idea, since it would facilitate revocation), or
simply sign a document granting the POA and attaching a copy to every
document the attorney signs.

And maybe I am becoming paranoid in my old age, but Mark Shuttleworth's
comments also bother me somewhat:

>That said, we've already encountered scenarios where an individual will
>not have the private key at request time - for example, where companies
>are requesting certificates for employees using keys they have generated
>centrally.
>
I would get very nervous at the thought that a company would generate
private keys on behalf of their employees, then issue certificates in those
employees names, and only then provide the private keys to the employees
along with the certificates. In such a scenario, the employee cannot be
assured of who else may have had access to the private key and they have not
had an opportunity to review and correct any of the information in the
certificate.  I'm not even very comfortable with the creation of a
certificate for a secure token prior to the token being in the control of
the designated user.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Wed, 8 Oct 1997 10:39:32 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: SA payloads and Next payload
Cc: [email-masked], [email-masked]
Status:

Doug,

I've had a request from a customer to add the capability to transmit
X.509 Attribute Certificates within the ISAKMP Certificate payload.
Attribute Certs allow authorization information (which may change
frequently) to be attached to base certs (which are normally updated
much less frequently), and they allow the authorization administrator
to operate independently of the Certificate Authority.

Attribute Certificates are defined in the ISO/ITU X.509 standard, but
have not yet been profiled in the PKIX document series.  There is
support for doing so, but no one has yet volunteered to do the
writing :-).

I propose adding the following line to the Cert Encoding field of the
ISAKMP Certificate payload:

                __________Certificate_Type___________Value___
                X.509 Certificate - Attribute         10

Regards,
Dave Kemp

----- Begin Included Message -----

                             1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ! Next Payload  !   RESERVED    !         Payload Length        !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ! Cert Encoding !                                               !
        +-+-+-+-+-+-+-+-+                                               !
        ~                       Certificate Data                        ~
        !                                                               !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 10:  Certificate Payload Format

 o  Payload Length (2 octets) - Length in octets of the current payload,
    including the generic payload header.

 o  Certificate Encoding (1 octet) - This field indicates the type of
    certificate or certificate-related information contained in the
    Certificate Data field.

                __________Certificate_Type___________Value___
                 NONE                                  0
                 PKCS #7 wrapped X.509 certificate      1
                 PGP Certificate                        2
                 DNS Signed Key                         3
                 X.509 Certificate - Signature          4
                 X.509 Certificate - Key Exchange       5
                 Kerberos Tokens                        6
                 Certificate Revocation List (CRL)      7
                 Authority Revocation List (ARL)        8
                 SPKI Certificate                       9
                 RESERVED                            10- 255

 o  Certificate Data (variable length) - Actual encoding of certificate
    data.  The type of certificate is indicated by the Certificate
    Encoding field.

----- End Included Message -----

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part4-02.txt
Date: Wed, 08 Oct 1997 09:39:32 -0400
Sender: [email-masked]
Status:

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

	Title		: Internet Public Key Infrastructure 
                          Certificate Policy 
                          and 
                          Certification Practices Framework
	Author(s)	: W. Ford, S. Chokhani
	Filename	: draft-ietf-pkix-ipki-part4-02.txt
	Pages		: 46
	Date		: 07-Oct-97
	
   This   document  presents  a  framework  to  assist  the  writers  of
   certificate  policies  or  certification  practice   statements   for
   certification   authorities   and  public  key  infrastructures.   In
   particular, the framework provides a  comprehensive  list  of  topics
   that potentially (at the writer's discretion) need to be covered in a
   certificate policy definition or a certification practice  statement.
   It is intended that this document, when fully developed, be published
   as an Informational RFC.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki-part4-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-part4-02.txt

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get I-D ACTION-draft-ietf-pki 4 (EuSn/CSOm) (0001C249)
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-part4-02.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-ipki-part4- (AURL/Arch) (0001C24A)
Content-Type: text/plain
Content-ID:	<[email-masked]>

From: "Arsenault, Al W. (MISSI)" <[email-masked]>
To: "'John Lowry'" <[email-masked]>, "'Mark Shuttleworth'" <[email-masked]>
Cc: "'Russ Housley'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Last Call (CMP proof-of-possession)
Date: Wed, 8 Oct 1997 07:50:11 -0400
Status:

I agree with Denis Pinkas' suggestion for the wording:  PoP should be
required for a CA, but it may not be done in the exchange messages.  If
a CA is centrally-generating key pairs on a hardware token which will
later be given to the user, PoP is done by procedural means:  the
private key corresponding to the public in the cert must be on the
token; we verify through all the courier/paper receipt stuff that the
right user got the token; thus, the user has possession of the
appropriate private key. (The same principal works if it's not a
hardware token, but instead is all software, and the user gets the
private key on a floppy disk.)

I *think* that's what's going on in Mark Shuttleworth's comment below.
Mark, is there something else you're doing that I'm missing that would
cause problems?

>----------
>From: 	Mark Shuttleworth[SMTP:[email-masked]]
>Sent: 	Tuesday, October 07, 1997 2:28 PM
>To: 	John Lowry
>Cc: 	Russ Housley; [email-masked]
>Subject: 	Re: Last Call (CMP proof-of-possession)
>
>Hiya folk
>
>We certainly jump through hoops to establish PoP for our current personal
>certification system.  It would be great to require that all clients are
>able to demonstrate PoP at certificate request time.
>
>That said, we've already encountered scenarios where an individual will
>not have the private key at request time - for example, where companies
>are requesting certificates for employees using keys they have generated
>centrally.
>
>--
>Mark Shuttleworth
>Thawte Consulting
>

			Al Arsenault
		- I speak only for myself; my opinions do not necessarily represent
those of my employer

Date: Wed, 8 Oct 1997 14:17:09 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: "Arsenault, Al W. (MISSI)" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: Last Call (CMP proof-of-possession)
Status:

> I *think* that's what's going on in Mark Shuttleworth's comment below.
> Mark, is there something else you're doing that I'm missing that would
> cause problems?

You got it.

--
Mark Shuttleworth
Thawte Consulting

Date: Wed, 8 Oct 1997 11:59:04 +0200
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Search Engines
Status:

> 
> 
> To receive no more correspondence see http://www.iemmc.org
> 

Do it your self. I DONT want te receive more junk email.

> From [email-masked] Wed Oct  8 11:59:16 1997
> Date: Tue, 7 Oct 1997 23:53:43 -0700
> From: NetWorld <[email-masked]>
> To: <[email-masked]>
> Reply-To: [email-masked]
> X-Mailer: NetMailer v1.0 (http://www.alphasoftware.com/netmailer) [C.R-DC4B08AF66FCBB5A0BBBFB7]   
> Subject: Search Engines  
> Mime-Version: 1.0
> 
> I saw your listing on the internet.  I work
> for a company that specializes in directing
> traffic to web sites.  We submit your web site
> to over 250 of the worlds best search engines
> for only $29.95!  (Yahoo, Lycos, Excite, Hotbot,
> Linkstar, Lycos, Webcrawler, AOL,) and hundreds
> others.
> 
> A professional will view your site and put together a list 
> your best key words and submit your site; mailing you
> a computer print out of ALL the search engines your
> site was submitted to.
> 
> If you would like your web site to receive more traffic,
> mail your check for only $29.95 to NetWorld, PO Box
> 326 Oceanside, CA. 92049.  To get your submission 
> started today, fax a copy of the check you are mailing
> to (760) 639-3551.  *BE SURE to include BOTH the
> web site and email address for each site to be submitted.
> For more information see our web page.
> 
> Sincerely,
> 
> NetWorld
> Email: [email-masked]
> http://www.a-1.org/net.htm
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> To receive no more correspondence see http://www.iemmc.org
> 
> 
> 
> 
> 
> 

Date: Wed, 08 Oct 1997 09:35:48 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Re: Last Call (CMP proof-of-possession)
Status:

David, Tom , Bob, and all others ... 

Since I have been involved in the thread along PoP, here is my position.

The text in section 2.3 currently says :

" In order to prevent certain attacks and to allow a CA/RA to properly 
check the validity of the binding between an end entity and a key pair, 
the PKI management operations specified here make it possible for an end 
entity to prove that it has possession of (i.e., is able to use) the 
private key corresponding to the public key for which a certificate is 
requested.  A given CA/RA is free to choose whether or not to enforce 
POP in its certification exchanges (i.e., this may be a policy issue).  
However, it is STRONGLY RECOMMENDED that CAs/RAs enforce POP because 
there are currently many non-PKIX operational protocols in use (various 
electronic mail protocols are one example) which do not explicitly check 
the binding between the end entity and the private key."

I have no problem to change in the last sentence "STRONGLY RECOMMENDED"
by "REQUIRED" provided that we say that this must be done by whatever
means. In particular, when the key pair is generated by the CA, PoP is
not required in the certification exchanges.

So I would propose to reformulate that last sentence along something
like the following:

" However, it is REQUIRED that CAs/RAs verify POP by whatever means
(i.e. using certification exchanges and/or procedural means) because
there are currently many non-PKIX operational protocols in use (various
electronic mail protocols are one example) which do not explicitly check
the binding between the end entity and 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: Tue, 7 Oct 1997 23:53:43 -0700
From: NetWorld <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Subject: Search Engines  
Status:

I saw your listing on the internet.  I work
for a company that specializes in directing
traffic to web sites.  We submit your web site
to over 250 of the worlds best search engines
for only $29.95!  (Yahoo, Lycos, Excite, Hotbot,
Linkstar, Lycos, Webcrawler, AOL,) and hundreds
others.

A professional will view your site and put together a list 
your best key words and submit your site; mailing you
a computer print out of ALL the search engines your
site was submitted to.

If you would like your web site to receive more traffic,
mail your check for only $29.95 to NetWorld, PO Box
326 Oceanside, CA. 92049.  To get your submission 
started today, fax a copy of the check you are mailing
to (760) 639-3551.  *BE SURE to include BOTH the
web site and email address for each site to be submitted.
For more information see our web page.

Sincerely,

NetWorld
Email: [email-masked]
http://www.a-1.org/net.htm

To receive no more correspondence see http://www.iemmc.org

Date: Wed, 8 Oct 1997 09:25:09 +1000
From: Michael Warner <[email-masked]>
To: [email-masked]
Subject: Re: RE(2): Last Call (CMP proof-of-possession)
Cc: [email-masked]
Status:

Without really wanting to (re)start a whole debate (particularly since
I haven't been paying enough attention to this mailing list for the last
few months) ...

> From: <[email-masked]>
> Without POP, all the certificate 
> says is: "This name wishes to be associated with the public key in the
> certificate; the corresponding private key may however belong to someone 
> else" - very useful :-(. 

An example of where this precise meaning may be useful is for granting 
power of attorney.   

> I'm also concerned that individuals might be spoofed into
> presenting the wrong public key value to the CA when requesting a
> certificate, or the request may be tampered with en route, so that the
> malicious private key owner who substituted his/her own public key can 
> then masquerade as the individual. 

This represents a very significant problem with the certification protocol.
POP does nothing to overcome this threat, since anything signed with the 
private key could also be signed by an attacker with her own private key.
 
> If you (a CA) are making a guaranteed binding between two values, both 
> need to be authenticated for the guarantee to be worth anything.

I would rephrase it as you have to make clear what the binding is, that you
are guaranteeing.

Not withstanding the above, I am not strongly opposed to POP - it might just
make some things a little more inconvenient.

Cheers,

Michael Warner
Telstra Research Labs

Date: Tue, 7 Oct 1997 20:28:34 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: John Lowry <[email-masked]>
cc: Russ Housley <[email-masked]>, [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

Hiya folk

We certainly jump through hoops to establish PoP for our current personal
certification system.  It would be great to require that all clients are
able to demonstrate PoP at certificate request time.

That said, we've already encountered scenarios where an individual will
not have the private key at request time - for example, where companies
are requesting certificates for employees using keys they have generated
centrally.

--
Mark Shuttleworth
Thawte Consulting

Date: Tue, 07 Oct 1997 09:18:52 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RE(2): Last Call (CMP proof-of-possession)
Status:

I strongly agree with Tom Parker and David Kemp.  A CA that doesn't confirm
that the subscriber/subject of a certificate is the rightful holder and
actually in possession of the corresponding private key simply isn't
carrying out the necessary certification functionality.

I do agree with Denis Pinkas in one respect -- it is unfortunate that we
have come this far without more explicitly binding the signer's identity to
the signed document, whether in the protocol, or perhaps in an augmented
digital signature macro. As it stands today, if the certificate is detached
from the body of the message and lost, we know that someone signed the
document, but we don't know who.  We ought to fix that, but perhaps this
isn't the time for something so fundamental.  (But will it be, later on?)

Denis argues (apparently -- I wasn't there) that without such an application
binding, the relying party has no way of knowing whether or not the CA
actually confirmed proof of possession.  But that is also true with respect
to validating the identity or other attributes of the subject of the
certificate, and that is why we require CAs to perform some degree of due
diligence with respect to verifying identities (except in the particular
case of an anonymous certificate).

The point is that verifying the subject's identity AND proof of possession
of the private key is the sole reason  -- the raison d'etre -- for the
existence of a CA -- to bind the subject's identity to the private key, by
way of the public key.  

We should not overlook the fact that although the IETF is certainly not a
legislative body, the net effect of standards such as these will have almost
the force of law, because they will undoubtedly be cited as proof of
prevailing trade practices throughout the industry. Allowing POP to be
merely strongly recommended would have the very unfortunate effect of
seriously diluting the legal significance of a digital signature.

CA's MUST be required to verify proof of possession, and be held legally and
financially accountable, i.e., liable, to all relying parties for doing so.
Otherwise they aren't a CA, but something else entirely. This is something
that cannot be waived by agreement between the CA and the subscriber, or
made a matter of policy in some unread Certification Practice Statement,
because it goes to the heart of what a relying party expects.

Proof of possession must be MANDATORY for all PKIX-compliant CAs.

Bob

.>>> <[email-masked]> 10/07/97 03:22AM >>>>
>David Kemp said:
>
>>Now that we are in last call, I'd like a straw poll to measure the
>>degree of consensus for REQUIRING Proof-of-Possession for PKIX-compliant
>>CAs.  If there is general agreement, PoP can be returned to its
>>original REQUIRED status without delaying the RFC.
>
>I'd like to support him in his proposal to make POP mandatory. As I've 
>already emailed, I believe that the CA should be considered to be 
>actually making a binding between the owner and the private key. The
>certificate should be saying: "this name owns the private key corresponding
>to the public key in this certificate". Without POP, all the certificate 
>says is: "This name wishes to be associated with the public key in the
>certificate; the corresponding private key may however belong to someone 
>else" - very useful :-(. 
>
>I'm also concerned that individuals might be spoofed into
>presenting the wrong public key value to the CA when requesting a
>certificate, or the request may be tampered with en route, so that the
>malicious private key owner who substituted his/her own public key can 
>then masquerade as the individual. 
>
>If you (a CA) are making a guaranteed binding between two values, both 
>need to be authenticated for the guarantee to be worth anything.
>
>Tom Parker
>ICL
>UK.

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Tue, 07 Oct 1997 09:34:48 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: PKIX Cert and CRL profile bugs and queries
Status:

>>> Dean Povey <[email-masked]> 10/01/97 10:41PM >>>

>With regard to DN's, PKIX simply states that you should use X.501 standard 
>attributes.  However, I'd like to see some recommendations/constraints in
here 
>ala Peter Gutmann's X.509 style guide, namely:
>
>Implementations conforming to this profile should not generate Certificates

>and CRLs including DNs which use multivalued SETs of AVAs.  SETs are yucky
to 
>DER encode (you have to sort on tag value from memory), and I would expect 
>that this would make life easier for developers.  Implementations may still

>accept other Certs and CRLs which do have multivalue AVA sets (DER decoding
of 
>SETs is much easier than encoding).

Dean, I would have to respectfully disagree with you on this one.

The overarching principle is with respect to DNs is that they be
_distinguished_, i.e., that they be globally unambiguous.

Unfortunately, it is too late to get all of the mothers and fathers of the
world to agree to name their offspring in such a way as to include the exact
date/time/location of their birth, a message digest of the mother's maiden
name, and a birth certificate number to be used as a tie-breaker within
their given name. And despite Carl Ellison's desire to use public keys as
identifiers rather than names, we aren't yet to the point where we will
implant a microchip in the baby's butt for ease of identification.

That being the case, common names will undoubtedly continue to be all too
common to be unique, and so we have to face the fact that within an
organization, or within some geopolitical locality, there will be
duplicates.  It will therefore be necessary to used some kind of additional
qualifier, such as an employee serial number, or an arbitrary qualifier
assigned by a CA, to prevent ambiguity.

Unlike e-mail addresses, which are assigned by the whim of some
administrator, we cannot reasonably expect people to change their names to
minimize the "yuckiness" faced by a developer, and a multivalued AVA for the
final leaf of the naming tree is the least objectionable way of solving this
problem that we have discovered to date.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Tue, 07 Oct 1997 11:32:07 -0400
To: Russ Housley <[email-masked]>, [email-masked]
From: John Lowry <[email-masked]>
Subject: Re: Last Call (CMP proof-of-possession)
Status:

AMEN !

John Lowry

At 10:30 AM 10/7/97 -0400, Russ Housley wrote:
>I stongly believe that Proof-of-Possession should be REQUIRED!
>
>Russ
>
>>>Now that we are in last call, I'd like a straw poll to measure the
>>>degree of consensus for REQUIRING Proof-of-Possession for PKIX-compliant
>>>CAs.  If there is general agreement, PoP can be returned to its
>>>original REQUIRED status without delaying the RFC.
>>
>>I'd like to support him in his proposal to make POP mandatory. As I've 
>>already emailed, I believe that the CA should be considered to be 
>>actually making a binding between the owner and the private key. The
>>certificate should be saying: "this name owns the private key corresponding
>>to the public key in this certificate". Without POP, all the certificate 
>>says is: "This name wishes to be associated with the public key in the
>>certificate; the corresponding private key may however belong to someone 
>>else" - very useful :-(. 
>>
>>I'm also concerned that individuals might be spoofed into
>>presenting the wrong public key value to the CA when requesting a
>>certificate, or the request may be tampered with en route, so that the
>>malicious private key owner who substituted his/her own public key can 
>>then masquerade as the individual. 
>>
>>If you (a CA) are making a guaranteed binding between two values, both 
>>need to be authenticated for the guarantee to be worth anything.
>>
>>Tom Parker
>>ICL
>>UK.
>>
>
>

Date: Tue, 07 Oct 1997 11:30:01 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Last Call - Certificate Policy/Practices Framework
Status:

The revised document, draft-ietf-pkix-ipki-part4-02.txt, has been submitted
to the Internet Draft directories and will be available shortly.

Changes made since the July version are all editorial in nature, involving
some minor changes to terminology, some minor reordering of topics, and
some cosmetic improvements.

It is proposed that this document be published as an Informational RFC.
While no formal Last Call process is required, pkix members now have a last
opportunity to raise any concerns with this document, prior to its
publication.

Warwick

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

Date: Tue, 07 Oct 1997 10:30:40 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Last Call (CMP proof-of-possession)
Status:

I stongly believe that Proof-of-Possession should be REQUIRED!

Russ

>>Now that we are in last call, I'd like a straw poll to measure the
>>degree of consensus for REQUIRING Proof-of-Possession for PKIX-compliant
>>CAs.  If there is general agreement, PoP can be returned to its
>>original REQUIRED status without delaying the RFC.
>
>I'd like to support him in his proposal to make POP mandatory. As I've 
>already emailed, I believe that the CA should be considered to be 
>actually making a binding between the owner and the private key. The
>certificate should be saying: "this name owns the private key corresponding
>to the public key in this certificate". Without POP, all the certificate 
>says is: "This name wishes to be associated with the public key in the
>certificate; the corresponding private key may however belong to someone 
>else" - very useful :-(. 
>
>I'm also concerned that individuals might be spoofed into
>presenting the wrong public key value to the CA when requesting a
>certificate, or the request may be tampered with en route, so that the
>malicious private key owner who substituted his/her own public key can 
>then masquerade as the individual. 
>
>If you (a CA) are making a guaranteed binding between two values, both 
>need to be authenticated for the guarantee to be worth anything.
>
>Tom Parker
>ICL
>UK.
>

Date: Tue, 07 Oct 1997 10:03:20 -0400
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: PKIX-2 http
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Status:

Blake:

>> I propose that we define two types:
>> 
>> 	application/pkix-cert
>> 	application/pkix-crl
>
>These will have file extensions also, right?

Yes.  The draft specifiies ".cer" and ".crl".

>> I suggest the use of "pkix" insepad of "x509" so that an application can be
>> assured that the PKIX Certificate and CRL Profile is followed.  I suspect
>> that many programmers will implement to the PKIX profile, not the full
>> generality of X.509.  If I am wrong, we wasted a lot of time developing a
>> profile that will be ignored.
>
>I agree with this.
>
>> Anil, I do not see a reson to distinguish between user and CA certificates
>> in the MIME type.  In your message, you proposed separate MIME types.
>> Don't you think that the same software application will process the
>> certificate?  If so. then the signed information inside the certificate
>> should be used to determine if it is a CA certificate or a user
certificate.
>
>I think that from an implementor's point of view, having different MIME
>types might make processing easier, but checking the basicConstraints
>has to be the final word on the matter, or it seems that there would be
>a potential security problem.

Please explain how user cert and CA cert types would help an implementor.

Russ

Date: Mon, 06 Oct 1997 11:36:53 -0400
From: Dwight Arthur <[email-masked]>
To: [email-masked], George Capehart <[email-masked]>
CC: PKIX List <[email-masked]>
Subject: Re: Comments on [MANDATORY cert discovery capabiity]
Status:

Peter Williams wrote:
> George Capehart wrote:
>> Personally, I couldn't imagine the circumstances under which I'd
>> accept an ActiveX control that wanted to help me do *anything* with
>> a cert.  Boy, talking about opening one's kimono . . . wanna make a
>> copy of my private key(s) while your here? PKIs are all about trust
>> and the ActiveX security model is essentially: "Trust me on this."
>>  Sorry, I'm not quite there yet.  8-)
> <snip> I would agree that its important for any user/buyer of crypto
> to know and trust the source of his/her virtual machine, as much as
> the operating system. In some implementations, the viritual machine
> and OS are one and the same. The assurances, due to evaluation, of
> the OS kernel and reference monitor (e.g. NT) and reliance on
> CPU-based  privilege  mode enforcement can carry over to assure the
> VM to the same level as the OS,  to all intents and purposes. ...
> A site's firewall can scan the activeX control's java opcodes and
> ensure they meet "security requirements" beyond mere well-
> formedness, before the control enters the enclosure for execution.

This may be outside the domain of PKIX. I am concerned about the idea of
an applet or control that would (a) display some transaction on a
browser, (b) solicit the subject's consent to the transaction, and (c)
create a signed message confirming the transaction. Even if this were a
teansaction confined to a JAVA sandbox or equivalent
security-constrained environment, how would the subject be able to
verify that the transaction's terms and conditions as described onscreen
match those in the signed message? If a rogue applet adds on usurious
interest, outrageous handling fees, etc, how would the consumer
repudiate this message in light of the consumer's signed, dated, and
perhaps notarized signature? I believe that the degree of trust based on
the privacy of a private key is potentially eroded if externally
provided applets are able to create signatures without the subject's
knowledge of the content of the signed message.

It's an attractive idea, having a firewall scan for bad applets. But how
would you code a filter that would allow ePayment modules that fully
disclose the transaction's terms & conditions and deny those that add
undisclosed terms to a message?

From: <[email-masked]>
X400-Received: by mta bath.mail.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 7 Oct 1997 10:22:46 +0100
X400-Received: by mta fel01m2 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 7 Oct 1997 10:21:33 +0100
X400-Received: by mta bra01c1 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Tue, 7 Oct 1997 10:21:29 +0100
X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5-text); Relayed; Tue, 7 Oct 1997 10:22:50 +0100
Date: Tue, 7 Oct 1997 10:22:50 +0100
X400-Originator: [email-masked]
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;win0199 0000008800013239]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 13239
Alternate-Recipient: Allowed
To: " (David P. Kemp)" <[email-masked]>
Cc: [email-masked]
Subject: RE(2): Last Call (CMP proof-of-possession)
Status:

David Kemp said:

>Now that we are in last call, I'd like a straw poll to measure the
>degree of consensus for REQUIRING Proof-of-Possession for PKIX-compliant
>CAs.  If there is general agreement, PoP can be returned to its
>original REQUIRED status without delaying the RFC.

I'd like to support him in his proposal to make POP mandatory. As I've 
already emailed, I believe that the CA should be considered to be 
actually making a binding between the owner and the private key. The
certificate should be saying: "this name owns the private key corresponding
to the public key in this certificate". Without POP, all the certificate 
says is: "This name wishes to be associated with the public key in the
certificate; the corresponding private key may however belong to someone 
else" - very useful :-(. 

I'm also concerned that individuals might be spoofed into
presenting the wrong public key value to the CA when requesting a
certificate, or the request may be tampered with en route, so that the
malicious private key owner who substituted his/her own public key can 
then masquerade as the individual. 

If you (a CA) are making a guaranteed binding between two values, both 
need to be authenticated for the guarantee to be worth anything.

Tom Parker
ICL
UK.

From: Ingmar Camphausen <[email-masked]>
Date: Mon,  6 Oct 97 17:35:05 +0200
To: IETF PKIX mailinglist <[email-masked]>
Subject: Component to use to build a certificate chain?
Reply-To: [email-masked]
Priority: normal
Status:

Having read the recent versions of Part I and Part II, I am still in  
doubt about the component(s) to use for the (automatic) construction of a  
certificate chain from within an application that does not have X.500 or  
LDAP support.

Suppose I have a PKIX conformant certificate issued by a CA that does  
not use the X.500 directory service as distribution medium for its  
certificates but, e.g., HTTP instead. Suppose further that I simply want  
to build a certificate chain to the "toplevel" issuing CA.

I have encountered three different components that -- at least in my  
perception -- might then serve for the construction of certificate chains  
for the verification of a certificate. I am not sure whether the drafts  
are ambiguous in this regard or whether I have missed a point somewhere  
(the latter being probably more likely ;-), so I would really welcome  
your comments on this.

My three "candidates" for the "links" within a certificate chain from a  
given certificate to a (possibly trusted) top-level CA's self-signed  
certificate are:

* the `authorityKeyId extension'

  as Peter Williams, in response to another question from me, pointed out:

  > The ability in X.509 to signal the cert's parent's chain
  > of certs was surely given over to the authorityKeyId
  > extension. A GeneralName there can also be a URI, and
  > could sensibly be a URL to a collection of certs for
  > that CA party (one for cert issuing, another for CRL
  > issuing, another for auth-cert issuing; and each of
  > which can be supported by its own path.)

* issuerAltName (despite Peter Williams' reply to my respective question)

  The following comment Tim Polk mailed in his note accompanying the
  PKIX Part1 draft 4:

  > I've attached an ASCII table summarizing the pointers to external
  > information in the PKIX certificate for this draft. The table
  > does not appear in the draft. It is intended to assist you as you
  > review draft 4. I think we can provide all the information needed
  > to validate a path through the certificate - can you think of
  > anything I've missed?
  [...]
  > Summary of "pointers to external information" in Part 1 certificate.
  [...]
  > |------------------------------------------------------------------|
  > | issuerAltName  |   certificates whose subject is the issuer of   |
  > |                |   this certificate; used to build paths. URI    |
  > |                |  specifies scheme and object (object implied    |
  > |                |  for mailto)                                    |
  > |------------------------------------------------------------------|

* the `authorityInfoAccess' extension

  as described in the second half of 4.2.2.1 in
  draft-ietf-pkix-ipki-part5-00.txt)

  > This profile defines an object identifier to obtain a description of
  > the CAs that have issued certificates superior to the CA that issued
  > the certificate containing this extension.  The referenced CA Issuers
  > description is intended to aid certificate users in the selection of
  > a certification path that terminates at a point trusted by the
  > certificate user.  The syntax of the referenced CA Issuers
  > description will be defined in PKIX Part 2. [...]
  [...]
  > The authorityInfoAccess extension may be included in a PKCS 7
  > encapsulation as an X.501 ATTRIBUTE. This attribute can then be
  > used to locate certificates automatically rather than include
  > the certificates directly.

So which component of an X.509v3 certificate would a PKIX-conformant CA  
use to help all those implementations build the certification path that  
do neither support X.500 nor LDAP and hence must rely on certificate  
retrieval via, e.g. HTTP or FTP?

BTW: The 3rd paragraph of 4.2.2.1 contains:

>    This profile defines an object identifier for the On-line Certificate
>    Status Protocol (OCSP) that will be defined in PKIX Part 2.  When
                      ~~~~                                ~~~~~~

Isn't that reference outdated? draft-ietf-pkix-ipki2opp-03 does not
contain the OCSP any more as far as I could see.

(Maybe either the "PKIX Part <n>" titles could be added to *all* of the
PKIX drafts, or the references within the drafts be made more precise?)

	Ingmar Camphausen

__________________________________________________________________
Internet : [email-masked]
Phone    : ++49 / (0)30 / 34 63 - 73 57
Fax      : ++49 / (0)30 / 34 63 - 83 57
Address  : Research Institute for Open Communication Systems
           GMD FOKUS, Kaiserin-Augusta-Allee 31, D-10589 Berlin, Germany

Date: Mon, 6 Oct 1997 10:36:10 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Last Call (CMP proof-of-possession)
Status:

Around the Memphis IETF, it was suggested that the Certificate Management
Protocol be modified so that CAs are not required to check that an 
End Entity actually owns the keypair being certified.  The current
wording in section 2.3 is:

  "A given CA/RA is free to choose whether or not to enforce Proof of
   Possession in its certification exchanges (i.e., this may be a policy
   issue).  However, it is STRONGLY RECOMMENDED that CAs/RAs enforce
   POP because ..."

Denis Pinkas objected to making POP mandatory for CAs because relying
parties have no way to ensure that CAs have actually enforced this
requirement.  He noted that application protocols must provide the
binding between identity information and private keys for each
message/transaction/connection in order to allow the relying party to
verify the binding.

While I agree 100% with Denis that application protocols should provide
runtime Proof of Possession, I disagree with the notion that CMP
should not also require Proof of Possession at certification time.
This is not simply a matter of individual CA policy; any CA which
will certify the binding between an End Entity and a public key without
requiring the EE to demonstrate that (s)he actually owns the keypair
is arguably not performing a meaningful Certification function at all,
and should not be deemed PKIX-compliant.

As I recall, there was general agreement within the working group that
(at least) until runtime binding is ubiquitous over all certificate-using
applications/protocols, CAs must perform certification-time binding.
But no one wanted to hold up progress on the standard over the issue,
so PoP was watered down from "REQUIRED" to "STRONGLY RECOMMENDED".

Now that we are in last call, I'd like a straw poll to measure the
degree of consensus for REQUIRING Proof-of-Possession for PKIX-compliant
CAs.  If there is general agreement, PoP can be returned to its
original REQUIRED status without delaying the RFC.

Date: Sun, 05 Oct 1997 21:15:24 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: ISC Meeting Notice
Cc: [email-masked]
Status:

For the information of pkix readers...

IMPORTANT - All attendees *must* respond with their intention to
participate.  Because we are meeting in Federal buildings, the Capitol
police need a list of all attendees a week before the meeting.  Anyone not
on the list will *not* be allowed in.

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

Please correspond with:
  Michael S. Baum, Esq.
  One Alewife Center, Suite 350
  Cambridge, MA 02140 USA
  V: +1 617.661.1234
  F: +1 617.661.0716
  E: [email-masked]

Subject: INFORMATION SECURITY COMMITTEE MEETING NOTICE - OCTOBER 16-18, 1997

Dear Committee Member and Prospective Members:

You are cordially invited to participate in a meeting of the Information
Security Committee, Section of Science & Technology, American Bar
Association, on Thursday-Saturday, October 16-18, 1997, in Washington DC.
The Committee will continue its advancement of public key infrastructure
legal and control issues, and will include further work on CA
accreditation, commercial key escrow guidelines, PKI evidentiary issues,
digital signature legislative initiatives, and CA / user liability, among
other matters.

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

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

Sincerely, 

Michael S. Baum 
Chair, Information Security Committee 
Section of Science & Technology, ABA 
--------------- 
INFORMATION SECURITY COMMITTEE
Section of Science & Technology, ABA
October 16-18, 1997

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

October 16, 1997  Thursday - Capitol Hill
 8:30- 9:00   Greetings, administrative matters 
 9:00- 9:30   Introductions, meeting logistics, general announcements 
 9:30-10:30   Updates by Work Groups; 
10:30-12:00   WG breakouts
12:00-13:00   Lunch with the Congressional Internet Caucus
13:00-17:00   WG breakouts
17:00-???     Watering hole discussions; possible continuation of WG meetings

October 17, 1997 Friday
 8:30-09:00   Breakfast, et cetera
 9:00-09:30   Administration Update- 
              Bruce McConnell, Office of Management and Budget
 9:30-12:00   Breakout sessions; Legislative WG conference call
12:00-13:00   Lunch speakers: Judge B. Paul Cotter will speak on the 
                  ANSI X.12 electronic filing standard
13:00-17:00   Breakout sessions

October 18, Saturday
 8:30-09:00   Breakfast, et cetera. 
 9:00-12:00   WG wrap-ups;
12:00-13:00   Lunch speaker/Discussion
13:00-14:30   WG presentations
14:30-15:00   Path forward; wrap-up

Information Security Committee
Washington, DC MEETING DETAILS
October 16-18, 1997

Members are urged to participate in one of the work groups that will be
presenting/meeting during the ISC's meeting. Please contact Ruven Schwartz,
Esq. ([email-masked]) for further information. 

**Accreditation Work Group 
Contacts:Chas Merrill, Esq. ([email-masked])
         Rick Hornbeck ([email-masked])
         Lynn McNulty ([email-masked]) 

The Accreditation Work Group (About 50 technologists and attorneys in three
sections: Process, Technical Standards, and Legal and Business Standards)
will continue work on its draft document, "Accreditation: Evaluation of CAs
and PKI", with a view toward distributing a draft on the Internet for
industry comments shortly after the end of the year.

**Addendum Work Group 
Contacts:Joseph Alhadeff, Esq. ([email-masked])
         Christine Axsmith ([email-masked])
         Robert Ball ([email-masked])

The Addendum Work Group will continue drafting a digital signature trading
partner agreement -- integrating the principles of the Digital Signature
Guidelines and current work on PKI and CA accreditation concerns, and
developing additional practical commentary for this model form of
electronic commerce agreement.

**Evidentiary Work Group 
Contacts:Gary Fresen, Esq. ([email-masked])
         Stan Kurzban, Esq. ([email-masked]) or 
         Serge Parisien, Esq. ([email-masked]) 

The Evidentiary Work Group will continue its drafting of the judicial
tutorial and report on its coordination activities with record management
standards authorities.  The working group members will also assist the
other working groups on their evidentiary issues.

**Key Recovery Work Group (KEWG) 
Contacts:Emily Frye, Esq. ([email-masked]) 
         Dwight Olson, Esq. ([email-masked]) 

The KRWG concentrates its efforts in two ways.  First, it monitors proposed
legislation and regulations, both here and abroad, that address key
recovery.  The KRWG offers comments where it thinks they would be
appropriate.  The KRWG's larger work is a document addressing the framework
and operation of a key recovery center.  Work is in the advanced outline
stage and will focus on fleshing out draft text.

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

The Liability Work Group will continue its work with the Accreditation
Group on the liability issues, including preparing liability policy
statements and also suitable clauses for inclusion in  PKI/CA-user and
PKI/CA cross-certification agreements. 

It will also continue its analyses of the liability of application software
providers, and for other (non-digital signature, non-confidentiality
encryption) applications of public key cryptography.  

Finally, it will consider technical methods of solving the legal problem of
binding relying parties.

**Digital Signatures Laws & Regulations 
Contacts:Kenneth Allen, Esq. ([email-masked])
         Dan Greenwood, Esq. ([email-masked])
         Dale Juffernbruch, Esq. ([email-masked])

The Legislative and Regulatory Working Group will hold its periodic
conference call, to discuss updates to legislation and regulation regarding
electronic authentication.  The Leg/Reg Working Group would also like to
continue to explore the relationship between legislation in this area and
accreditation of Certification Authorities; further pursue the evidentiary
effects of electronic authentication, and discuss litigation, to the extent
any exists.

The dress for the meeting is business attire.

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

Meeting Location:

  October 16:
     The Capitol Building - room HC5
     lunch - The Rayburn Building - room B369

  October 17:
     Transportation Dept 400 7th St SW (L'Enfant Plaza).  Rooms 6244 - 6248

  October 18:
     Longworth House Office Building - Room 1539

Meals: There will be a $25 fee for lunch on Thursday (with the Internet
Caucus).

Lodging: Call Gibb Travel for discounted fares on local hotels (Loews
L'Enfant Plaza, Hyatt Regency Capitol, and others).  They will have a range
of prices available, tell them if you have a specific price range in mind.
Mention the ABA Information Security Committee.
Gibb's number is 617-353-0595 or 800-541-9949

RSVP: Please confirm your intention to participate to Ann Kowalsky, Section
Manager, Section of Science and Technology ([email-masked]) as soon
as possible.  IMPORTANT - All attendees *must* respond with their intention
to participate.  Because we are meeting in Federal buildings, the Capitol
police need a list of all attendees a week before the meeting.  Anyone not
on the list will *not* be allowed in.

See you in Washington.

PS - It has turned out that Congress has decided to take their vacation the
same week that our meeting has been scheduled.  This action was taken after
we had scheduled the meeting.  As a result, there will be no members of
Congress on the Hill during our meeting.  One positive aspect of this is
that Congressional staff members will have more of their time free to join
us during the Internet Caucus lunch and will be able to spend more time
discussing the issues. 

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

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

From: Dean Povey <[email-masked]>
To: [email-masked]
Subject: More ASN.1 bugs
Date: Mon, 06 Oct 97 11:30:22 +1000
Status:

The ASN.1 for the CertificatePolicies extension in the body does not match the 
ASN.1 in the appendix.  The text in the body seems correct.

Cheers.

-- 
+----------------------------------------+-------------------------------+
| Dean Povey,                            |  Email: [email-masked]     |
| Research Scientist, Security Unit,     |  Phone: +61 7 3864 2799       | 
| CRC for Distributed Systems Technology |  Fax:   +61 7 3864 1282       |
+----------------------------------------+-------------------------------+

From: Dean Povey <[email-masked]>
To: [email-masked]
Subject: A few more ASN.1 bugs
Date: Mon, 06 Oct 97 11:40:49 +1000
Status:

Oops, I forgot to check.  In the body of the text on the CertificatePolicies
extension, the definition of id-qt is syntactically incorrect should be:

id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }

This DOES appear in the appendix :-) 

-- 
+----------------------------------------+-------------------------------+
| Dean Povey,                            |  Email: [email-masked]     |
| Research Scientist, Security Unit,     |  Phone: +61 7 3864 2799       | 
| CRC for Distributed Systems Technology |  Fax:   +61 7 3864 1282       |
+----------------------------------------+-------------------------------+

From: <[email-masked]>
Comments: Authenticated sender is <[email-masked]>
To: [email-masked]
Date: Sun, 5 Oct 1997 08:28:48 +0000
Subject: How can unsubscribe this list?
Priority: normal
Status:

thanks.
My email :  [email-masked]
            [email-masked]
            lijun<[email-masked]>
Homepage :  http://members.tripod.com/~lijun/index.htm
            http://www.geocities.com/Eureka/Park/5818
            http://lijun.home.ml.org
            http://www.geocities.com/WallStreet/3689/ 
Tel      :  (8623)62800001-3269,3270 (Office)
            (8623)62828300,62903703  (Home)  
Addr     :  Computer Center,ICBC,No.1,North Road,
            NanPing, ChongQing, China, 400060

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: PKIX-2 http
Date: Fri, 3 Oct 1997 17:20:06 -0700
Status:

On Thursday, October 02, 1997 1:46 PM, Russ Housley
[SMTP:[email-masked]] wrote:
> I propose that we define two types:
> 
> 	application/pkix-cert
> 	application/pkix-crl

These will have file extensions also, right?

> I suggest the use of "pkix" insepad of "x509" so that an application can be
> assured that the PKIX Certificate and CRL Profile is followed.  I suspect
> that many programmers will implement to the PKIX profile, not the full
> generality of X.509.  If I am wrong, we wasted a lot of time developing a
> profile that will be ignored.

I agree with this.

> Anil, I do not see a reson to distinguish between user and CA certificates
> in the MIME type.  In your message, you proposed separate MIME types.
> Don't you think that the same software application will process the
> certificate?  If so. then the signed information inside the certificate
> should be used to determine if it is a CA certificate or a user certificate.

I think that from an implementor's point of view, having different MIME
types might make processing easier, but checking the basicConstraints
has to be the final word on the matter, or it seems that there would be
a potential security problem.

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

Reply-To: "Peter Williams" <[email-masked]>
From: "Peter Williams" <[email-masked]>
To: <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: PKIX-2 http
Date: Fri, 3 Oct 1997 11:41:59 -0700
Status:

-----Original Message-----
From: Russ Housley <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Friday, October 03, 1997 4:53 AM
Subject: Re: PKIX-2 http

>Anil and Peter:
>
>We need to agree the MIME type for returning an http resource, and I
>suspect that the ones we select will be used by Trevor in the e-mial
document.
>
>I propose that we define two types:
>
> application/pkix-cert
> application/pkix-crl
>
>I suggest the use of "pkix" insepad of "x509" so that an application can be
>assured that the PKIX Certificate and CRL Profile is followed.  I suspect
>that many programmers will implement to the PKIX profile, not the full
>generality of X.509.  If I am wrong, we wasted a lot of time developing a
>profile that will be ignored.

application/pkix-cert|crl; [version=1|2|3...]

People will still specialise the http response with custom headers if
they want to specialise PKIX, or overload its meaning, note. There
is nothing one can or should do about this.

The suggestion of allow the optional version field is to note
that pkix profile will inevitably evolve its conformance
rules as deployment knowledge os ptaoed/

--------
Analysis:-

When a *user* uses a http-post method to accomplish cert
publication to the directories as part of PKIX-3, Im assuming
that when using ftp, they transfer using
file  name foo.crt. When they use
http-post, they use application/pkix-cert as a
element of the mime multipart msg specified
in RFC xxxx  for file uploads. Note, where
the URL referenced causes post-processing,
the http server would actually publish this in whatever
mechanism implied by the post-processing mechanism.
(e.g. see Microsoft Content Replication Service use
of http-post to post-process and distribute content to
mirrors, etc.)

The URL (or ftp access point)  to which users publish will be part of the
PKIInfo distributed by PKIX-3 processes

I dont believe any of this analysis needs to go into the
document; but we do need to understand here that
this use is expected of the mime types when considering
their selection and procedures for use.

>
>Anil, I do not see a reson to distinguish between user and CA certificates
>in the MIME type.  In your message, you proposed separate MIME types.
>Don't you think that the same software application will process the
>certificate?  If so. then the signed information inside the certificate
>should be used to determine if it is a CA certificate or a user
certificate.
>
>Russ
>
>

Date: Fri, 03 Oct 1997 10:24:10 -0700
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: Russ Housley <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: PKIX-2 http
Status:

Russ Housley wrote:
> 
> Anil and Peter:
> 
> We need to agree the MIME type for returning an http resource, and I
> suspect that the ones we select will be used by Trevor in the e-mial
> document.
> 
> I propose that we define two types:
> 
>         application/pkix-cert
>         application/pkix-crl
> 
> I suggest the use of "pkix" insepad of "x509" so that an application
> can be
> assured that the PKIX Certificate and CRL Profile is followed.  I
> suspect
> that many programmers will implement to the PKIX profile, not the full
> generality of X.509.  If I am wrong, we wasted a lot of time
> developing a
> profile that will be ignored.
> 
> Anil, I do not see a reson to distinguish between user and CA
> certificates
> in the MIME type.  In your message, you proposed separate MIME types.
> Don't you think that the same software application will process the
> certificate?  If so. then the signed information inside the
> certificate
> should be used to determine if it is a CA certificate or a user
> certificate.
> 
> Russ

I'd suggest getting input from the current practitioners of this
kind of thing, particularly engineers at Netscape and Microsoft.

The MIME types I suggested were chosen because they are what is currently
in use, but my main point was to discourage use of a generic
(non-)type like "application/octet-string", which would definitely
not go over well.

In current implementations, the separate mime types are used to trigger 
different "importing" behavior.  I agree that it is possible to distinguish
CA and user certificates based on content later in the handling code.

It is not always as easy to distinguish end-entity certificates that
are intended for use by the importing entity and those for other entities
with whom the implementation must communicate (e.g. by secure e-mail).

One feasible scheme involves checking whether the public component matches
one of the private keys known by the implementation for the present
user, but I believe current implementations are using yet another mime type
to distinguish these.

This avoids the issue of whether the implementation already has or will
later have the key.  I think that nothing precludes proper treatment in both cases.

In short I don't object to Russ's suggestion, but one should
ask people who are doing this kind of thing already.

--a.

-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:[email-masked]
http://www.StructuredArts.com

From: "Carl Binding"<[email-masked]>
To: [email-masked]
Date: Fri, 3 Oct 1997 13:44:06 +0100
Subject: References for sha-1With RSAEncryption
Status:

In Internet Public Key Infrastructure PartI: X.509 Certificate & CRL
profile <draft-ietf-pkix-part1-05.txt>, dated July 30,
1997 I seem not to be able to find the bibliographical reference for
sha-1WithRSAEncryption (pg 51)
Although we can make an educated guess, the doc should probably be
completed.
Similarly, the [OIW] reference does not seem to be included in the
refernces on pg 56.
Regards,
Carl Binding
ps: it might well be that I've an old version of the doc?!

Date: Thu, 02 Oct 1997 16:46:06 -0400
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: PKIX-2 http
Cc: [email-masked]
Status:

Anil and Peter:

We need to agree the MIME type for returning an http resource, and I
suspect that the ones we select will be used by Trevor in the e-mial document.

I propose that we define two types:

	application/pkix-cert
	application/pkix-crl

I suggest the use of "pkix" insepad of "x509" so that an application can be
assured that the PKIX Certificate and CRL Profile is followed.  I suspect
that many programmers will implement to the PKIX profile, not the full
generality of X.509.  If I am wrong, we wasted a lot of time developing a
profile that will be ignored.

Anil, I do not see a reson to distinguish between user and CA certificates
in the MIME type.  In your message, you proposed separate MIME types.
Don't you think that the same software application will process the
certificate?  If so. then the signed information inside the certificate
should be used to determine if it is a CA certificate or a user certificate.

Russ

From: Dean Povey <[email-masked]>
To: Andrew Csinger <[email-masked]>
Cc: [email-masked]
Subject: Re: PKI Modeling 
Date: Fri, 03 Oct 97 11:18:24 +1000
Status:

>-----BEGIN PGP SIGNED MESSAGE-----
>
>Building on my dissertation in User Modelling (1995), I've been 
>involved
>in the formation of this kind of effort at Xcert for over a year now 
>and
>would be interested in corresponding.  We've long believed that 
>there's a
>whole lot more to PKI than certificates and CRLs...
>
>Andrew
>
>
>At 14:59 9/29/97 -0400, Robert W. Shirey wrote:
>>Request For Correspondence
>>
>>I'd like to exchange ideas and information with people who are 
>involved in
>>or thinking about building a quantitative, analytical model of PKI 
>for the
>>purpose of estimating costs and predicting other aspects of system
>>performance.
>>
>>Regards, -Rob-
>>

Are you both aware of a paper entitled "Modelling a Public-Key Infrastructure", by Ueli Maurer [Proc. European Symposium on Research in Computer Security (ESORICS' 96), http://www.inf.ethz.ch/personal/maurer/publications.html]

Here is the abstract:

"A global public-key infrastructure (PKI), components of which are emerging in the near future, is a prerequisite for security in distributed systems and for electronic commerce. The purpose of this paper is to propose an approach to modelling and reasoning about a PKI from a user Alice's point of view. Her view, from which she draws conclusions about the authenticity of other entities' public keys and possibly the trustworthiness of other entities, consists of statements about which public keys she believes to be authentic and which entities she believes to be trustworthy, as well as a collection of certificates and recommendations obtained or retrieved from the PKI. The model takes into account recommendations for the trustworthiness of entities. Furthermore, it includes confidence values for statements and can exploit arbitrary certification structures containg multiple intersecting certification paths to achieve a higher confidence value than for any single certification p!
ath. Confidence values are measured on a continuous scal between 0 and 1 and, in contrast to previous work in this area, are interpreted as probabilities in a well-defined random experiment"

This appears to be modelling of trust, rather than cost/performance that you are suggesting, but may give you some ideas.

-- 
+----------------------------------------+-------------------------------+
| Dean Povey,                            |  Email: [email-masked]     |
| Research Scientist, Security Unit,     |  Phone: +61 7 3864 2799       | 
| CRC for Distributed Systems Technology |  Fax:   +61 7 3864 1282       |
+----------------------------------------+-------------------------------+

Date: Thu, 02 Oct 1997 21:43:01 -0400
From: George Capehart <[email-masked]>
Organization: Capehart Associates
To: [email-masked]
CC: [email-masked]
Subject: Re: Comments on [MANDATORY cert discovery capabiity]
Status:

Peter Williams wrote:
> 

[snip]

> An activeX control may be implemented using java, and imply
> all the assurances of the users java virtual machine.

True, but the operative word is "may."  'Softies around here generally
eschew Java for more esoteric languages like Visual Basic for their OCXs
. . .

> 
> I would agree that its important for any user/buyer of crypto
> to know and trust the source of his/her virtual machine,
> as much as the operating system. In some implementations,
> the viritual machine and OS are one and the same. The
> assurances, due to evaluation, of the OS kernel
> and reference monitor (e.g. NT) and reliance on
> CPU-based  privilege  mode enforcement can carry over to
> assure the VM to the same level as the OS,  to all intents and
> purposes.
> 
> This is a distinguishing factor of OS and non-OS
> java clients for serious users of actual  internet security
> technology.
> 
> A site's firewall can scan the activeX control's java
> opcodes and ensure they meet "security requirements"
> beyond mere well-formedness, before the control enters
> the enclosure for execution. And this is not theory...

Hmmmm, couple of thoughts.  First, not *every* potential recipient of
one of these controls is behind a firewall.  Secondly, the implication
is that firewall/proxy vendors need to implement a "streaming class
loader" that is smart enough to know to look for some very specific
things . . . for instance, that a control/applet is snooping for
wallets, keyrings, passwords, etc.  As an exercise, I;ve been trying to
design one of those that would provide reasonable throughput in my head
. . .  gave me a major headache.  ;-)  This ia *really* an interesting
problem!  Thanks for bringing it up.

rgds,

gwc

Date: Thu, 02 Oct 1997 12:22:47 -0700
To: "Robert W. Shirey" <[email-masked]>, [email-masked]
From: Andrew Csinger <[email-masked]>
Subject: Re: PKI Modeling
Status:

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

Building on my dissertation in User Modelling (1995), I've been 
involved
in the formation of this kind of effort at Xcert for over a year now 
and
would be interested in corresponding.  We've long believed that 
there's a
whole lot more to PKI than certificates and CRLs...

Andrew

At 14:59 9/29/97 -0400, Robert W. Shirey wrote:
>Request For Correspondence
>
>I'd like to exchange ideas and information with people who are 
involved in
>or thinking about building a quantitative, analytical model of PKI 
for the
>purpose of estimating costs and predicting other aspects of system
>performance.
>
>Regards, -Rob-
>
>[email-masked], Phone 703-284-4641, Reception 284-4600, Fax 284-
2766
>Robert W. Shirey, GTE Internetworking - Mail Stop 30/12B2, Suite 
1200
>1300 North Seventeenth Street, Arlington, Virginia   22209-3801   
USA
>

--------------------------------------------------------------
Andrew Csinger, President                  Xcert Software Inc.
1001-701 West Georgia Street    P.O. Box 10145, Pacific Centre
Vancouver, B.C.                                 Canada V7Y 1C6
tel:     1-604-640-6210                fax:     1-604-640-6220
http://www.xcert.com                  email: [email-masked]
           **** Internet Security Technologies ****
"Every  information  object known to modern man is a candidate 
 for PKI-based ACL"                          - Young Etheridge
--------------------------------------------------------------

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: last call spoof?
Date: Thu, 2 Oct 1997 09:38:32 -0400
Status:

Hi,

>----------
>From: 	Stephen Kent[SMTP:[email-masked]]
>Sent: 	Wednesday, October 01, 1997 6:49 PM
>To: 	[email-masked]
>Subject: 	last call spoof?
>
>Well, it finally happened.  Somebody pretending to be your WG co-chair sent
>out a last call message for a series of documents yesterday, including
>several documents that are not yet ready for last call.  How annoying!  The
>real list of documents ready for last call appears below.
...
>	- PKIX Part 3, on certificate management protocols
>(draft-ietf-pkix-ipki3cmp-04.txt) has also been debated extensively and I
>would like progress this document to last call.

With respect to Part 3 (PKIX-CMP), my plan is this.  Since the Last Call
was issued yesterday (Oct. 1), and since Working Group Last Call periods
last for two weeks, I will collect all comments received by the end of
the day on Oct. 14th and issue a revised draft ("...-05.txt") on the
morning of Oct 15th.  This is the draft that will go to IETF-wide Last
Call (during which time those who issued comments should check that I
haven't missed anything).

Hoping for a quiet 2 weeks...   :-)

Carlisle.

Date: Thu, 02 Oct 1997 09:38:24 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: Comments on [MANDATORY cert discovery capabiity]
Cc: [email-masked], [email-masked]
Status:

>>On other matters, you may want to clean up fast:-
>>
>>the oids for:-
>>
>>     - Example InfoTypeAndValue contents include, but are not limited to:
>>       --   { CAProtEncCert    = { xx }, Certificate                     }
>>       --   { SignKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier }
>>       --   { EncKeyPairTypes  = { xx }, SEQUENCE OF AlgorithmIdentifier }
>>       --   { PreferredSymmAlg = { xx }, AlgorithmIdentifier             }
>>       --   { CAKeyUpdateInfo  = { xx }, CAKeyUpdAnnContent              }
>>         --   { CurrentCRL       = { xx }, CertificateList
>
>Probably the fastest way to get numbers reserved here is to assign these
>under the "id-pkix" arc.  I see (from the most recent Part 1 draft) that
>this is defined to be:
>
>   id-pkix  OBJECT IDENTIFIER  ::= 
>      { iso(1) identified-organization(3) dod(6) internet(1) security(5)
>mechanisms(5) pkix(7) }
>
>and that under this, the values 1, 2, 3, and 48 have already been
>assigned.  I hereby propose that we reserve
>{ id-pkix 4 } for "id-pkix-cmp-infoType" and, under this, reserve the
>values 1 through 6 for the examples given above (in the order given).
>
>Are there any objections to this (specifically, has { id-pkix 4 } been
>assigned already for something I didn't notice)?  I see that IANA has
>Russ Housley's name beside "id-pkix".  Russ, does this mean that I can
>simply ask you to reserve these numbers, or do I have to go through IANA
>anyway (from what I understand, I think the former is the case)?

Carlisle:

The IANA has delegated the management of the PKIX Arc to me.  I will gladly
assign the OIDs that you request.  In fact, I will post the current
contents of the registry to the list so that everyone knows the current
state of it.

Russ

Date: Thu, 02 Oct 1997 09:40:06 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: PKIX OIDs
Status:

This is a dump of the OIDs currently assigned in the PKIX OID Arc.

Russ

= = = = = = = = = = =

-- PKIX Object Identifier Registry
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 
            dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

-- PKIX Arcs
id-pe   OBJECT IDENTIFIER ::= { id-pkix 1 }    -- private certificate
extensions
id-qt   OBJECT IDENTIFIER ::= { id-pkix 2 }    -- policy qualifier types
id-kp   OBJECT IDENTIFIER ::= { id-pkix 3 }    -- extended key purpose
identifiers
id-it   OBJECT IDENTIFIER ::= { id-pkix 4 }    -- CMP information types
id-ad   OBJECT IDENTIFIER ::= { id-pkix 48 }   -- access descriptors

-- pkix private extensions
id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }

-- policyQualifierIds for Internet policy qualifiers
id-qt-cps              OBJECT IDENTIFIER ::= { id-qt 1 }
id-qt-unotice          OBJECT IDENTIFIER ::= { id-qt 2 }

-- extended key purpose identifiers
id-kp-serverAuth       OBJECT IDENTIFIER ::= { id-kp 1 }
id-kp-clientAuth       OBJECT IDENTIFIER ::= { id-kp 2 }
id-kp-codeSigning      OBJECT IDENTIFIER ::= { id-kp 3 }
id-kp-emailProtection  OBJECT IDENTIFIER ::= { id-kp 4 }
id-kp-ipsecEndSystem   OBJECT IDENTIFIER ::= { id-kp 5 }
id-kp-ipsecTunnel      OBJECT IDENTIFIER ::= { id-kp 6 }
id-kp-ipsecUser        OBJECT IDENTIFIER ::= { id-kp 7 }
id-kp-timeStamping     OBJECT IDENTIFIER ::= { id-kp 8 }

-- CMP information types
id-it-caProtEncCert    OBJECT IDENTIFIER ::= { id-it 1 }
id-it-signKeyPairTypes OBJECT IDENTIFIER ::= { id-it 2 }
id-it-encKeyPairTypes  OBJECT IDENTIFIER ::= { id-it 3 }
id-it-preferredSymmAlg OBJECT IDENTIFIER ::= { id-it 4 }
id-it-caKeyUpdateInfo  OBJECT IDENTIFIER ::= { id-it 5 }
id-it-currentCRL       OBJECT IDENTIFIER ::= { id-it 6 }

-- access descriptors for authority info access extension
id-ad-ocsp             OBJECT IDENTIFIER ::= { id-ad 1 }
id-ad-caIssuers        OBJECT IDENTIFIER ::= { id-ad 2 }

From: Dean Povey <[email-masked]>
To: [email-masked]
Subject: PKIX Cert and CRL profile bugs and queries
Date: Thu, 02 Oct 97 14:41:27 +1000
Status:

First a bug:
The OID for Diffie-Hellman parameters differs in the text of the document:

{ iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }

and the ASN.1 in the appendix:

{ iso(1) member-body(2) us(840) ansi-x942(10046) 1 }

Since this document is going to last call, I think someone needs to have a 
close read of the ASN.1 in the text and the appendicies to make sure they 
match (I'm not volunteering :-) ).

Next a query:
With regard to DN's, PKIX simply states that you should use X.501 standard 
attributes.  However, I'd like to see some recommendations/constraints in here 
ala Peter Gutmann's X.509 style guide, namely:

Implementations conforming to this profile should not generate Certificates 
and CRLs including DNs which use multivalued SETs of AVAs.  SETs are yucky to 
DER encode (you have to sort on tag value from memory), and I would expect 
that this would make life easier for developers.  Implementations may still 
accept other Certs and CRLs which do have multivalue AVA sets (DER decoding of 
SETs is much easier than encoding).

Also a recommendation that DNs include attributes from the set {common name, 
country, organization, organizational unit, state or province, street address, 
locality} would be useful. The profile should list the OIDs for these:

 ds             	ID   			::= {joint-iso-ccitt(2) 5}
 commonName 		OBJECT IDENTIFIER       ::= {ds 4 3}
 countryName 		OBJECT IDENTIFIER       ::= {ds 4 6}
 localityName 		OBJECT IDENTIFIER       ::= {ds 4 7}
 stateOrProvinceName 	OBJECT IDENTIFIER       ::= {ds 4 8}
 streetAddress 		OBJECT IDENTIFIER       ::= {ds 4 9}
 organizationName 	OBJECT IDENTIFIER       ::= {ds 4 10}
 organizationalUnitName OBJECT IDENTIFIER       ::= {ds 4 11}
  
This doesn't preclude the use of other attributes in the DN, just gives a 
recommended set which (among other things) are easy to convert to an RFC1779 
string representation.

Just my (rather belated) $0.02.

-- 
+----------------------------------------+-------------------------------+
| Dean Povey,                            |  Email: [email-masked]     |
| Research Scientist, Security Unit,     |  Phone: +61 7 3864 2799       | 
| CRC for Distributed Systems Technology |  Fax:   +61 7 3864 1282       |
+----------------------------------------+-------------------------------+

From: <[email-masked]>
Date: Wed, 01 Oct 1997 16:10:28 -0600
To: Stef Hoeben <[email-masked]>
Subject: Re: Last Call & idea for OCSP
Cc: [email-masked]
Status:

Stef--

Work on OCSP is proceeding.  A draft incorporating comments to date should
be available  for final review in about two weeks.

Regarding an incremental certificate validity list, a server could equally
well cache prior signed responses per certificate.  Sending back just that
response vs. a list of other valid certs that are potentially relevant
saves bandwidth.  One might also consider the use of the HTTP "Expires:"
header field to yield cacheing effects on the requestor's Web server.

--Mike

At 03:55 PM 10/1/97 +0200, you wrote:
>
>And the OCSP protocol?
>
>This may be an idea for that protocol, so the CA doesn't have
>to sign each answer separately (which takes quite some time):
>
>- The CA divides its certs in groups of say 100 or 500
>- When an OCSP_query for a cert C comes in:
>  * If the cert is not valid (revoked, expired, ...)
>    the CA replies with an ordinary OCSP-response.
>  * If the cert is valid, the CA makes a list of 
>    all valid certs that are in the same group as cert C.
>    The CA then signs this list together with the current
>    time and sends it to the requestor. That one must look
>    for his cert C in the list to assure C is valid.
>
>If another OSCP-query for a valid cert in the same group 
>as C comes in, within say a minute, the CA can simply
>send the same message as for cert C without having to
>sign anything.
>
>(This ressembles a bit the CRL functionality but CRL's
>may be much larger then this here.)
>
>(It's all based on Micalli's paper on the previous 
>RSA conference.)
>
>
>Don't know if it's no old news or not realistic ...
>
>Stef
>
>-------------------------------------------------------------------------
>[email-masked]            | All wiyht.
>Katholieke Universiteit Leuven               | Rho sritched
>Dept. Electrical Engineering-ESAT / COSIC    | mg kegtops
>K. Mercierlaan 94, B-3001 Heverlee, BELGIUM  | awound?
>tel. +32 16 32 10 73   fax. +32 16 32 19 86  |
>-------------------------------------------------------------------------
>
>
>

Date: Wed, 1 Oct 1997 18:49:33 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: last call spoof?
Status:

Well, it finally happened.  Somebody pretending to be your WG co-chair sent
out a last call message for a series of documents yesterday, including
several documents that are not yet ready for last call.  How annoying!  The
real list of documents ready for last call appears below.  PKIX Part 1 has
not yet been revised and thus is not yet ready, and PKIX Part 4 has not
been updated since Munich.  Upadates to both of these are expected in the
next two weeks, and we will begin last call for them at that time.
Finally, although PKIX Part 2 FTP/HTTP has just been posted, it does need
work to nail down the MIME content types and thus it too should not be in
last call yet.  I apologize for any undue confusion caused by the
preceeding last call message.

	- PKIX Part 2 has been split into several pieces.  The LDAP portion
(draft-ietf-pkix-ipki2opp-03.txt) is now under consideration and I've seen
no substantial comments on it, so let's go to last call on it.

	- PKIX Part 3, on certificate management protocols
(draft-ietf-pkix-ipki3cmp-04.txt) has also been debated extensively and I
would like progress this document to last call.

Steve

Date: Wed, 1 Oct 1997 16:59:41 -0400
To: [email-masked] (David P. Kemp)
From: Stephen Kent <[email-masked]>
Subject: Re: PKIX1 definition of a certificate
Cc: [email-masked]
Status:

David,

	Let's just view the text in question as a typo ;-) and get on with
this.

Steve

Date: Wed, 01 Oct 1997 14:13:32 -0700
From: Peter Williams <[email-masked]>
Reply-To: [email-masked]
Organization: VeriSign
To: Carlisle Adams <[email-masked]>
CC: ",[email-masked]'" <[email-masked]>
Subject: Re: Comments on [MANDATORY cert discovery capabiity]
Status:

Carlisle Adams wrote:

>  >and
> >
> >
> >     SinglePubInfo ::= SEQUENCE {      pubMethod    INTEGER {
> >               dontCare    (0),          x500        (1),          web
> >     (2)
> >
> >shoud include ldap
>
> I'm not sure what you mean here.  LDAP is not a publication method; it's
> a protocol.  All we really had in mind with this was "publish in an
> X.500 directory", or "publish on a web page", etc., with the "location"
> field giving more specific information, if desired.  Maybe the name
> "pubMethod" is not clear enough  --  suggestions?

Its nice to think of ldap as one of the protocols which implement
the X.500 Directory Abstract Service. Instead of OSI's DAP, ones
uses IPS's ldap. But this isn't real, perhaps. Effectively, ldap
is an access method for a distinct, non-X500 telematic service
which just happens to leverage off of much of
the X.500 models and objects.

The entire directory model of X.500 (as a publication method)
can be seen as distinct in its location, knowlege and distribution model.  ldap

has more interesting modes, perhaps more suited
to repository-oriented certificate publication than was simple
X.500 DAS.

Perhaps name the method "asid". Note Im not
trying to be difficult here; just positive about the asid/ldap
viewed as a distinct  "publication method". (Note, I assume "web"
implies any URL protocol, other than ldap.)

Peter.

M. Wahl
 A CIP-based Centroid Exchange for LDAP
         draft-ietf-find-ldapc-00.txt

"2. Introduction

   This document defines a centroid-based index for a subtree of the
   directory. It is carried by an update MIME object.

   The supplier server is an LDAP server which masters or shadows a naming
   context.  In this protocol it acts as a "simple CIP leaf server".

   The supplier server will at intervals mail the update to the consumer
   server.  The consumer server is a different LDAP server with a subordinate
   or cross reference to the supplier server, which makes use of this update
   to determine how to route queries.

   The centroid-based index consists of processed attribute values from
   entries. The supplier may send the complete attribute values, or if this
   would violate data protection laws, only approximate match codes of values,
   which are nonreversible.  As more processing is performed on values, the
   size of the index is reduced, as is its usefulness to the consumer.

   The specification allows for both total and incremental updates to be sent.

   This specification is intended for "push" environments, where there are many

   (tens of thousands) of naming contexts, and a small number (dozens) of
   index consumers.  The naming contexts are as a whole static, however it is
   desirable or changes to take effect rapidly."

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Peter Williams
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 19 (TEXT/R*ch) (0001C183)

Date: Wed, 01 Oct 1997 13:02:48 -0700
From: Peter Williams <[email-masked]>
Reply-To: [email-masked]
Organization: VeriSign
To: Ben Laurie <[email-masked]>
CC: George Capehart <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Comments on [MANDATORY cert discovery capabiity]
Status:

Ben Laurie wrote:

> Peter Williams wrote:
> > A site's firewall can scan the activeX control's java
> > opcodes and ensure they meet "security requirements"
> > beyond mere well-formedness, before the control enters
> > the enclosure for execution. And this is not theory...
>
> Sounds more like marketing hype than theory to me. Who claims to be able
> to do this?
>

It may be marketing hype; fact and fiction oftenmerge when someone is trying
to sell your something
or otherwise seek to make you think the way which suits them.

http://www.microsoft.com/security/swdownload2.htm is what
I was thinking of.

Admittedly, on this page, there is not the vendor who claimed to scan
the java opcodes (versus merely exclude java applets).And I cant quite
remember the name of the product  (it may have been the
http://www.finjan.com/products/html/surfingate.html Surfingate product.)

This scenario doesn't seem unreasonable however. All java VMs scan
the opcodes during class loading. Moving the scanning/type-checking
to a firewall doesnt sound problematic. Adding scanning
rules beyond java saftey rules to enforce  local-acls of class references
or other parameters is just "programming". Again does not sound
beyond what java licensee's value-added securityManagers do anyway
on modern java end-systems!

Followups to mail, please. Getting way off legitimate PKIX topics.

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

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Peter Williams
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 18 (TEXT/R*ch) (0001C181)

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Comments on [MANDATORY cert discovery capabiity]
Date: Wed, 1 Oct 1997 15:51:55 -0400
Status:

Hi Peter,

[Russ, there's a question for you below.]

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Tuesday, September 30, 1997 8:05 PM
>To: 	Carlisle Adams
>Cc: 	[email-masked]'
>Subject: 	Re: Comments on [MANDATORY cert discovery capabiity]
>
>Carlisle,
>
>OK. I am going away from this exchange with two beliefs:
>
>(a) no Appendix B message (set) specified needs to be necessarily
>sent, or handled if received; there is no state or sequence of messages
>(sets) implied
>to be conforming. PKIInformation need not even be sent, and can
>be ignored in any case by an EE.

This is correct.  The model is that *if* you want to achieve a
particular function using a PKIMessage, Appendix B specifies the message
to use, including the particular fields and their semantics.  It is not
essential that you use a PKIMessage to achieve any function (though
using other methods is likely to hurt interoperability).

Having said that, however, I think normal procedure will be that if a
request message is sent, the protocol engine will expect a response
message (or error), and will then reply with a confirm message.  In
other words, I suspect most implementations will have "state" within a
message set.  "State" *between* different message sets is not implied by
Appendix B.

>(b) If an EE  implementation wants to ignore PKIInfo, it they can; if they
>want to ignore InitReq they can. They can deem information and
>initialization to have occured by other means, and go straight to cr
>whose protection mechanism may use signing (MSG_SIG_ALG ).

Again correct.  Note, however, that even if initialization has occurred
by other means, the resulting certificate must be verifiable by the CA
that is being sent the "cr" message (otherwise it won't be able to
verify the signature protection on the request).

Furthermore, we need to be a bit cautious about doing initialization "by
other means".  This is, of course, allowed, but keep in mind that
getting EEs securely initialized into the PKI is one of the most
important steps in creating a PKI that can be trusted and used.  The
"basic authenticated scheme" in PKIX-CMP provides a solid, implementable
method for doing this properly.  Many other proposals (and current
practices) that I've seen are not quite as careful.  I'm not so
enthusiastic about EEs getting initialized elsewhere and then using
PKIX-CMP for subsequent certificate management functions...

>--------
>
>On other matters, you may want to clean up fast:-
>
>the oids for:-
>
>     - Example InfoTypeAndValue contents include, but are not limited to:
>       --   { CAProtEncCert    = { xx }, Certificate                     }
>       --   { SignKeyPairTypes = { xx }, SEQUENCE OF AlgorithmIdentifier }
>       --   { EncKeyPairTypes  = { xx }, SEQUENCE OF AlgorithmIdentifier }
>       --   { PreferredSymmAlg = { xx }, AlgorithmIdentifier             }
>       --   { CAKeyUpdateInfo  = { xx }, CAKeyUpdAnnContent              }
>         --   { CurrentCRL       = { xx }, CertificateList

Probably the fastest way to get numbers reserved here is to assign these
under the "id-pkix" arc.  I see (from the most recent Part 1 draft) that
this is defined to be:

   id-pkix  OBJECT IDENTIFIER  ::= 
      { iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) }

and that under this, the values 1, 2, 3, and 48 have already been
assigned.  I hereby propose that we reserve
{ id-pkix 4 } for "id-pkix-cmp-infoType" and, under this, reserve the
values 1 through 6 for the examples given above (in the order given).

Are there any objections to this (specifically, has { id-pkix 4 } been
assigned already for something I didn't notice)?  I see that IANA has
Russ Housley's name beside "id-pkix".  Russ, does this mean that I can
simply ask you to reserve these numbers, or do I have to go through IANA
anyway (from what I understand, I think the former is the case)?

>and
>
>
>     SinglePubInfo ::= SEQUENCE {      pubMethod    INTEGER {
>               dontCare    (0),          x500        (1),          web
>     (2)
>
>shoud include ldap

I'm not sure what you mean here.  LDAP is not a publication method; it's
a protocol.  All we really had in mind with this was "publish in an
X.500 directory", or "publish on a web page", etc., with the "location"
field giving more specific information, if desired.  Maybe the name
"pubMethod" is not clear enough  --  suggestions?

>     B1. General Rules for interpretation of these profiles.
>      1.Where OPTIONAL or DEFAULT fields are not mentioned in individual
>        profiles, they should be absent from the relevant message.
>        Mandatory fields are not mentioned if they have an obvious value
>        (e.g., pvno).
>
>State whether a receiver doing type checking has  reasonable basis for
>rejecting
>an inbound msg which has a present, not-mentioned-by-profile OPTIONAL or
>DEFAULT
>field.

Yes, a receiver that implements only the PKIX-CMP mandatory stuff should
not expect any such field and may freely reject such an inbound message
as syntactically incorrect.  A receiver that goes beyond the mandatory
might be able to syntactically parse the message properly, but may or
may not actually understand (i.e., support) these fields; hence, it too
may reject such an inbound message or it may return a more satisfying
(to the sender!) response (depending on how far beyond the mandatory it
has implemented).

I will try to clarify this point.

>You may want to revisit, and ensure its generically compatible with the
>actual
>profiles for the various operations.
>
>      9.All PKI message exchanges in this profile require a PKIConfirm
>        message to be sent by the initiating entity.  This message is not
>        included in many of the profiles given below since its body is
>        NULL and its header contents are clear from the context.  Any
>        authenticated means can be used for the protectionAlg (e.g.,
>        password-based MAC, if shared secret information is known, or
>     signature).

I see what you mean.  I will check this and fix up where necessary.

>Thats all I have. I can say that only with these recent dialogues do I,
>for one, mostly understand the subtleties. Hopefully lots
>of implementors now intepret things similarly, and multi-vendor
>interworking will actually happen!

I hope so too!

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

Date: Wed, 1 Oct 1997 15:42:58 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKIX1 definition of a certificate
Status:

> From: Stephen Kent <[email-masked]>
>
> Peter,
> 
> 	The defintion cited is not appropriate since, as you note, it
> unenecssarily and inappropriately brings encrytpion into the picture.  Our
> definition should cite only the use of a signature algorithm to bind a
> public key to a set of attributes, specifically the attributes defined in
> the spec (including extensions).

I agree that the definition is inappropriate, but since X.509 still
drags encryption into the picture, PKIX has little choice but to follow
suit.

Since DSA has been around at least since 1993, it seems that there would
have been ample opportunity to amend X.509 to accommodate both reversible
(RSA) and irreversible (DSA) signature algorithms.  But the current X.509
still defines signatures in terms of encryption:

  ENCRYPTED-HASH { ToBeSigned } ::= BIT STRING ( CONSTRAINED BY {
    -- must be the result of applying a hashing procedure to the
    -- DER-encoded octets of a value of -- ToBeSigned -- and then
    -- applying an encipherment procedure to those octets -- } )

  SIGNATURE { ToBeSigned } ::= SEQUENCE {
    algorithmIdentifier AlgorithmIdentifier,
    encrypted           ENCRYPTED-HASH { ToBeSigned }}

ISO/ITU folks:  Is there any chance that the 2001 version of X.509
could acknowledge the existence of irreversible signature algorithms,
since it's apparently too late to get them into the 1997 version?

Out of necessity, users of DSS certificates have been forced to
interpret the words "encrypted" and "encipherment" as including
mathematical techniques which have no inverse "decryption" operation,
even though such doublespeak is repugnant to those who expect standards
to be written in clear and unambiguous language.

No wonder there's so much confusion about making a distinction between
signature and encryption keys.

Date: Wed, 01 Oct 1997 20:08:47 +0100
From: Ben Laurie <[email-masked]>
Organization: A.L. Digital Ltd.
To: [email-masked]
CC: George Capehart <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Comments on [MANDATORY cert discovery capabiity]
Status:

Peter Williams wrote:
> A site's firewall can scan the activeX control's java
> opcodes and ensure they meet "security requirements"
> beyond mere well-formedness, before the control enters
> the enclosure for execution. And this is not theory...

Sounds more like marketing hype than theory to me. Who claims to be able
to do this?

Cheers,

Ben.

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

Date: Wed, 01 Oct 1997 10:47:33 -0700
From: Peter Williams <[email-masked]>
Reply-To: [email-masked]
Organization: VeriSign
To: George Capehart <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Comments on [MANDATORY cert discovery capabiity]
Status:

George Capehart wrote:

> > (Take this example figuratively, only.)
>
> Interesting thought, though.  Personally, I couldn't imagine the
> circumstances under which I'd accept an ActiveX control that wanted to
> help me do *anything* with a cert.  Boy, talking about opening one's
> kimono . . . wanna make a copy of my private key(s) while your here?
> PKIs are all about trust and the ActiveX security model is essentially:
> "Trust me on this."  Sorry, I'm not quite there yet.  8-)

An activeX control may be implemented using java, and imply
all the assurances of the users java virtual machine.

I would agree that its important for any user/buyer of crypto
to know and trust the source of his/her virtual machine,
as much as the operating system. In some implementations,
the viritual machine and OS are one and the same. The
assurances, due to evaluation, of the OS kernel
and reference monitor (e.g. NT) and reliance on
CPU-based  privilege  mode enforcement can carry over to
assure the VM to the same level as the OS,  to all intents and
purposes.

This is a distinguishing factor of OS and non-OS
java clients for serious users of actual  internet security
technology.

A site's firewall can scan the activeX control's java
opcodes and ensure they meet "security requirements"
beyond mere well-formedness, before the control enters
the enclosure for execution. And this is not theory...

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Peter Williams
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 17 (TEXT/R*ch) (0001C17F)

Date: Wed, 01 Oct 1997 10:53:13 -0700
From: Peter Williams <[email-masked]>
Reply-To: [email-masked]
Organization: VeriSign
To: [email-masked]
CC: [email-masked]
Subject: Re: PKIX-2 http
Status:

Anil R. Gangolli wrote:

> Peter Williams wrote:
> >
> > We do need to agree the mime type for returning an http resource,
> > still.
> >
> > I note that the introduction also allows the http mechanism to be used
> > for pushing the cert/CRL to the directory. Perhaps its best
> > that the objects we are pulling/pushing are indeed simply
> > regarded as files. When pulling a .crt file the object
> > is labelled application/octet-string. When pushing files,
> > the file objects are transferred in a classical http push operation's
> > multipart mime type.
> >
>
> Most HTTP clients that I know about use the mime type to
> dispatch to type-specific handling code.  Using a generic
> mime type like application/octet-string precludes this.
>
> For certificates and CRLs browsers do and will likely continue
> to use MIME types that indicate both the type and often
> an application-specific usage.
>
> Examples are:
>
> application/x-x509-user-cert
> application/x-x509-ca-cert

Anil,

you and I and Microsoft have all suggested this; but there
is just silence. Somehow, this simple statement just
will not get written down and become what we
all use. I know not why this issue fails to get
resolved.

In lieu of other progress, I fell back to what I
hoped I could get actually written, and I started
with the simplest type of all....

application/octet-string; name=foo.crt
application/octet-string; name=foo.crl

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Peter Williams
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 16 (TEXT/R*ch) (0001C17E)

From: <[email-masked]>
Date: Wed, 1 Oct 97 13:33:28 EDT
To: [email-masked]
Subject: unsubscribeStatus:

Date: Wed, 01 Oct 1997 10:12:35 -0700
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: [email-masked]
CC: [email-masked]
Subject: Re: PKIX-2 http
Status:

Peter Williams wrote:
> 
> We do need to agree the mime type for returning an http resource,
> still.
> 
> I note that the introduction also allows the http mechanism to be used
> for pushing the cert/CRL to the directory. Perhaps its best
> that the objects we are pulling/pushing are indeed simply
> regarded as files. When pulling a .crt file the object
> is labelled application/octet-string. When pushing files,
> the file objects are transferred in a classical http push operation's
> multipart mime type.
> 

Most HTTP clients that I know about use the mime type to
dispatch to type-specific handling code.  Using a generic
mime type like application/octet-string precludes this.

For certificates and CRLs browsers do and will likely continue
to use MIME types that indicate both the type and often
an application-specific usage.

Examples are:

application/x-x509-user-cert
application/x-x509-ca-cert

 
-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:[email-masked]
http://www.StructuredArts.com

Organization: ESAT, K.U.Leuven, Belgium
Date: Wed, 1 Oct 1997 15:55:49 +0200 (MET DST)
From: Stef Hoeben <[email-masked]>
To: [email-masked]
Subject: Re: Last Call & idea for OCSP
Status:

> (draft-ietf-pkix-ipki2opp-03.txt) is now under consideration and I've seen
> no substantial comments on it. The FTP and HTTP portion,
> (draft-ietf-pkix-opp-ftp-http-00.txt), is also posted, and the only
> comments I've seen there are relatively minor ones re choice of MIME
> context types.  I'd like to move forward on this one as well.

And the OCSP protocol?

This may be an idea for that protocol, so the CA doesn't have
to sign each answer separately (which takes quite some time):

- The CA divides its certs in groups of say 100 or 500
- When an OCSP_query for a cert C comes in:
  * If the cert is not valid (revoked, expired, ...)
    the CA replies with an ordinary OCSP-response.
  * If the cert is valid, the CA makes a list of 
    all valid certs that are in the same group as cert C.
    The CA then signs this list together with the current
    time and sends it to the requestor. That one must look
    for his cert C in the list to assure C is valid.

If another OSCP-query for a valid cert in the same group 
as C comes in, within say a minute, the CA can simply
send the same message as for cert C without having to
sign anything.

(This ressembles a bit the CRL functionality but CRL's
may be much larger then this here.)

(It's all based on Micalli's paper on the previous 
RSA conference.)

Don't know if it's no old news or not realistic ...

Stef

-------------------------------------------------------------------------
[email-masked]            | All wiyht.
Katholieke Universiteit Leuven               | Rho sritched
Dept. Electrical Engineering-ESAT / COSIC    | mg kegtops
K. Mercierlaan 94, B-3001 Heverlee, BELGIUM  | awound?
tel. +32 16 32 10 73   fax. +32 16 32 19 86  |
-------------------------------------------------------------------------

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>
Subject: AuthorityInfoAccess
Date: Wed, 1 Oct 1997 08:28:05 -0400
Status:

The ASN.1 for this extension is different between the text and the ASN.1
module in Appendix A.  Which is correct?

Also note the ASN.1 in the text is not syntactically correct; it should be:

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

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

Regards,
Rich

Date: Wed, 01 Oct 1997 06:57:30 -0400
From: George Capehart <[email-masked]>
Organization: Capehart Associates
To: [email-masked]
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Comments on [MANDATORY cert discovery capabiity]
Status:

Peter Williams wrote:
> 

[snip]

> Im imagining in a Microsoft implementation of this PKIInformation exchange
> in which  the activeX enrollment control, which implements the
> more elaborate B.x profiles using RSA, would be supplied to the EE in response
> to
> PKInformation object {ms 1}. Where the CA is not a activeX
> CA (i.e. it sends an error msg), then that same browser needs to fall
> back to non-activeX mechanisms by syncing on initialization information they
> can agree on (i.e. that which the CA optionally provides) and using a
> barebones PKIX-3 minimal, default implementation with DSA cipherSuites, say.
> 
> (Take this example figuratively, only.)

Interesting thought, though.  Personally, I couldn't imagine the
circumstances under which I'd accept an ActiveX control that wanted to
help me do *anything* with a cert.  Boy, talking about opening one's
kimono . . . wanna make a copy of my private key(s) while your here? 
PKIs are all about trust and the ActiveX security model is essentially: 
"Trust me on this."  Sorry, I'm not quite there yet.  8-)
-- 
/*
 *  George Capehart     email:  [email-masked]     phone:  +1 704.866.9151
 *
 *  PGP ID:  George W. Capehart <[email-masked]>
 */

Date: Wed, 1 Oct 1997 00:00:01 -0700
From: Operator - SUNTAN <[email-masked]>
To: [email-masked], [email-masked]
Subject: Monthly reminder (IETF-PKIX list)
Status:

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].