Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id OAA07139 for ; Tue, 30 Sep 1997 14:04:11 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 30 Sep 1997 21:06:16 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id TAA19246; Tue, 30 Sep 1997 19:07:27 -0700 Received: from zafu.bbn.com by suntan.tandem.com (8.6.12/suntan5.970212) for id TAA19243; Tue, 30 Sep 1997 19:07:26 -0700 Received: from [128.89.30.22] (ARA22.BBN.COM [128.89.30.22]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id WAA13365; Tue, 30 Sep 1997 22:08:49 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Sep 1997 21:20:46 -0400 To: Mike Smith From: Stephen Kent Subject: Re: Certificate Suspension Cc: ietf-pkix@tandem.com Status: Mike, A good CA revocation policy can specify an authentication mechanism used to verify that a revocation request is genuine. The examples you cite don't exhibit such a mechanism. I hate to see this justification for the suspension facility, but I'm beyond complaining about this CRL feature. Steve Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA05093 for ; Tue, 30 Sep 1997 12:45:24 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 30 Sep 1997 19:47:28 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id RAA03122; Tue, 30 Sep 1997 17:04:18 -0700 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id RAA03112; Tue, 30 Sep 1997 17:04:16 -0700 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id RAA08198; Tue, 30 Sep 1997 17:03:43 -0700 (PDT) Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id RAA10654; Tue, 30 Sep 1997 17:03:41 -0700 (PDT) Message-ID: <343193E3.26AE3BC4@verisign.com> Date: Tue, 30 Sep 1997 17:05:55 -0700 From: Peter Williams Reply-To: peter@verisign.com Organization: VeriSign X-Mailer: Mozilla 4.02 [en]C-DIAL (Win95; U) MIME-Version: 1.0 To: Carlisle Adams CC: "'ietf-pkix@tandem.com'" Subject: Re: Comments on [MANDATORY cert discovery capabiity] References: Content-Type: multipart/mixed; boundary="------------B8773A43A854E01D8AB6E4EB" Status: Carlisle,:
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.

(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 ).

Just set me right if they are wrong.

--------

On other matters, you may want to clean up fast:-

the oids for:-

-- { CurrentCRL = { xx }, CertificateList

and

shoud include ldap

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.

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

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!

Peter.

Hi Peter,

>----------
>From: Peter Williams[SMTP:peter@verisign.com]
>Sent: Tuesday, September 30, 1997 3:46 PM
>To:    Carlisle Adams
>Cc:    'ietf-pkix@tandem.com'
>Subject:       Re: Comments on [MANDATORY cert discovery capabiity]
>
>Carlisle Adams wrote:
>
>> But, to answer your question, the CA must respond with an error message
>> (a response that should be expected by any EE that goes outside the
>> mandatory spec.). This does not hamper the EE's abilities or future
>> actions in any way, because it can always send another request with an
>> empty SET (to get whatever the CA does know), or get the required
>> information in any other fashion (recall that PKIMessages do not need to
>> be used for this information exchange), or decide that it really didn't
>> need this particular information after all and simply send an InitReq
>> message.
>
>Should we mandate that an EE be required to send a PKIInformation "with
an empty set of requirements" msg if it gets an error msg to its
>previous attempt
>to synchronise PKI information before entering the initialization or
>certification states wheree real work gets done?

I'm not sure why this would need to be mandated...

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

I would assume that falling back to guaranteed interoperable messages
would be normal behavior for any well-designed protocol engine.
Bringing up my previous analogy again, if one side can't communicate
with the other using 3-DES / RC5 / IDEA / CAST-128, it should fall back
to DES because it knows this will work. Do we need to mandate such
common-sense behavior? I don't think so -- as I said, the EE may
decide to do the information exchange in some out-of-band way or may
decide it doesn't really need the information. Also, protocol
implementors seem pretty familiar with this style of protocol (where
certain messages, options, algorithms, etc., are mandated so that
interoperability can be guaranteed), so it seems unnecessary to mandate
this particular flowchart ("try this; if it doesn't work, go with
that").

Your example is interesting, but I'm a bit surprised by your conclusion.
I thought you were keen to mandate fewer things rather than more... ?

--------------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
--------------------------------------------

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 15 (TEXT/R*ch) (0001C140) Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id LAA03821 for ; Tue, 30 Sep 1997 11:52:59 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 30 Sep 1997 18:55:04 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id RAA04513; Tue, 30 Sep 1997 17:11:36 -0700 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id RAA04509; Tue, 30 Sep 1997 17:11:34 -0700 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id RAA08264; Tue, 30 Sep 1997 17:11:04 -0700 (PDT) Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id RAA10880; Tue, 30 Sep 1997 17:11:02 -0700 (PDT) Message-ID: <3431959C.C706A52B@verisign.com> Date: Tue, 30 Sep 1997 17:13:16 -0700 From: Peter Williams Reply-To: peter@verisign.com Organization: VeriSign X-Mailer: Mozilla 4.02 [en]C-DIAL (Win95; U) MIME-Version: 1.0 To: ietf-pkix@tandem.com Subject: PKIX-2 http Content-Type: multipart/mixed; boundary="------------3AFF91AE40F01BD93F1B7809" Status: 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. 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 14 (TEXT/R*ch) (0001C13F) Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id LAA02572 for ; Tue, 30 Sep 1997 11:06:09 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 30 Sep 1997 18:08:13 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id PAA22388; Tue, 30 Sep 1997 15:52:39 -0700 Received: from zafu.bbn.com by suntan.tandem.com (8.6.12/suntan5.970212) for id PAA22379; Tue, 30 Sep 1997 15:52:38 -0700 Received: from [128.89.30.5] (ARA5.BBN.COM [128.89.30.5]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id SAA06341 for ; Tue, 30 Sep 1997 18:53:59 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Sep 1997 18:53:29 -0400 To: ietf-pkix@tandem.com From: Stephen Kent Subject: Last Call Status: Folks, We have several revised I-Ds that have been posted recently and I'd like to begin the WG last call process. We discussed which I-Ds seemed to be ready for progression during the Munich meeting, as reported in the meeting minutes distributed to this list immediately after the meeting. New versions of several of the documents have been posted and are now ready for a final review. - PKIX Part 1, X.509 certificate and CRL syntax, (draft-ietf-pkix-ipki-part1-05.txt), has been in process for a long while. Although I saw a couple of minor syntax changes proposed recently, I assume that we're ready to close the books on this one, modulo resolution of the proposed changes by the authors. - 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. 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. - PKIX Part 3, on certificate management protocols (draft-ietf-pkix-ipki3cmp-04.txt) has also been debated extensively and I would progress this document as well. - PKIX Part IV, certificatecertification practices framework, (draft-ietf-pkix-ipki-part4-01.txt ) is up for review as an Informational RFC, not standards track. Although not strictly necessary, I would like to get Wg approval to forward this document to the IESG as well. Please send any comments on these I-Ds to the list so that we can determine if any further changes need to to made prior to forwarding the documents to the IESG for IETF-wide last call. Steve Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id JAA00009 for ; Tue, 30 Sep 1997 09:31:25 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 30 Sep 1997 16:33:29 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id NAA29819; Tue, 30 Sep 1997 13:33:26 -0700 Received: from gatekeeper.entrust.com by suntan.tandem.com (8.6.12/suntan5.970212) for id NAA29815; Tue, 30 Sep 1997 13:33:24 -0700 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCCDBD.BE52ED30@mail.entrust.com>; Tue, 30 Sep 1997 16:27:28 -0400 Message-ID: From: Carlisle Adams To: "'peter@verisign.com'" Cc: "'ietf-pkix@tandem.com'" Subject: RE: Comments on [MANDATORY cert discovery capabiity] Date: Tue, 30 Sep 1997 16:27:26 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: Hi Peter, >---------- >From: Peter Williams[SMTP:peter@verisign.com] >Sent: Tuesday, September 30, 1997 3:46 PM >To: Carlisle Adams >Cc: 'ietf-pkix@tandem.com' >Subject: Re: Comments on [MANDATORY cert discovery capabiity] > >Carlisle Adams wrote: > >> But, to answer your question, the CA must respond with an error message >> (a response that should be expected by any EE that goes outside the >> mandatory spec.). This does not hamper the EE's abilities or future >> actions in any way, because it can always send another request with an >> empty SET (to get whatever the CA does know), or get the required >> information in any other fashion (recall that PKIMessages do not need to >> be used for this information exchange), or decide that it really didn't >> need this particular information after all and simply send an InitReq >> message. > >Should we mandate that an EE be required to send a PKIInformation "with an empty set of requirements" msg if it gets an error msg to its >previous attempt >to synchronise PKI information before entering the initialization or >certification states wheree real work gets done? I'm not sure why this would need to be mandated... >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. I would assume that falling back to guaranteed interoperable messages would be normal behavior for any well-designed protocol engine. Bringing up my previous analogy again, if one side can't communicate with the other using 3-DES / RC5 / IDEA / CAST-128, it should fall back to DES because it knows this will work. Do we need to mandate such common-sense behavior? I don't think so -- as I said, the EE may decide to do the information exchange in some out-of-band way or may decide it doesn't really need the information. Also, protocol implementors seem pretty familiar with this style of protocol (where certain messages, options, algorithms, etc., are mandated so that interoperability can be guaranteed), so it seems unnecessary to mandate this particular flowchart ("try this; if it doesn't work, go with that"). Your example is interesting, but I'm a bit surprised by your conclusion. I thought you were keen to mandate fewer things rather than more... ? -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA30979 for ; Tue, 30 Sep 1997 08:20:47 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 30 Sep 1997 15:22:51 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id MAA22503; Tue, 30 Sep 1997 12:45:07 -0700 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id MAA22498; Tue, 30 Sep 1997 12:45:05 -0700 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id MAA03958; Tue, 30 Sep 1997 12:44:27 -0700 (PDT) Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA28810; Tue, 30 Sep 1997 12:44:27 -0700 (PDT) Message-ID: <3431572B.B20523A2@verisign.com> Date: Tue, 30 Sep 1997 12:46:51 -0700 From: Peter Williams Reply-To: peter@verisign.com Organization: VeriSign X-Mailer: Mozilla 4.02 [en]C-DIAL (Win95; U) MIME-Version: 1.0 To: Carlisle Adams CC: "'ietf-pkix@tandem.com'" Subject: Re: Comments on [MANDATORY cert discovery capabiity] References: Content-Type: multipart/mixed; boundary="------------3F137448F0F4C603EB33E377" Status: Carlisle Adams wrote: > But, to answer your question, the CA must respond with an error message > (a response that should be expected by any EE that goes outside the > mandatory spec.). This does not hamper the EE's abilities or future > actions in any way, because it can always send another request with an > empty SET (to get whatever the CA does know), or get the required > information in any other fashion (recall that PKIMessages do not need to > be used for this information exchange), or decide that it really didn't > need this particular information after all and simply send an InitReq > message. Should we mandate that an EE be required to send a PKIInformation "with an empty set of requirements" msg if it gets an error msg to its previous attempt to synchronise PKI information before entering the initialization or certification states wheree real work gets done? 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.) 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 13 (TEXT/R*ch) (0001C10E) Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id DAA23440 for ; Tue, 30 Sep 1997 03:25:45 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 30 Sep 1997 10:27:48 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA22921; Tue, 30 Sep 1997 07:13:58 -0700 Received: from gatekeeper.entrust.com by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA22914; Tue, 30 Sep 1997 07:13:57 -0700 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCCD88.B3982430@mail.entrust.com>; Tue, 30 Sep 1997 10:07:47 -0400 Message-ID: From: Carlisle Adams To: "'Stef Hoeben'" Cc: "'ietf-pkix@tandem.com'" Subject: RE: questions about ipki3cmp-04.txt (fwd) Date: Tue, 30 Sep 1997 10:07:46 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: Hi Stef, >---------- >From: Stef Hoeben[SMTP:Stefan.Hoeben@esat.kuleuven.ac.be] >Sent: Tuesday, September 30, 1997 3:34 AM >To: ietf-pkix@tandem.com >Subject: questions about ipki3cmp-04.txt (fwd) > >Sorry to bother you all, but here are two questions >about the creation of certs (cmp draft): > >* a bit is said about CertReqContent and CertRepContent, >but I don't know in which case to use these messages >and what exactly is the difference with InitReqContent >and InitRepContent? A couple of people have asked this over the past few months so I tried to be a bit more explicit in this latest draft with the wording in Appendix B (specifically, B8 and B9). InitReq / InitRep are intended to be used when an EE is first getting initialized (i.e., just getting started in the system and requesting its first certificate), whereas CertReq / CertRep are intended to be used by EEs that are already initialized (i.e., they are already in the system and are requesting subsequent certificates). Supporting this is the fact that for InitReq / InitRep the protectionAlg can only be a MAC (based on a key derived from shared secret information) and for CertReq / CertRep the protectionAlg can be a MAC or a signature (since the EE may already have a valid verification certificate and is presumed to hold a valid copy of the CA's verification certificate). Syntactically there is very little difference between the two, except that InitReq allows the EE to send to the CA a protocol encryption key (this is to be used to encrypt the private key coming back to the EE, if centralized key generation was requested and is supported by the CA). >* for the Centralised scheme (2.2.2.1), the message sent >to the user is a CertRepContent or a InitRepContent, right? Yes (although since the centralized scheme is an initialization scheme, InitRep is semantically more appropriate). >Greetings, Stef > >PS I'd like to congratiulate Peter and Carlisle for > cheering up this list, I'm always looking forward > to reading their discussions. Thank you, but all the credit really should go to Peter... -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id DAA23186 for ; Tue, 30 Sep 1997 03:17:34 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 30 Sep 1997 10:19:37 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA21429; Tue, 30 Sep 1997 07:03:42 -0700 Received: from zionsbank.com by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA21422; Tue, 30 Sep 1997 07:03:41 -0700 Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Tue, 30 Sep 1997 08:02:27 -0600 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 30 Sep 1997 08:02:07 -0600 From: Mike Smith To: dwightarthur@mindspring.com, peter@verisign.com Cc: ietf-pkix@tandem.com Subject: Re: Certificate Suspension Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Status: Dwight: A CA may, in its own interest to limit liability, take a warning of a signing key compromise from a third party and suspend the suspected compromised signing key while confirming with the private key holder ("subscriber "in Utah) whether or not to revoke the private key. If the issue is not resolved in 24 hrs, then the key is revoked. In industries like yours, a "denial of service" attack would be easy if a trading entity was able to report a competitor's key as compromised then the CA would automatically revoke the competitor's key. If the CA did not revoke the reportedly compromised key when notified, then the CA would probably incur liability for NOT revoking if a compromised key is actually used for fraudulent purposes. Michael >>> Dwight Arthur 09/29/97 01:01PM >>> Peter Williams wrote: > The suspension action can be logically undone. > > A revocation action cannot be undone. > > If one advises a VISA bank that is possible that one has lost one's > visacard, then they can suspend its use (for three days most > issuing policies). When you find the card, account activity can be > resumed as if nothing had happened. <...> In the world of securities trading, where people profit on good news and bad but uncertainty causes panics, there is nothing more expensive than a transaction that can neither be cancelled nor completed. In this industry, I believe that suspensions will be deprecated and revocation used instead. -Dwight Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id UAA12098 for ; Mon, 29 Sep 1997 20:09:59 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 30 Sep 1997 03:12:02 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id AAA13402; Tue, 30 Sep 1997 00:35:10 -0700 Received: from barbar.esat.kuleuven.ac.be by suntan.tandem.com (8.6.12/suntan5.970212) for id AAA13392; Tue, 30 Sep 1997 00:35:08 -0700 Received: from dante (dante.esat.kuleuven.ac.be [134.58.66.131]) by barbar (version 8.8.5) for with SMTP id JAA17281; Tue, 30 Sep 1997 09:34:56 +0200 (METDST) Organization: ESAT, K.U.Leuven, Belgium Date: Tue, 30 Sep 1997 08:34:55 +0100 (MET) From: Stef Hoeben X-Sender: hoeben@dante To: ietf-pkix@tandem.com Subject: questions about ipki3cmp-04.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: Sorry to bother you all, but here are two questions about the creation of certs (cmp draft): * a bit is said about CertReqContent and CertRepContent, but I don't know in which case to use these messages and what exactly is the difference with InitReqContent and InitRepContent? * for the Centralised scheme (2.2.2.1), the message sent to the user is a CertRepContent or a InitRepContent, right? Greetings, Stef PS I'd like to congratiulate Peter and Carlisle for cheering up this list, I'm always looking forward to reading their discussions. Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA29906 for ; Mon, 29 Sep 1997 10:16:47 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 29 Sep 1997 17:18:48 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id OAA10317; Mon, 29 Sep 1997 14:54:39 -0700 Received: from gatekeeper.entrust.com by suntan.tandem.com (8.6.12/suntan5.970212) for id OAA10309; Mon, 29 Sep 1997 14:54:37 -0700 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCCD00.154FD9E0@mail.entrust.com>; Mon, 29 Sep 1997 17:49:50 -0400 Message-ID: From: Carlisle Adams To: "'peter@verisign.com'" Cc: "'ietf-pkix@tandem.com'" Subject: RE: Comments on [MANDATORY cert discovery capabiity] Date: Mon, 29 Sep 1997 17:49:48 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: Hi Peter, >---------- >From: Peter Williams[SMTP:peter@verisign.com] >Sent: Monday, September 29, 1997 4:47 PM >To: Carlisle Adams >Cc: 'ietf-pkix@tandem.com' >Subject: Re: Comments on [MANDATORY cert discovery capabiity] > >Carlisle Adams wrote: > >> Two comments here. Firstly, it is true that a requestor may ask for any >> number of particular things (the request is, after all, a SET of >> {OID,value} pairs). However, the only request that MUST be supported >> according to B.6 is the empty SET, which corresponds to "give me >> whatever information you think I need to know" (see 3.3.18). Thus, >> there is nothing explicit in the request that forces the CA to supply >> any particular piece of information. More relevant to your concern is >> the fact that B.6 currently mandates that the CA include the current CRL >> in the response. The thinking here was that the CA would have this >> information anyway (since it's the one that created the CRL) and an >> initializing EE would probably want to see this (it's a useful part of >> the start-up information). However, it doesn't really need to be >> mandatory, so I will change the top line of p.53 to "optionally present, >> with relevant value". [I assume this will make you happier.] > >(The CRL matter is news to me, and Ill have to think aboutwhy this CRL or >similar flow during initalization was possibly rationalised to be >*mandatory* in the first place... Are there any other mandatory objects >to be provided, btw?) It shouldn't have been "news to you", since it was in one of the excerpts you yourself quoted in your line of thinking in your previous post. As for why it was "possibly rationalised to be mandatory in the first place", I already answered that in the text above. As for other "mandatory objects to be provided", how many times do I have to say "look at Appendix B"? (That's what this appendix is there for!) In this case, B.6 says what must be present in the response message. >But to the protocol issue:- > >I'm contemplating the situation where as a value-added feature, a given >EE implementation presets the requested particular-options to include >"{private-oid 1}". This the vendors synced-up CA software will know how to handle. All >other vendors >software seem to be required to present error returns. Effectively, >the EE is locked down to a given vendor's system at initialization time & consequently thereafter, with a mere configuration option. >Normally, open >systems protocol extensibility schemes are designed not cause such raw >interworking failure when used. I don't really understand your concern here. Let's say there is a protocol somewhere that says DES is the mandatory algorithm (and everything else is optional). As a "value-added feature, a given EE implementation presets the requested particular-options" to be 3-DES, or IDEA, or RC5, or CAST-128. Does this mean it is "locked down to a given vendor's system ... with a mere configuration option"? Yes. Once you go outside the mandatory, you cannot guarantee interoperability. People seem to know and understand this aspect of protocol design very well. What, exactly, is your objection here? >My suggestion is that this element of service be amended to have >the EE set a "required" bit on a per-oid basis, to signal >that the reply must contain the requested information. By >default, a particular-option "required" bit is to be not-set i.e. the >per-item >request may be optionally satisfied by the responder. EEs are >expected to continue the enrollment protocol should the requested >(but not-required) option be returned empty. I have to admit that I can't see much value in modifying the protocol to allow EEs to say, "I'd like this information, but I don't really care if you send it to me or not." Instead of having a "required" bit, why not simply have EEs only ask for the information they really want (which is what we have already)? >Let me ask a direct question to have you clarify positively for >the case in question:- > >If EE sends a msg asking for information identified by {private-oid 1} >where {private-oid 1} is not an object known to the CA, may >the CA reply anyway with what it does know, and thereby enable >the EE to choose to continue on with the msg flow of the msg sequences >indicated in the part 4, and appendix B? >From the EE's point of view, there is no difference between an error message and the CA replying with what it does know (which doesn't include {private-oid 1}). In both cases the EE does not have what it asked for. Furthermore, in both cases the EE can subsequently send whatever PKIMessage it wants (i.e., an error message does not prevent it from sending an InitReq message at any time in the future -- did you think it did?). But, to answer your question, the CA must respond with an error message (a response that should be expected by any EE that goes outside the mandatory spec.). This does not hamper the EE's abilities or future actions in any way, because it can always send another request with an empty SET (to get whatever the CA does know), or get the required information in any other fashion (recall that PKIMessages do not need to be used for this information exchange), or decide that it really didn't need this particular information after all and simply send an InitReq message. -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id JAA28310 for ; Mon, 29 Sep 1997 09:08:12 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 29 Sep 1997 16:10:14 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id NAA27958; Mon, 29 Sep 1997 13:46:03 -0700 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id NAA27953; Mon, 29 Sep 1997 13:46:02 -0700 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id NAA19678; Mon, 29 Sep 1997 13:45:25 -0700 (PDT) Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id NAA07546; Mon, 29 Sep 1997 13:45:24 -0700 (PDT) Message-ID: <343013F3.FEE265F4@verisign.com> Date: Mon, 29 Sep 1997 13:47:47 -0700 From: Peter Williams Reply-To: peter@verisign.com Organization: VeriSign X-Mailer: Mozilla 4.02 [en]C-DIAL (Win95; U) MIME-Version: 1.0 To: Carlisle Adams CC: "'ietf-pkix@tandem.com'" Subject: Re: Comments on [MANDATORY cert discovery capabiity] References: Content-Type: multipart/mixed; boundary="------------7E2C3172FA2276C3177A6BB5" Status: Thanks for your reply. Carlisle Adams wrote: >> (...much of the "line of thinking" deleted to save space...) >> >> I note that a requestor may ask for any material indicated by the >> options supported in >> B.6, including those elements which seem (to me) to be one of the >> instantiations of 3.3.14 / 3.3.16 operations. > > Two comments here. Firstly, it is true that a requestor may ask for any > number of particular things (the request is, after all, a SET of > {OID,value} pairs). However, the only request that MUST be supported > according to B.6 is the empty SET, which corresponds to "give me > whatever information you think I need to know" (see 3.3.18). Thus, > there is nothing explicit in the request that forces the CA to supply > any particular piece of information. More relevant to your concern is > the fact that B.6 currently mandates that the CA include the current CRL > in the response. The thinking here was that the CA would have this > information anyway (since it's the one that created the CRL) and an > initializing EE would probably want to see this (it's a useful part of > the start-up information). However, it doesn't really need to be > mandatory, so I will change the top line of p.53 to "optionally present, > with relevant value". [I assume this will make you happier.] (The CRL matter is news to me, and Ill have to think aboutwhy this CRL or similar flow during initalization was possibly rationalised to be *mandatory* in the first place... Are there any other mandatory objects to be provided, btw?) But to the protocol issue:- I'm contemplating the situation where as a value-added feature, a given EE implementation presets the requested particular-options to include "{private-oid 1}". This the vendors synced-up CA software will know how to handle. All other vendors software seem to be required to present error returns. Effectively, the EE is locked down to a given vendor's system at initialization time & consequently thereafter, with a mere configuration option. Normally, open systems protocol extensibility schemes are designed not cause such raw interworking failure when used. There may be a more acceptable requirement for the EE to say, please send information X, but please do not return an error just because you do not have it available (or are unwilling to supply..) My suggestion is that this element of service be amended to have the EE set a "required" bit on a per-oid basis, to signal that the reply must contain the requested information. By default, a particular-option "required" bit is to be not-set i.e. the per-item request may be optionally satisfied by the responder. EEs are expected to continue the enrollment protocol should the requested (but not-required) option be returned empty. The PKIX conformance statements might strongly urge that, by default, EE's do not ask for any required particular-options. this will help get multi-vendor interworking up faster. Once operational needs are determined, then (of course) locally-required behaviour may be tweaked by administrators. > > > If the EE indicates a particular option, such a message is outside the > mandatory set of messages and options specified in B.6, so a > PKIX-compliant CA is free to take whatever action it wants (including > throwing away the message because it doesn't understand it). Again, > there is no way an EE can use this request to force the CA to distribute > certificates. > This I had not understood ; I had understood the required processing to be: if an unknown PKIinformation particular-option is presented by the user then the CA/RA must return an error msg (being unable to fulfill the request totally.) I was assuming, given the text, that this procedure was mandatory: i.e. all CA/RA implementations must adopt this very specific failure mode processing. Let me ask a direct question to have you clarify positively for the case in question:- If EE sends a msg asking for information identified by {private-oid 1} where {private-oid 1} is not an object known to the CA, may the CA reply anyway with what it does know, and thereby enable the EE to choose to continue on with the msg flow of the msg sequences indicated in the part 4, and appendix B? If the answer is no, can we introduce the "required bit" per particular-object oid as suggested above so that error returns are only mandated only when its a "required" information unit that a CA/RA cannot, or is unwilling to, provide? If the answer is yes, perhaps add one phrase of clarification. (I certainly read the spec as requiring CA/RA to return an error response...) Peter. 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 12 (TEXT/R*ch) (0001C105) Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA26761 for ; Mon, 29 Sep 1997 08:13:25 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 29 Sep 1997 15:15:22 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id MAA17121; Mon, 29 Sep 1997 12:47:03 -0700 Received: from gatekeeper.entrust.com by suntan.tandem.com (8.6.12/suntan5.970212) for id MAA17113; Mon, 29 Sep 1997 12:47:02 -0700 Received: tid PAB20792; Mon, 29 Sep 1997 15:43:43 -0400 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCCCEE.1DE1C7B0@mail.entrust.com>; Mon, 29 Sep 1997 15:41:13 -0400 Message-ID: From: Carlisle Adams To: "'Peter Williams'" Cc: "'ietf-pkix@tandem.com'" Subject: RE: Comments on [MANDATORY cert discovery capabiity] Date: Mon, 29 Sep 1997 15:41:12 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: Hi Peter, Sorry I was called away for several days on other things, but now I'm back and thinking about PKIX again... >---------- >From: Peter Williams[SMTP:peter@verisign.com] >Sent: Monday, September 22, 1997 3:49 PM >To: Carlisle Adams >Cc: ietf-pkix@tandem.com >Subject: Re: Comments on [MANDATORY cert discovery capabiity] > I *am* reading and relating one section with another. I have one aim in mind: to determine what is the minimum functionality one must implement. (Then, laterm I can perform an analysis of whether it is acceptable to be required (as an operator) to enact those procedures, individually and in tandem. ) >Can you reproduce (and defend) the line of reasoning that led you to >believe that 3.3.14 and 3.3.16 are mandatory? I would be willing to >correct any text that leads to such a conclusion, but at the moment I >can't find any text that needs correction... This was my line of thinking: (...much of the "line of thinking" deleted to save space...) I note that a requestor may ask for any material indicated by the options supported in B.6, including those elements which seem (to me) to be one of the instantiations of 3.3.14 / 3.3.16 operations. Two comments here. Firstly, it is true that a requestor may ask for any number of particular things (the request is, after all, a SET of {OID,value} pairs). However, the only request that MUST be supported according to B.6 is the empty SET, which corresponds to "give me whatever information you think I need to know" (see 3.3.18). Thus, there is nothing explicit in the request that forces the CA to supply any particular piece of information. More relevant to your concern is the fact that B.6 currently mandates that the CA include the current CRL in the response. The thinking here was that the CA would have this information anyway (since it's the one that created the CRL) and an initializing EE would probably want to see this (it's a useful part of the start-up information). However, it doesn't really need to be mandatory, so I will change the top line of p.53 to "optionally present, with relevant value". [I assume this will make you happier.] Secondly, 3.3.14 and 3.3.16 are different PKIBody structures (i.e., they correspond to totally different PKIMessages from 3.3.18 and 3.3.19) so I don't really know what you mean by "one of the instantiations of 3.3.14 / 3.3.16 operations". As I said before, 3.3.14 and 3.3.16 are optional PKIMessages and need not be supported by PKIX-conformant EEs, RAs, or CAs. Thus I reasoned, that the document seemed to be mandating that CAs must perform the CA-based certificate distribution mechanism to conform to the spec if the relevevant option is indicated by the EE, else they must return error messages during intial registration./certification. If the EE indicates a particular option, such a message is outside the mandatory set of messages and options specified in B.6, so a PKIX-compliant CA is free to take whatever action it wants (including throwing away the message because it doesn't understand it). Again, there is no way an EE can use this request to force the CA to distribute certificates. that is: a CA implementation must either implement (to conform) an unerring error return, or it must satisfy the options requested. It cannont say: here is your certificate dear subscriber, but I do not wish to engage in the requested CA-based distribution/management mechanism; please use the LDAP directory instead. Again, the "here is your certificate dear subscriber" message is not related in any way to the general request / response messages, so I don't understand why you are trying to tie them together. ------ Please do not merely argue with my reasoning if you respond ; my reasoning may be right or wrong. Perhaps, just add a specific section which defines the minimum PKIX-3 conformance position in terms of the management operations, message formats, and options required, rather than having people deduce what it is (wrongly, half-wrong, or correctly) from a set of statements and procedure, optional messages and (optional) message element interactions spread all over a 70-page document. You would like a "specific section which defines the minimum PKIX-3 conformance position in terms of the management operations" (this is Section 4) "message formats, and options required" (this is Appendix B). Sections 1 and 2 talk in general terms about the certificate management functionality that an Internet PKI may have and Section 3 defines messages that can achieve that functionality. Section 4 specifies the subset of the operations from Sections 1 and 2 that MUST be supported and Appendix B specifies the subset of the messages from Section 3 that MUST be supported (to achieve the requirements of Section 4). The PKIX-3 conformance position is not "spread all over a 70-page document"; it is contained (explicitly) in one section and one appendix. I really don't know what you're asking for beyond this. (I intend after this comment threat to send a note on two other (hopefully simple) issues to do with conformance requirements, your choice of language and the indirect signals they send to me -- whose currrent expression may impact actual interworking.) I assume you mean "thread" above :-) I haven't seen your two other issues yet. Have they been resolved with further reading, or are you just trying to heighten my curiosity by waiting before you post them? -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id HAA25958 for ; Mon, 29 Sep 1997 07:42:17 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 29 Sep 1997 14:44:17 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id MAA08531; Mon, 29 Sep 1997 12:00:05 -0700 Received: from rosslyn.BBN.COM by suntan.tandem.com (8.6.12/suntan5.970212) for id MAA08522; Mon, 29 Sep 1997 12:00:02 -0700 Received: from RSHIREY.BBN.COM by rosslyn.BBN.COM id aa09682; 29 Sep 97 15:03 EDT X-Sender: rshirey@rosslyn.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Sep 1997 14:59:49 -0400 To: ietf-pkix@tandem.com From: "Robert W. Shirey" Subject: PKI Modeling Status: 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- rshirey@bbn.com, 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 Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id HAA25953 for ; Mon, 29 Sep 1997 07:42:01 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 29 Sep 1997 14:43:55 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id MAA09322; Mon, 29 Sep 1997 12:04:36 -0700 Received: from camel14.mindspring.com by suntan.tandem.com (8.6.12/suntan5.970212) for id MAA09314; Mon, 29 Sep 1997 12:04:35 -0700 Received: from arthur.nscc.com (ip22.an5-new-york4.ny.pub-ip.psi.net [38.26.16.22]) by camel14.mindspring.com (8.8.5/8.8.5) with ESMTP id PAA29058; Mon, 29 Sep 1997 15:04:30 -0400 (EDT) Message-ID: <3430091D.F0A07718@mindspring.com> Date: Mon, 29 Sep 1997 15:01:33 -0400 From: Dwight Arthur X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: Peter Williams CC: ietf-pkix@tandem.com Subject: Re: Certificate Suspension X-Priority: 3 (Normal) References: <01bcc90c$94287080$b603a8c0@pwilliams-pc.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: Peter Williams wrote: > The suspension action can be logically undone. > > A revocation action cannot be undone. > > If one advises a VISA bank that is possible that one has lost one's > visacard, then they can suspend its use (for three days most > issuing policies). When you find the card, account activity can be > resumed as if nothing had happened. <...> In the world of securities trading, where people profit on good news and bad but uncertainty causes panics, there is nothing more expensive than a transaction that can neither be cancelled nor completed. In this industry, I believe that suspensions will be deprecated and revocation used instead. -Dwight Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA29735 for ; Sun, 28 Sep 1997 12:48:36 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Sun, 28 Sep 1997 19:50:32 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id RAA18470; Sun, 28 Sep 1997 17:43:56 -0700 Received: from typhoon.dstc.qut.edu.au by suntan.tandem.com (8.6.12/suntan5.970212) for id RAA18463; Sun, 28 Sep 1997 17:43:53 -0700 Received: from localhost (povey@localhost [127.0.0.1]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with SMTP id KAA10289 for ietf-pkix@tandem.com; Mon, 29 Sep 1997 10:43:50 +1000 (EST) From: Dean Povey Message-Id: <199709290043.KAA10289@typhoon.dstc.qut.edu.au> X-Authentication-Warning: typhoon.dstc.qut.edu.au: povey@localhost [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 1.6.9 8/22/96 To: ietf-pkix@tandem.com Subject: Errors in the 88 ASN.1 of PKIX pt 1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Sep 97 10:43:50 +1000 X-Mts: smtp Status: Hi all, I've just been debugging the '88 ASN.1 and have run across the following problems: The following types and values are defined more than once: Version, Extensions, Extension, CertificateSerialNumber, id-ce-cRLNumber, id-pkix-authorityInfoAccess, Dss-Sig-Value I think the following are typos: + PolicyQualifierId has a trailing { + id-pkix-authorityInfoAccess OBJECT-IDENTIFIER should be OBJECT IDENTIFIER + certificateIssuer EXTENSION ... should be: CertificateIssuer ::= GeneralNames + sizE(1..ub-pds-parameter-length... should be SIZE In addition, I think the convention of using uppercase first character for types and lowercase for values should be adhered to (it chokes my ASN.1 compiler if it isn't used): anotherName -> AnotherName, certificateIssuer -> CertificateIssuer, ExtensionAttributeTable -> extensionAttributeTable Should the string types in Directory string have SIZE(1..MAX) rather than SIZE(1..maxSize)? That's about it :-) Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id GAA12977 for ; Fri, 26 Sep 1997 06:29:47 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Fri, 26 Sep 1997 13:31:37 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id LAA19706; Fri, 26 Sep 1997 11:26:56 -0700 Received: from ietf.org by suntan.tandem.com (8.6.12/suntan5.970212) for id LAA19702; Fri, 26 Sep 1997 11:26:55 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA07511; Fri, 26 Sep 1997 14:26:46 -0400 (EDT) Message-Id: <199709261826.OAA07511@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-pkix@tandem.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-opp-ftp-http-00.txt Date: Fri, 26 Sep 1997 14:26:45 -0400 Sender: cclark@cnri.reston.va.us 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-00.txt Pages : 5 Date : 23-Sep-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 ietf-pkix@tandem.com 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-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-opp-ftp-http-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: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pkix-opp-ftp-http-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: <19970924164150.I-D@ietf.org> [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 3 (EuSn/CSOm) (0001BF78) Content-Type: Message/External-body; name="draft-ietf-pkix-opp-ftp-http-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-opp-ftp-htt (AURL/Arch) (0001BF79) Content-Type: text/plain Content-ID: <19970924164150.I-D@ietf.org> Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id EAA09787 for ; Fri, 26 Sep 1997 04:23:47 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Fri, 26 Sep 1997 11:25:38 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id JAA25062; Fri, 26 Sep 1997 09:16:33 -0700 Received: from crack.x509.com by suntan.tandem.com (8.6.12/suntan5.970212) for id JAA25052; Fri, 26 Sep 1997 09:16:30 -0700 Received: from localhost (marcnarc@localhost) by crack.x509.com (8.8.7/8.8.7) with SMTP id JAA26186 for ; Fri, 26 Sep 1997 09:10:54 -0700 (PDT) Date: Fri, 26 Sep 1997 09:10:53 -0700 (PDT) From: Marc Branchaud X-Sender: marcnarc@crack To: "'ietf-pkix@tandem.com'" Subject: RE: Comments about Part 2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: -----BEGIN PGP SIGNED MESSAGE----- On Fri, 26 Sep 1997, Peter Whittaker wrote: > > >3.2.1 CertTemplate definition > > > >Why are issuer and Subject defined as Name instead of GeneralName? > > The definition of Certificate in X.509 uses Name for subject and issuer. > Unless we wish for PKIX to be incompatible with X.509 (and that would > be bad, by definition of PKIX, right? :->), we should continue to use > Name instead of GeneralName for these fields. Note that PKIX pt1 > describes an accomodation that works as well, and that is to have null > subject or issuer, with their identity being carried in the > subjectAltName or issuerAltName extension. I get it now, thanks... > > > >3.2.4 Certificate Identification > > > >Shouldn't serialNumber be a CertificateSerialNumber? > > That seems right, for the sake of complete accuracy (in the end, they > are the same thing, as CertificateSerialNumber is defined as INTEGER). > Yeah, it's just a nit. I noticed it because it made me stop to wonder if it was different from a certificate's serial number. No big deal, though... Marc +------------------------------------------------------------------------+ Marc Branchaud \/ Chief PKI Architect /\CERT SOFTWARE INC. marcnarc@xcert.com PKI References page: www.xcert.com 604-640-6210x227 www.xcert.com/~marcnarc/PKI/ +------------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNCvejVrdFXNdDxPlAQH2DgMAsozLhX82uv8YQ/f0PbuB+9rzdv+1zch2 TbZQXSV2VF5QnpjnuTFekTXQgztJ6mH88txyzXkjfGGKBEdPncyKUeRf351JhHND 5eBihsU1ckBID9N9hsvZClQwTbVGHTW9 =0ncM -----END PGP SIGNATURE----- Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id DAA07673 for ; Fri, 26 Sep 1997 03:12:48 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Fri, 26 Sep 1997 10:14:39 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA09706; Fri, 26 Sep 1997 07:45:18 -0700 Received: from argus.posten.se by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA09692; Fri, 26 Sep 1997 07:45:15 -0700 From: Received: (from smap@localhost) by argus.posten.se (8.8.6/8.8.5) id QAA00136; Fri, 26 Sep 1997 16:45:12 +0200 (MET DST) Received: from info(147.14.7.70) by argus via smap (V2.0) id xma000121; Fri, 26 Sep 97 16:45:07 +0200 Received: from hkmail.cph.posten.se (hkmail.cph.posten.se [147.14.142.201]) by info.posten.se (8.8.6/8.8.6) with ESMTP id QAA16503; Fri, 26 Sep 1997 16:45:06 +0200 (METDST) Received: from localhost by hkmail.cph.posten.se with SMTP (1.39.111.2/16.2) id AA120715105; Fri, 26 Sep 1997 16:45:05 +0200 X-Openmail-Hops: 1 Date: Fri, 26 Sep 97 16:44:53 +0200 Message-Id: Subject: SV: Re: SV: Re: Coding of national characters? To: pgut001@cs.auckland.ac.nz Cc: ietf-pkix@tandem.com Status: wrote: > > The (rather complex) issues surrounding this are explained in the X.509 style > guide (with some recent updates to cover character set issues), available from > http://www.cs.auckland.ac.nz/~pgut001/x509guide.txt. Apologies to people who > already know about the guide, but these sorts of questions seem to come up a > fair bit so I've cc'd the message back to the list in case anyone else wants > to know how to handle character set issues. > > I've also written some code which should be able to take virtually any input > text and convert it to an X.509-kosher form, if anyone wants to test this > (especially with multibyte and widechar character sets) please let me know - > I've only really got access to ASCII and 8859-1 environments so some of the > stuff is guesswork. Thanx Peter, your guide is very helpful. I was already aware of it but I've noticed that it's been updated since the last time I went through it. However, it's still NOT a solution to the problem (unless of course your guide is incorporated into the standard ;-) Can we please have this fixed in PKIX-1? BMPString sounds like a much better alternative than teletexString so one possibility would be to change the definition to: DirectoryString ::= CHOICE { printableString PrintableString (SIZE (1..maxSize)), --if it's sufficient otherwise... bmpString BMPString (SIZE (1..maxSize)), --if it's sufficient otherwise... universalString UniversalString (SIZE (1..maxSize)) --otherwise } Nevertheless, ISO 8859-1 is a lot better solution than BMPString for most european languages in terms of efficiency. So what's the tag 'visibleString' from the SET definition? Is that ISO 8859-1? In that case, can we use it? Do I sound desperate? /Lars Johansson Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id BAA05565 for ; Fri, 26 Sep 1997 01:49:06 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Fri, 26 Sep 1997 08:50:57 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id FAA25007; Fri, 26 Sep 1997 05:47:28 -0700 Received: from gatekeeper.entrust.com by suntan.tandem.com (8.6.12/suntan5.970212) for id FAA25004; Fri, 26 Sep 1997 05:47:26 -0700 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BCCA58.1960FA50@mail.entrust.com>; Fri, 26 Sep 1997 08:42:19 -0400 Message-ID: From: Peter Whittaker To: "'ietf-pkix@tandem.com'" , "'Marc Branchaud'" Cc: Carlisle Adams Subject: RE: Comments about Part 2 Date: Fri, 26 Sep 1997 08:42:16 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: >3.2.1 CertTemplate definition > >Why are issuer and Subject defined as Name instead of GeneralName? The definition of Certificate in X.509 uses Name for subject and issuer. Unless we wish for PKIX to be incompatible with X.509 (and that would be bad, by definition of PKIX, right? :->), we should continue to use Name instead of GeneralName for these fields. Note that PKIX pt1 describes an accomodation that works as well, and that is to have null subject or issuer, with their identity being carried in the subjectAltName or issuerAltName extension. > >3.2.4 Certificate Identification > >Shouldn't serialNumber be a CertificateSerialNumber? That seems right, for the sake of complete accuracy (in the end, they are the same thing, as CertificateSerialNumber is defined as INTEGER). pww Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id NAA19038 for ; Thu, 25 Sep 1997 13:11:24 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Thu, 25 Sep 1997 20:13:14 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id SAA25791; Thu, 25 Sep 1997 18:06:38 -0700 Received: from eagle.webpros.com by suntan.tandem.com (8.6.12/suntan5.970212) for id SAA25777; Thu, 25 Sep 1997 18:06:36 -0700 Received: from casa (casa.structuredarts.com [206.127.206.2]) by eagle.webpros.com (8.8.5/8.6.10) with ESMTP id SAA27928; Thu, 25 Sep 1997 18:07:29 -0700 (PDT) Message-ID: <342B0B73.59508E5B@StructuredArts.com> Date: Thu, 25 Sep 1997 18:10:11 -0700 From: "Anil R. Gangolli" Reply-To: gangolli@structuredarts.com Organization: Structured Arts Consulting Group X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: Marc Branchaud CC: ietf-pkix@tandem.com Subject: Re: Question about Part 1... X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: Marc Branchaud wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > On Thu, 25 Sep 1997, Brian Korver wrote: > > > > Marc Branchaud writes: > > > > > > 4.2.1.1 Authority Key Identifier > > > > > > Does the authorityCertIssuer field indicate the CA that signed the > > > certificate, or the CA that issued a certificate for the CA that > signed > > > the certificate (i.e. the CA's parent CA)? > > > > The later. For instance, here's a 3-level cert hierarchy (with a > self-signed > > root): > > > > Serial: 1 > > Issuer: Root CA > > Subject: Root CA > > > > Serial: 2 > > Issuer: Root CA > > Subject: UnderRoot CA > > AuthorityCertIssuer: Root CA > > AuthorityCertSerial: 1 > > > > Serial: 3 > > Issuer: UnderRoot CA > > Subject: EndEntity > > AuthorityCertIssuer: Root CA > > AuthorityCertSerial: 2 > > > > I suggest that the draft clarify this. Including this example would > be > most helpful. At the least, change the first sentence of the second > paragraph from > > "The identification can be based on either the key identifier (the > subject > key identifier in the issuer's certificate) or on the issuer name and > serial number." > > to > > "The identification information is obtained from the issuer's > certificate > (i.e. the certificate for the issuer's key, signed by a parent CA). > The > identification can be based on either the key identifier, or the > issuer's name and serial number, from that certificate." > > Marc Yes, this needs careful clarification. It may be helpful to clarify how it is intended to be used in chain formation together matching either the (explicit or implicit) subject key identifier in the immediate parent cert or matching the issuer and serial number in the immediate parent cert. In addition, one might want to note that the use of the authorityCertIssuer and authorityCertSerial fields rather than the keyIdentifier field precludes later re-rooting (or extension upward) of an existing CA hierarchy, which is often desirable. -- Anil R. Gangolli Structured Arts Consulting Group mailto:gangolli@StructuredArts.com http://www.StructuredArts.com Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA15257 for ; Thu, 25 Sep 1997 10:40:58 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Thu, 25 Sep 1997 17:42:48 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id PAA06079; Thu, 25 Sep 1997 15:48:43 -0700 Received: from crack.x509.com by suntan.tandem.com (8.6.12/suntan5.970212) for id PAA06073; Thu, 25 Sep 1997 15:48:41 -0700 Received: from localhost (marcnarc@localhost) by crack.x509.com (8.8.7/8.8.7) with SMTP id PAA29822 for ; Thu, 25 Sep 1997 15:43:06 -0700 (PDT) Date: Thu, 25 Sep 1997 15:43:05 -0700 (PDT) From: Marc Branchaud X-Sender: marcnarc@crack To: ietf-pkix@tandem.com Subject: Re: Question about Part 1... In-Reply-To: <199709252209.PAA13373@dv8.terisa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: -----BEGIN PGP SIGNED MESSAGE----- On Thu, 25 Sep 1997, Brian Korver wrote: > > Marc Branchaud writes: > > > > 4.2.1.1 Authority Key Identifier > > > > Does the authorityCertIssuer field indicate the CA that signed the > > certificate, or the CA that issued a certificate for the CA that signed > > the certificate (i.e. the CA's parent CA)? > > The later. For instance, here's a 3-level cert hierarchy (with a self-signed > root): > > Serial: 1 > Issuer: Root CA > Subject: Root CA > > Serial: 2 > Issuer: Root CA > Subject: UnderRoot CA > AuthorityCertIssuer: Root CA > AuthorityCertSerial: 1 > > Serial: 3 > Issuer: UnderRoot CA > Subject: EndEntity > AuthorityCertIssuer: Root CA > AuthorityCertSerial: 2 > I suggest that the draft clarify this. Including this example would be most helpful. At the least, change the first sentence of the second paragraph from "The identification can be based on either the key identifier (the subject key identifier in the issuer's certificate) or on the issuer name and serial number." to "The identification information is obtained from the issuer's certificate (i.e. the certificate for the issuer's key, signed by a parent CA). The identification can be based on either the key identifier, or the issuer's name and serial number, from that certificate." Marc +------------------------------------------------------------------------+ Marc Branchaud \/ Chief PKI Architect /\CERT SOFTWARE INC. marcnarc@xcert.com PKI References page: www.xcert.com 604-640-6210x227 www.xcert.com/~marcnarc/PKI/ +------------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNCro+lrdFXNdDxPlAQFoVQMAlEifx4CNRTstwol1Ah2eEDPQmW/VSJ9G 8pycvWTG4B00bJ/iYp7pxKjqJRJCMoTQ12TBr9Z5asX9Fa8Dx6dqkW3J/efMugKk TNe/YbrBb4ONqoXjuai9zva5oSs9+qNt =ih0J -----END PGP SIGNATURE----- Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id JAA13242 for ; Thu, 25 Sep 1997 09:26:17 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Thu, 25 Sep 1997 16:28:07 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id OAA24797; Thu, 25 Sep 1997 14:36:35 -0700 Received: from crack.x509.com by suntan.tandem.com (8.6.12/suntan5.970212) for id OAA24794; Thu, 25 Sep 1997 14:36:34 -0700 Received: from localhost (marcnarc@localhost) by crack.x509.com (8.8.7/8.8.7) with SMTP id OAA27294 for ; Thu, 25 Sep 1997 14:30:59 -0700 (PDT) Date: Thu, 25 Sep 1997 14:30:59 -0700 (PDT) From: Marc Branchaud X-Sender: marcnarc@crack Reply-To: Marc Branchaud To: ietf-pkix@tandem.com Subject: Question about Part 1... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: -----BEGIN PGP SIGNED MESSAGE----- 4.2.1.1 Authority Key Identifier Does the authorityCertIssuer field indicate the CA that signed the certificate, or the CA that issued a certificate for the CA that signed the certificate (i.e. the CA's parent CA)? Marc +------------------------------------------------------------------------+ Marc Branchaud \/ Chief PKI Architect /\CERT SOFTWARE INC. marcnarc@xcert.com PKI References page: www.xcert.com 604-640-6210x227 www.xcert.com/~marcnarc/PKI/ +------------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNCrYE1rdFXNdDxPlAQGlsgMAnrIJkOEAnTgaJOmnNTwg3cN2IMSr72iy 4b3EXARsjW39Ne560Pw1+9bWsgMOXZEppFG3QEqrQMed/XOkNEJbTPmxoR9FAIq9 vV4scZtjVfkug9H4iGQopyhPBUumTJZn =0JFU -----END PGP SIGNATURE----- Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id JAA13986 for ; Thu, 25 Sep 1997 09:55:46 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Thu, 25 Sep 1997 16:57:36 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id PAA29618; Thu, 25 Sep 1997 15:08:48 -0700 Received: from terisa-bh.terisa.com by suntan.tandem.com (8.6.12/suntan5.970212) for id PAA29613; Thu, 25 Sep 1997 15:08:47 -0700 Received: (from uucp@localhost) by terisa-bh.terisa.com (8.6.12/8.6.11) id PAA01235; Thu, 25 Sep 1997 15:08:47 -0700 Received: from itech.terisa.com by terisa-bh.terisa.com via smap (3.2) id xma001227; Thu, 25 Sep 97 15:08:28 -0700 Received: from dv8.terisa.com (dv8.terisa.COM [205.226.39.41]) by itech.terisa.com (8.8.5/8.6.4) with ESMTP id PAA02031; Thu, 25 Sep 1997 15:09:23 -0700 (PDT) From: Brian Korver Received: (briank@localhost) by dv8.terisa.com (8.6.12/8.6.4) id PAA13373; Thu, 25 Sep 1997 15:09:21 -0700 Message-Id: <199709252209.PAA13373@dv8.terisa.com> Subject: Re: Question about Part 1... To: marcnarc@xcert.com Date: Thu, 25 Sep 1997 15:09:21 -0700 (PDT) Cc: ietf-pkix@tandem.com In-Reply-To: from "Marc Branchaud" at Sep 25, 97 02:30:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: Marc Branchaud writes: > > -----BEGIN PGP SIGNED MESSAGE----- > > > 4.2.1.1 Authority Key Identifier > > Does the authorityCertIssuer field indicate the CA that signed the > certificate, or the CA that issued a certificate for the CA that signed > the certificate (i.e. the CA's parent CA)? The later. For instance, here's a 3-level cert hierarchy (with a self-signed root): Serial: 1 Issuer: Root CA Subject: Root CA Serial: 2 Issuer: Root CA Subject: UnderRoot CA AuthorityCertIssuer: Root CA AuthorityCertSerial: 1 Serial: 3 Issuer: UnderRoot CA Subject: EndEntity AuthorityCertIssuer: Root CA AuthorityCertSerial: 2 brian briank@terisa.com Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id JAA13229 for ; Thu, 25 Sep 1997 09:25:49 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Thu, 25 Sep 1997 16:27:38 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id OAA24638; Thu, 25 Sep 1997 14:35:28 -0700 Received: from crack.x509.com by suntan.tandem.com (8.6.12/suntan5.970212) for id OAA24628; Thu, 25 Sep 1997 14:35:27 -0700 Received: from localhost (marcnarc@localhost) by crack.x509.com (8.8.7/8.8.7) with SMTP id OAA27191 for ; Thu, 25 Sep 1997 14:29:52 -0700 (PDT) Date: Thu, 25 Sep 1997 14:29:51 -0700 (PDT) From: Marc Branchaud X-Sender: marcnarc@crack Reply-To: Marc Branchaud To: ietf-pkix@tandem.com Subject: Comments about Part 2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: -----BEGIN PGP SIGNED MESSAGE----- Just a couple of brief points... 3.2.1 CertTemplate definition Why are issuer and Subject defined as Name instead of GeneralName? 3.2.4 Certificate Identification Shouldn't serialNumber be a CertificateSerialNumber? Marc +------------------------------------------------------------------------+ Marc Branchaud \/ Chief PKI Architect /\CERT SOFTWARE INC. marcnarc@xcert.com PKI References page: www.xcert.com 604-640-6210x227 www.xcert.com/~marcnarc/PKI/ +------------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNCrXz1rdFXNdDxPlAQFuUgMAsVKq5pFXlC+DKoGxhOLSqZO15B6mp1oe ayDg5NACKyCp9/goNWUqfZKUpxFg05Xqg2cv1mhAuJV97PjzBb6XC2GwPFLASzdt rkNCGo6k4LCvNsvqOAOxVM6Ami85zYlj =Z8mY -----END PGP SIGNATURE----- Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id CAA02496 for ; Thu, 25 Sep 1997 02:20:14 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Thu, 25 Sep 1997 09:22:05 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id GAA06934; Thu, 25 Sep 1997 06:21:17 -0700 Received: from zafu.bbn.com by suntan.tandem.com (8.6.12/suntan5.970212) for id GAA06922; Thu, 25 Sep 1997 06:21:12 -0700 Received: from [128.89.30.5] (ARA5.BBN.COM [128.89.30.5]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id JAA19221; Thu, 25 Sep 1997 09:22:15 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <01bcc913$0c79c600$b603a8c0@pwilliams-pc.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Sep 1997 07:10:49 -0600 To: "Peter Williams" From: Stephen Kent Subject: Re: PKIX1 definition of a certificate Cc: "IETF PKIX List" Status: 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). Steve Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id PAA18445 for ; Wed, 24 Sep 1997 15:27:18 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Wed, 24 Sep 1997 22:29:06 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id UAA05237; Wed, 24 Sep 1997 20:28:26 -0700 Received: from elvis.vnet.net by suntan.tandem.com (8.6.12/suntan5.970212) for id UAA05219; Wed, 24 Sep 1997 20:28:22 -0700 Received: from vnet.net (polaris.vnet.net [166.82.242.43]) by elvis.vnet.net (8.8.5/8.8.4) with ESMTP id XAA19902; Wed, 24 Sep 1997 23:28:16 -0400 (EDT) Message-ID: <3429DA5E.3D01AB5E@vnet.net> Date: Wed, 24 Sep 1997 23:28:31 -0400 From: George Capehart Organization: Capehart Associates X-Mailer: Mozilla 4.03 [en] (Win95; U) MIME-Version: 1.0 To: peter@verisign.com CC: ietf-pkix@tandem.com Subject: Re: PKIX1 definition of a certificate References: <01bcc913$0c79c600$b603a8c0@pwilliams-pc.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: Peter Williams wrote: > > "(4) the term 'public key certificates' means a certification of > the determination of the origin of encrypted information through > verification of a persons public key by identifying the unique > characteristics of the key;" > > Should we alter PKIX-1 to have this as the definition of a > PKIX public key certificate (assuming someone knows what > the above means). Though I have no voting rights, I *do* have a strong interest in this discussion. I work for a large bank and we are in the process of creating our CPS and are therefore wrestling with this issue. IMHO, a _public_key_certificate_ is an object that contains the EE's public key along with some representation of degree of certainty the CA has that the EE who presented the public key to be certified is also in possession of the private part of the key pair and really is who they represent themselves to be. It seems to me that a cert is an object and "certification of the determination of origin of . . ." is an action . . . at least grammatically. As far as what the phrase actually means, I'm not really sure. I diagrammed the sentence and working backwards, I get the statement that, based on unique characteristics of some public key, that key can be identified and through that identification, the origin of some encrypted information can be determined. Shortening that somewhat, I get: That by knowing the fingerprint of some public key, I can determine and certify the origin of some encrypted data. If that's what is meant by a digital certificate, that doesn't get me where I want to be. > (One notes that the above would not seem to cover a PKIX > DSA or ECC-DSA certificate validating a DSA/ECC-DSA digital > signature.) Or most anything else. I still haven't figured out how something can be a noun and a verb at the same time . . . > > Peter. -- /* * George Capehart email: gwc@vnet.net phone: +1 704.866.9151 * * "If you push something hard enough, it will fall over." * Fudd's First Law of Opposition */ Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id HAA06215 for ; Wed, 24 Sep 1997 07:29:40 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Wed, 24 Sep 1997 14:31:22 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id MAA23177; Wed, 24 Sep 1997 12:07:42 -0700 Received: from arctic.valicert.com by suntan.tandem.com (8.6.12/suntan5.970212) for id MAA23162; Wed, 24 Sep 1997 12:07:40 -0700 Received: from crater (crater.valicert.com [206.217.81.67]) by arctic.valicert.com (8.6.12/8.6.9) with ESMTP id LAA02439; Wed, 24 Sep 1997 11:01:55 -0700 Message-ID: <34296642.9AB786F@valicert.com> Date: Wed, 24 Sep 1997 12:13:06 -0700 From: Ambarish Malpani Organization: ValiCert, Inc. X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: "Sheedy, E.C.C." CC: "'ietf-pkix@tandem.com'" Subject: Re: Certificate Suspension X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: I believe Certificate Suspension is where the certifiate is not considered valid for some time and then considered valid again after that. For example, if you go on leave for 6 months, your company may want to suspend your certificate for those 6 months without revoking it. A -- --------------------------------------------------------------------- Ambarish Malpani Architect (408) 738-2040 ValiCert, Inc. ambarish@valicert.com 333 W. El Camino Real, Suite 270 http://www.valicert.com Sunnyvale, CA 94087 Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id GAA04160 for ; Wed, 24 Sep 1997 06:14:56 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Wed, 24 Sep 1997 13:16:44 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id LAA06730; Wed, 24 Sep 1997 11:04:45 -0700 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id LAA06727; Wed, 24 Sep 1997 11:04:44 -0700 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id LAA19378; Wed, 24 Sep 1997 11:04:11 -0700 (PDT) Received: from pwilliams-pc by mentat.verisign.com (8.8.5/BCH1.0) id LAA07063; Wed, 24 Sep 1997 11:04:07 -0700 (PDT) Reply-To: "Peter Williams" From: "Peter Williams" To: , "Russ Housley" Subject: Re: FTP and HTTP Date: Wed, 24 Sep 1997 11:06:42 -0700 Message-ID: <01bcc914$9caacf20$b603a8c0@pwilliams-pc.verisign.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0073_01BCC8D9.F03B2E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Status: Russ, The use of application/octet-string would seem suitable if the object is truely a file. I do not believe one intends, however, to deny other objects transferred using http. Consider adding language which explicitely allows other mime types to be used, without standarizating their form. To your paragrah "For convenience, the names of files that contain certificates should have a suffix of ".cer". Each ".cer" file contains exactly one certificate, encoded in DER format. Likewise, the names of files that contain CRLs should have a suffix of ".crl". Each ".crl" file contains exactly one CRL, encoded in DER format." One might add a phrase: 'Other http resources usable with this mechanism may have alternative formats and naming conventions." -------- Consider, by way of example, this msg. There is an electronic vard attachment. Within, I have hopefully placed an http URL, which points to an interactive page which parties may used to download my cert in a variety of formats used by various security applications. This action is intended to replace the need to attach my cert chain to each signed message, which is rather a waste of resources particularly for those who do not bother to verify signatures. Peter. -----Original Message----- From: Russ Housley To: ietf-pkix@tandem.com Date: Tuesday, September 23, 1997 2:55 PM Subject: FTP and HTTP >Here is FTP/HTTP document that was slit out from PKIX Part 2. >It is also being sent to the I-D repository. > >There is one detail to complete before last call: the assignement >of MIME types for use with HTTP. Does anyone have a preference? > >Russ Attachment converted: Lutefisk:Peter Williams.vcf 3 (TEXT/R*ch) (0001BF3B) Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Attachment converted: Lutefisk:smime.p7s 19 (????/----) (0001BF3C) Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id FAA03572 for ; Wed, 24 Sep 1997 05:48:49 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Wed, 24 Sep 1997 12:50:38 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id KAA03366; Wed, 24 Sep 1997 10:53:33 -0700 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id KAA03358; Wed, 24 Sep 1997 10:53:31 -0700 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id KAA19210; Wed, 24 Sep 1997 10:52:59 -0700 (PDT) Received: from pwilliams-pc by mentat.verisign.com (8.8.5/BCH1.0) id KAA06552; Wed, 24 Sep 1997 10:52:56 -0700 (PDT) Reply-To: "Peter Williams" From: "Peter Williams" To: "IETF PKIX List" Subject: PKIX1 definition of a certificate Date: Wed, 24 Sep 1997 10:55:30 -0700 Message-ID: <01bcc913$0c79c600$b603a8c0@pwilliams-pc.verisign.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_004C_01BCC8D8.600A2520" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Status: "(4) the term 'public key certificates' means a certification of the determination of the origin of encrypted information through verification of a persons public key by identifying the unique characteristics of the key;" Should we alter PKIX-1 to have this as the definition of a PKIX public key certificate (assuming someone knows what the above means). (One notes that the above would not seem to cover a PKIX DSA or ECC-DSA certificate validating a DSA/ECC-DSA digital signature.) Peter. Notice: This message is not signed. Attachment converted: Lutefisk:Peter Williams.vcf 2 (TEXT/R*ch) (0001BF39) Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Attachment converted: Lutefisk:smime.p7s 18 (????/----) (0001BF3A) Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id FAA03050 for ; Wed, 24 Sep 1997 05:26:31 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Wed, 24 Sep 1997 12:28:17 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id KAA20692; Wed, 24 Sep 1997 10:07:14 -0700 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id KAA20688; Wed, 24 Sep 1997 10:07:12 -0700 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id KAA18566; Wed, 24 Sep 1997 10:06:41 -0700 (PDT) Received: from pwilliams-pc by mentat.verisign.com (8.8.5/BCH1.0) id KAA04707; Wed, 24 Sep 1997 10:06:37 -0700 (PDT) From: "Peter Williams" To: "Sheedy, E.C.C." , Subject: Re: Certificate Suspension Date: Wed, 24 Sep 1997 10:09:12 -0700 Message-ID: <01bcc90c$94287080$b603a8c0@pwilliams-pc.verisign.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000E_01BCC8D1.E7C99880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Status: -----Original Message----- From: Sheedy, E.C.C. To: 'ietf-pkix@tandem.com' Date: Wednesday, September 24, 1997 8:56 AM Subject: Certificate Suspension >Hi, >Whilst attempting to negotiate my way through the various PKIX documents >i came across two terms which seem quite similar but have been made >distinct. The two tersm are >1. Certificate Revocation and >2. Certificate Suspension. > >Cert. revocation is quite clear and needs no further explanation but >cert. suspension i am quite unsure about. The two seem to have the same >effects thus could someone please clarify the exact difference between >them and the resulting actions taken which makes suspension different >from Revocation. The suspension action can be logically undone. A revocation action cannot be undone. If one advises a VISA bank that is possible that one has lost one's visacard, then they can suspend its use (for three days most issuing policies). When you find the card, account activity can be resumed as if nothing had happened. If you do not find it, the card is revoked, and you get a new one. The consequences of revocation [request] are laid out in the issuing policy; for example, you may be responsible for reporting loss of the card to the police, in some countries. > >Cheers >Colm Sheedy >KPN Research > Attachment converted: Lutefisk:Peter Williams.vcf 1 (TEXT/R*ch) (0001BF38) Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id EAA00995 for ; Wed, 24 Sep 1997 04:06:52 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Wed, 24 Sep 1997 11:08:38 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id IAA29982; Wed, 24 Sep 1997 08:35:00 -0700 Received: from hermes.research.kpn.com by suntan.tandem.com (8.6.12/suntan5.970212) for id IAA29949; Wed, 24 Sep 1997 08:34:55 -0700 Received: from ntl11.research.kpn.com by research.kpn.com (PMDF V5.1-8 #18053) with SMTP id <01IO125C6GU20004UA@research.kpn.com> for ietf-pkix@tandem.com; Wed, 24 Sep 1997 17:34:40 +0200 Received: by ntl11.research.kpn.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCC910.2364F590@ntl11.research.kpn.com>; Wed, 24 Sep 1997 17:34:41 +0100 Date: Wed, 24 Sep 1997 17:34:45 +0100 From: "Sheedy, E.C.C." Subject: Certificate Suspension To: "'ietf-pkix@tandem.com'" Message-id: MIME-version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Status: Hi, Whilst attempting to negotiate my way through the various PKIX documents i came across two terms which seem quite similar but have been made distinct. The two tersm are 1. Certificate Revocation and 2. Certificate Suspension. Cert. revocation is quite clear and needs no further explanation but cert. suspension i am quite unsure about. The two seem to have the same effects thus could someone please clarify the exact difference between them and the resulting actions taken which makes suspension different from Revocation. Cheers Colm Sheedy KPN Research Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA06512 for ; Tue, 23 Sep 1997 10:23:14 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 23 Sep 1997 17:25:01 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id OAA08444; Tue, 23 Sep 1997 14:28:49 -0700 Received: from nile.spyrus.com by suntan.tandem.com (8.6.12/suntan5.970212) for id OAA08398; Tue, 23 Sep 1997 14:28:40 -0700 Received: from spg-as51s32.erols.com by nile.spyrus.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1458.49) id T3JX6P6B; Tue, 23 Sep 1997 14:34:27 -0700 Message-Id: <3.0.3.16.19970923170448.3e072312@nile.spyrus.com> X-Sender: rhousley@nile.spyrus.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (16) Date: Tue, 23 Sep 1997 17:04:48 -0400 To: ietf-pkix@tandem.com From: Russ Housley Subject: FTP and HTTP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_875063088==_" Status: Here is FTP/HTTP document that was slit out from PKIX Part 2. It is also being sent to the I-D repository. There is one detail to complete before last call: the assignement of MIME types for use with HTTP. Does anyone have a preference? Russ Attachment converted: Lutefisk:PKIX2OP3.TXT (TEXT/MSIE) (0001BF2E) Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id FAA31943 for ; Tue, 23 Sep 1997 05:49:53 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 23 Sep 1997 12:51:38 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id KAA13842; Tue, 23 Sep 1997 10:12:15 -0700 Received: from letterbox.cs.auckland.ac.nz by suntan.tandem.com (8.6.12/suntan5.970212) for id KAA13828; Tue, 23 Sep 1997 10:12:10 -0700 Received: from cs26.cs.auckland.ac.nz (cs26.cs.auckland.ac.nz [130.216.33.9]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id FAA16098; Wed, 24 Sep 1997 05:12:04 +1200 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <87503472402601>; Wed, 24 Sep 1997 05:12:04 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: lars.gu.johansson@posten.se Subject: Re: SV: Re: Coding of national characters? Cc: ietf-pkix@tandem.com Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Wed, 24 Sep 1997 05:12:04 (NZST) Message-ID: <87503472402601@cs26.cs.auckland.ac.nz> Status: >It looks to me that BMPString is actually defined in the later version >of the ASN.1 specification (ISO/IEC 8824) as a subset of UniversalString >(with a different tag!). I have only the 88 version so I haven't been able >to check this. Does that mean that BMPString can replace UniversalString >wherever it appears (e.g. the DirectoryString definition of X.520)? The (rather complex) issues surrounding this are explained in the X.509 style guide (with some recent updates to cover character set issues), available from http://www.cs.auckland.ac.nz/~pgut001/x509guide.txt. Apologies to people who already know about the guide, but these sorts of questions seem to come up a fair bit so I've cc'd the message back to the list in case anyone else wants to know how to handle character set issues. I've also written some code which should be able to take virtually any input text and convert it to an X.509-kosher form, if anyone wants to test this (especially with multibyte and widechar character sets) please let me know - I've only really got access to ASCII and 8859-1 environments so some of the stuff is guesswork. Peter. Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id DAA28304 for ; Tue, 23 Sep 1997 03:21:59 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 23 Sep 1997 10:23:44 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA06622; Tue, 23 Sep 1997 07:28:50 -0700 Received: from argus.posten.se by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA06604; Tue, 23 Sep 1997 07:28:46 -0700 From: Received: (from smap@localhost) by argus.posten.se (8.8.6/8.8.5) id QAA18135; Tue, 23 Sep 1997 16:28:35 +0200 (MET DST) Received: from info(147.14.7.70) by argus via smap (V2.0) id xma018110; Tue, 23 Sep 97 16:28:29 +0200 Received: from hkmail.cph.posten.se (hkmail.cph.posten.se [147.14.142.201]) by info.posten.se (8.8.6/8.8.6) with ESMTP id QAA29884; Tue, 23 Sep 1997 16:28:28 +0200 (METDST) Received: from localhost by hkmail.cph.posten.se with SMTP (1.39.111.2/16.2) id AA016354907; Tue, 23 Sep 1997 16:28:27 +0200 X-Openmail-Hops: 1 Date: Tue, 23 Sep 97 16:28:16 +0200 Message-Id: Subject: SV: Re: Coding of national characters? Mime-Version: 1.0 To: gangolli@structuredarts.com Cc: ietf-pkix@tandem.com Content-Type: text/plain; charset=US-ASCII; name="SV:" Content-Disposition: inline; filename="SV:" Content-Transfer-Encoding: 7bit Status: gangolli@StructuredArts.com wrote: > > lars.gu.johansson@posten.se wrote: > > > > We have a problem... > > > > In PKIX part 1, chapter 4.1.2.4 "Issuer Name" the issuer field > > (and the subject field similarly) is defined. There are no > > mandatory X.520 attributes (like country or commonName etc) > > but the the DirectoryString is defined in ASN.1 as: > > > > > DirectoryString ::= CHOICE { > > > teletexString TeletexString (SIZE (1..maxSize)), > > > printableString PrintableString (SIZE > > (1..maxSize)), > > > universalString UniversalString (SIZE > > (1..maxSize)) > > > I agree with Lars. > > First, I believe the most current X.520 allows BMPString in this > choice. I have a version of X.520 from Nov 93 (is there a later version?) which doesn't include BMPString in the choice. However, in the appendix A to PKIX-1 I found the following lines: -- UNIVERSAL Types defined in '93 ASN.1 -- but required by this specification UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING -- UniversalString is defined in ASN.1:1993 BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING -- BMPString is the subtype of -- UniversalString and models the Basic Multilingual Plane -- of ISO/IEC 10646-1 It looks to me that BMPString is actually defined in the later version of the ASN.1 specification (ISO/IEC 8824) as a subset of UniversalString (with a different tag!). I have only the 88 version so I haven't been able to check this. Does that mean that BMPString can replace UniversalString wherever it appears (e.g. the DirectoryString definition of X.520)? If anyone on this list have a specification of the character set in BMPString I would appreciate a copy. Please respond to me privately. > Second, I believe we should just avoid encoding as TeletexString > (T61String) > altogether. > > I'd like to see the precedence go: > > - PrintableString if it "fits" > - BMPString if it "fits" > - UniversalString I think this would be in line with the SET specification. Regards, /Lars J Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id XAA22277 for ; Mon, 22 Sep 1997 23:58:02 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 23 Sep 1997 06:59:47 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id EAA19315; Tue, 23 Sep 1997 04:39:22 -0700 Received: from clbull.frcl.bull.fr by suntan.tandem.com (8.6.12/suntan5.970212) for id EAA19284; Tue, 23 Sep 1997 04:39:03 -0700 Received: from lambada1.frcl.bull.fr (lambada.frcl.bull.fr [129.182.22.1]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with SMTP id NAA15250; Tue, 23 Sep 1997 13:35:03 +0200 Received: from ska by lambada1.frcl.bull.fr; Tue, 23 Sep 97 13:34:10 +0200 (MET) Received: from loopback by ska.frcl.bull.fr (AIX 4.1/UCB 5.64/4.03) id AA23922; Tue, 23 Sep 1997 14:32:54 +0200 Sender: vallot@ska.frcl.bull.fr Message-Id: <3427B6F6.2781@frcl.bull.fr> Date: Tue, 23 Sep 1997 14:32:54 +0200 From: Max VALLOT Organization: BULL Worldwide Information Systems X-Mailer: Mozilla 3.0 (X11; I; AIX 1) Mime-Version: 1.0 To: ietf-pkix@tandem.com Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: subscribe -- ____________________________________________________________ Max VALLOT Phone: +33 (0)1.30.80.60.62 Bull SA Fax: +33 (0)1.30.80.77.99 FRCL-A5/146 mailto:M.Vallot@frcl.bull.fr rue Jean Jaures, BP68, 78340 Les Clayes sous Bois, FRANCE ____________________________________________________________ Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id VAA18987 for ; Mon, 22 Sep 1997 21:42:12 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Tue, 23 Sep 1997 04:43:57 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id AAA28595; Tue, 23 Sep 1997 00:01:16 -0700 Received: from clbull.frcl.bull.fr by suntan.tandem.com (8.6.12/suntan5.970212) for id AAA28543; Tue, 23 Sep 1997 00:01:05 -0700 Received: from bahamas.frcl.bull.fr (bahamas.frcl.bull.fr [129.182.22.122]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with SMTP id IAA06792 for ; Tue, 23 Sep 1997 08:57:04 +0200 Received: from localhost by bahamas.frcl.bull.fr (AIX 4.1/UCB 5.64/4.03) id AA12322; Tue, 23 Sep 1997 09:01:01 +0200 Date: Tue, 23 Sep 1997 09:01:01 +0200 (DFT) From: "J.Lebastard" To: ietf-pkix@tandem.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: subscribe Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id JAA00536 for ; Mon, 22 Sep 1997 09:23:18 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 22 Sep 1997 16:24:56 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id MAA22233; Mon, 22 Sep 1997 12:47:26 -0700 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id MAA22229; Mon, 22 Sep 1997 12:47:24 -0700 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id MAA19787; Mon, 22 Sep 1997 12:46:51 -0700 (PDT) Received: from pwilliams-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA21188; Mon, 22 Sep 1997 12:46:48 -0700 (PDT) From: "Peter Williams" To: "Carlisle Adams" Cc: Subject: Re: Comments on [MANDATORY cert discovery capabiity] Date: Mon, 22 Sep 1997 12:49:24 -0700 Message-ID: <01bcc790$a1205500$b603a8c0@pwilliams-pc.verisign.com> MIME-Version: 1.0 Content-Type: application/x-pkcs7-mime; boundary="----=_NextPart_000_007B_01BCC755.F4B0B420"; name="smime.p7m" Content-Disposition: attachment; filename="smime.p7m" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Status: Attachment converted: Lutefisk:smime.p7m (????/----) (0001BF16) Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id GAA28122 for ; Mon, 22 Sep 1997 06:02:37 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 22 Sep 1997 13:04:20 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id KAA28919; Mon, 22 Sep 1997 10:40:39 -0700 Received: from eagle.webpros.com by suntan.tandem.com (8.6.12/suntan5.970212) for id KAA28909; Mon, 22 Sep 1997 10:40:38 -0700 Received: from casa (casa.structuredarts.com [206.127.206.2]) by eagle.webpros.com (8.8.5/8.6.10) with ESMTP id KAA08544; Mon, 22 Sep 1997 10:41:24 -0700 (PDT) Message-ID: <3426AE5E.1EB3CBB2@StructuredArts.com> Date: Mon, 22 Sep 1997 10:43:58 -0700 From: "Anil R. Gangolli" Reply-To: gangolli@structuredarts.com Organization: Structured Arts Consulting Group X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: lars.gu.johansson@posten.se CC: ietf-pkix@tandem.com Subject: Re: Coding of national characters? X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: lars.gu.johansson@posten.se wrote: > > We have a problem... > > In PKIX part 1, chapter 4.1.2.4 "Issuer Name" the issuer field > (and the subject field similarly) is defined. There are no > mandatory X.520 attributes (like country or commonName etc) > but the the DirectoryString is defined in ASN.1 as: > > > DirectoryString ::= CHOICE { > > teletexString TeletexString (SIZE (1..maxSize)), > > printableString PrintableString (SIZE > (1..maxSize)), > > universalString UniversalString (SIZE > (1..maxSize)) I agree with Lars. First, I believe the most current X.520 allows BMPString in this choice. Second, I believe we should just avoid encoding as TeletexString (T61String) altogether. I'd like to see the precedence go: - PrintableString if it "fits" - BMPString if it "fits" - UniversalString --a. > > Below this definition it is stated that: > > > The directoryString is defined as a choice of PrintableString, > > TeletexString 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 charater set is > sufficient, > > the string string will be represented as a TeletexString; > > > > (c) failing (a) and (b), the string shall be represented as a > > UniversalString. > > The problem for us outside the US is how to encode national > characters. > In Sweden for example, PrintableString which is equivalent to 7-bit > ASCII > is not sufficient. According to the standard we would then make use of > teletexString which is equivalent to the T.61 character set. > > Now, T.61 is an old standard that is very seldomly used nowadays. In > particular neither Netscape Navigator nor Microsoft Internet Explorer > make use of T.61. > > Instead both Navigator and Explorer uses the character set in ISO > 8859-1 > (Latin-1 which is equivalent to 8-bit ASCII). This character set is > used for > both the PrintableString tag and the teletexString tag. > > Clearly the use of ISO 8859-1 in conjuction with the teletexString tag > is an > error and some X.500 directories won't accept this. The effect would > be > that searching these directories becomes impossible. > > The other alternative (ISO 8859-1 with the PrintableString tag) looks > very > attractive IMHO and I would prefer that this solution were > incorporated into > the standard. There are still problems however: many complilers based > on ASN.1 doesn't accept 8-bit characters in a PrintableString. > > Can anyone on this list see a solution to this problem? If so, I would > suggest > that the PKIX-1 draft is updated accordinly. > > Regards, > /Lars Johansson > Sweden Post -- Anil R. Gangolli Structured Arts Consulting Group mailto:gangolli@StructuredArts.com http://www.StructuredArts.com Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id FAA28103 for ; Mon, 22 Sep 1997 05:59:28 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 22 Sep 1997 13:01:06 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id KAA29143; Mon, 22 Sep 1997 10:41:45 -0700 Received: from guardian.guard.ncsc.mil by suntan.tandem.com (8.6.12/suntan5.970212) for id KAA29125; Mon, 22 Sep 1997 10:41:42 -0700 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id NAA07543 for ; Mon, 22 Sep 1997 13:41:20 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma007534; Mon Sep 22 13:40:54 1997 Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.53.166]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id NAA00418 for ; Mon, 22 Sep 1997 13:38:02 -0400 Received: from smtpgw.missi.ncsc.mil (unverified [144.51.54.211]) by mimesweeper.missi.ncsc.mil (Integralis SMTPRS 2.02) with SMTP id ; Mon, 22 Sep 1997 13:42:41 -0400 Received: by smtpgw.missi.ncsc.mil with Microsoft Mail id <3426AF1E@smtpgw.missi.ncsc.mil>; Mon, 22 Sep 97 13:47:10 EDT From: "Arsenault, Al W." To: Carlisle Adams , "'Peter Williams'" Cc: "'ietf-pkix@tandem.com'" Subject: RE: Comments on [MANDATORY cert discovery capabiity] Date: Mon, 22 Sep 97 13:39:00 EDT Message-Id: <3426AF1E@smtpgw.missi.ncsc.mil> Encoding: 24 TEXT X-Mailer: Microsoft Mail V3.0 Status: On closer review, I confirmed that I like the document as it now stands. There is the ability to use PKIX-CMP to distribute certificates, CRLs, etc. to users upon initial registration. (For some set of users, it's easier to get the signed certificate, the CA's current CRL, and other ancillary information in a message - possibly contained on a floppy-disk for an off-line CA - than to be told to get them from a repository.) There is no need for this to be mandatory; I recognize that many CA providers will not want to provide this service and I don't wish to require them to. Additionally, I can use PKIX-CMP (vice PKIX-OPP) to distribute new CRLs on occasions where a push is deemed necessary. The messages I need to do this are all there in the protocol now. Again, there is no need for these messages to be mandatory for PKIX conformance - not everybody wants to/has to implement a similar service. All I ask is that somebody providing such a service not be deemed non-conformant with PKIX. Al Arsenault - speaking only for myself Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id FAA26826 for ; Mon, 22 Sep 1997 05:14:13 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 22 Sep 1997 12:15:50 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id JAA12121; Mon, 22 Sep 1997 09:23:00 -0700 Received: from ietf.org by suntan.tandem.com (8.6.12/suntan5.970212) for id JAA12116; Mon, 22 Sep 1997 09:22:56 -0700 Received: from ietf.ietf.org by ietf.org id aa10017; 22 Sep 97 12:17 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-pkix@tandem.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ipki2opp-03.txt (re-send) Date: Mon, 22 Sep 1997 12:17:19 -0400 Sender: cclark@ietf.org Message-ID: <9709221217.aa10017@ietf.org> 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 - LDAP Author(s) : S. Boeyen, T. Howes, P. Richard Filename : draft-ietf-pkix-ipki2opp-03.txt Pages : 11 Date : 1997-09-17 The protocol described in this document is designed to satisfy some of the operational requirements within the Internet Public Key Infrastruc- ture (IPKI). Specifically, this document addresses requirements to pro- vide access to Public Key Infrastructure (PKI) repositories for the pur- poses of retrieving PKI information and managing that same information. The mechanism described in this document is based on the Lightweight Directory Access Protocol (LDAP) version 2, defined in RFC 1777, and defines a profile of that protocol for use within the IPKI. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. 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-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki2opp-03.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: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ipki2opp-03.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: <19970917170340.I-D@ietf.org> [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 2 (EuSn/CSOm) (0001BF0C) Content-Type: Message/External-body; name="draft-ietf-pkix-ipki2opp-03.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-03 (AURL/Arch) (0001BF0D) Content-Type: text/plain Content-ID: <19970917170340.I-D@ietf.org> Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id FAA26818 for ; Mon, 22 Sep 1997 05:13:55 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 22 Sep 1997 12:15:34 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id JAA11448; Mon, 22 Sep 1997 09:19:56 -0700 Received: from gd2050.swissptt.ch by suntan.tandem.com (8.6.12/suntan5.970212) for id JAA11431; Mon, 22 Sep 1997 09:19:51 -0700 From: Received: from gd2zdk.swissptt.ch (138.190.170.105) by gd2050.swissptt.ch (MX F5.0) with SMTP; Mon, 22 Sep 1997 18:19:15 +0200 Received: by gd2zdk.swissptt.ch with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BCC784.257D7240@gd2zdk.swissptt.ch>; Mon, 22 Sep 1997 18:20:03 +0200 Message-ID: To: CC: Subject: FW: Coding of national characters? Date: Mon, 22 Sep 1997 19:19:12 +0200 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sparky.wovenword.com id FAA26818 Status: >As a European I understand your problem. But 2 wrongs don't make a right! >PrintableString is well-defined and shouldn't be misused either. ISO 8859-1 >is a good solution for European languages, but the question is: How should it >be coded? > >When will the Americans learn that there is a Rest-of-the-World? >Mit freundlichen Gr�ssen a Meilleures salutations w Kind regards >Viktor Steiner >[ viktor.steiner@swisscom.com | viktor.steiner@unisys.com ] > >---------- >From: lars.gu.johansson@posten.se[SMTP:lars.gu.johansson@posten.se] >Sent: 22 September 1997 10:58 >To: ietf-pkix@tandem.com >Subject: Coding of national characters? > >We have a problem... > >In PKIX part 1, chapter 4.1.2.4 "Issuer Name" the issuer field >(and the subject field similarly) is defined. There are no >mandatory X.520 attributes (like country or commonName etc) >but the the DirectoryString is defined in ASN.1 as: > >> DirectoryString ::= CHOICE { >> teletexString TeletexString (SIZE (1..maxSize)), >> printableString PrintableString (SIZE (1..maxSize)), >> universalString UniversalString (SIZE (1..maxSize)) > >Below this definition it is stated that: > >> The directoryString is defined as a choice of PrintableString, >> TeletexString 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 charater set is sufficient, >> the string string will be represented as a TeletexString; >> >> (c) failing (a) and (b), the string shall be represented as a >> UniversalString. > >The problem for us outside the US is how to encode national characters. >In Sweden for example, PrintableString which is equivalent to 7-bit ASCII >is not sufficient. According to the standard we would then make use of >teletexString which is equivalent to the T.61 character set. > >Now, T.61 is an old standard that is very seldomly used nowadays. In >particular neither Netscape Navigator nor Microsoft Internet Explorer >make use of T.61. > >Instead both Navigator and Explorer uses the character set in ISO 8859-1 >(Latin-1 which is equivalent to 8-bit ASCII). This character set is used for >both the PrintableString tag and the teletexString tag. > >Clearly the use of ISO 8859-1 in conjuction with the teletexString tag is an >error and some X.500 directories won't accept this. The effect would be >that searching these directories becomes impossible. > >The other alternative (ISO 8859-1 with the PrintableString tag) looks very >attractive IMHO and I would prefer that this solution were incorporated into >the standard. There are still problems however: many complilers based >on ASN.1 doesn't accept 8-bit characters in a PrintableString. > >Can anyone on this list see a solution to this problem? If so, I would >suggest >that the PKIX-1 draft is updated accordinly. > >Regards, >/Lars Johansson >Sweden Post > > Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id EAA25753 for ; Mon, 22 Sep 1997 04:29:17 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 22 Sep 1997 11:30:56 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id IAA03009; Mon, 22 Sep 1997 08:37:05 -0700 Received: from gatekeeper.entrust.com by suntan.tandem.com (8.6.12/suntan5.970212) for id IAA02991; Mon, 22 Sep 1997 08:37:02 -0700 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BCC74A.F87D4D80@mail.entrust.com>; Mon, 22 Sep 1997 11:30:47 -0400 Message-ID: From: Carlisle Adams To: "'Peter Williams'" Cc: "'ietf-pkix@tandem.com'" Subject: RE: Comments on [MANDATORY cert discovery capabiity] Date: Mon, 22 Sep 1997 11:30:45 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: Peter, >---------- >From: Peter Williams[SMTP:peter@verisign.com] >Sent: Friday, September 19, 1997 5:46 PM >To: Arsenault, Al W. >Cc: ietf-pkix@tandem.com >Subject: Re: Comments on [MANDATORY cert discovery capabiity] > I would personally remove from PKIX-III the "alternative directory >protocol" and >certificate/CRL distribution service it evidently forces on the world, >where said messeging is not for the above purposes. > >At least make it non-mandatory. > >" 4 Certificate/CRL discovery operations: some PKI management >operations result in the publication of certificates or CRLs: > 4.1 certificate publication: Having gone to the trouble of producing >a certificate some means for publishing it is needed. The "means" >defined in PKIX may involve the messages specified in Sections >3.3.13 - 3.3.16, or may involve other methods (LDAP, for example) as >described in the "Operational Protocols" part of this series (see >[PKIX-OP]). > 4.2 CRL publication: As for certificate publication. " > >But thankyou - I had never previously understood the relevance of >these messages to internet clients other than for simple notice/alert of >future status. I had never realised the capability >could be diverted for use to administering centralised access control >(and uses therefore) to keys at remote EEs via its management of compromise >status, and its mandatory status. > >yes - it seems that the 3.3.13 - 3.3.16 are attempting to >force PKIX-3 conforming implementations to adopt a >capability for users to use a non-directory mechanism for >certificate and CRL distribution. > >I argue hat this must be optional, for reasons along >many of the same lines that centralised key gen was made >optional. > >I am not in major disagreement; however certificate discovery support >should be removed from mandatory requirements. > >This is good discussion - we can now seemingly remove another mandatory >service element >designed for an atypical environment, though allow it to be optional. > >Anyone disagree with a motion to remove mandatory status from cert discovery >service elements current required for conformance to PKIX-3? I can't emphasize enough how helpful it would be to all of us if you would read what the document actually says before inventing something and repeating it at least seven times (as in the excerpts above from your previous posting). Nothing in the document states or even suggests that the certificate or CRL announcement PKIMessages are mandatory. Again I point you to Section 4 and Appendix B which profile the PKI management functionality, and corresponding PKIMessages, that MUST be supported. Again I ask you to notice that certificate announcement and CRL announcement are not there (i.e., they do not need to be supported by conforming implementations). Perhaps you might also look at 3.3.14 and 3.3.16, which specifically use the word "may" rather than "must". Perhaps you might also read the note given in 3.3.14, which says that the only reason the certificate announcement message exists at all is to cover those environments (if any!) in which there is no other way to publish certificates -- in other words, if you have another way to publish certificates, use it instead of this. Perhaps you might even look more carefully at the bullet points 4.1 and 4.2 from Section 1.3 (which you quoted above) that say that either 3.3.14 / 3.3.16 *or* the methods given in PKIX-OP can be used for certificate and CRL announcement (and in fact even this text uses the word "may", thus allowing for other options as well). Can you reproduce (and defend) the line of reasoning that led you to believe that 3.3.14 and 3.3.16 are mandatory? I would be willing to correct any text that leads to such a conclusion, but at the moment I can't find any text that needs correction... -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id DAA24682 for ; Mon, 22 Sep 1997 03:51:28 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 22 Sep 1997 10:53:07 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id IAA28739; Mon, 22 Sep 1997 08:16:38 -0700 Received: from igw2 by suntan.tandem.com (8.6.12/suntan5.970212) for id IAA28723; Mon, 22 Sep 1997 08:16:35 -0700 Received: from igw2.merck.com; Mon, 22 Sep 1997 11:03:56 -0400 Message-Id: <199709221503.LAA24192@igw2> Received: by ngatekeeper.merck.com via smap (3.1) id xmaxa1932; Mon, 22 Sep 97 10:59:20 -0400 Date: Mon, 22 Sep 1997 10:35:00 -0400 From: "Shah, Jay" Subject: unsubscribe To: ietf-pkix@tandem.com MIME-version: 1.0 Content-type: text/plain Status: unsubscribe Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id XAA17385 for ; Sun, 21 Sep 1997 23:26:11 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 22 Sep 1997 06:27:50 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id DAA01328; Mon, 22 Sep 1997 03:33:02 -0700 Received: from relay-1.mail.demon.net by suntan.tandem.com (8.6.12/suntan5.970212) for id DAA01325; Mon, 22 Sep 1997 03:32:58 -0700 Received: from secstan.demon.co.uk ([158.152.35.12]) by relay-1.mail.demon.net id aa0114096; 22 Sep 97 11:11 BST Comments: Authenticated sender is From: Nick Pope To: Simonetti David Date: Mon, 22 Sep 1997 11:08:06 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: encipherOnly and decipherOnly Key Usages CC: ietf-pkix@tandem.com Priority: normal In-reply-to: <9E7D9D26@asq8po2.bah.com> X-mailer: Pegasus Mail for Win32 (v2.53/R1) Message-ID: <874923088.0114096.0@secstan.demon.co.uk> Status: In reply to your message of 19 Sep 97, 10:30: As someone who was involved in the inital definition of this field in X.509, it was the intention to be able to use the key agreement key to encrypt a token. I don't believe that it was intended to place further restictions on how the data encrypted (in this case the token) may be used. I'm not sure I totally understand your question. If you are asking can a (preumeably symmetric) key held in the token be used for purposes other than encrypting a message, where the token was encrypted using the other parties public key agreement key provided though a certificate with the encipherOnly bit set, probably yes. If you can say a bit more about what you had in mind I will be happy to give my views. Nick Pope > I have a question on usage of the encipherOnly and decipherOnly key > usages. > Assume I use the pulic key agreement key to protect a token. The > token in > turn houses the message key that was used to encrypt the message. > Taking X.509 literally, setting encipherOnly means that the public key > agreement key shall only be used to encrypt the token. > > In my example, is it possible (is it correct) to interpret the > definition of encipherOnly to mean that I may only use the public key > of that certificate as part of the process to encrypt a message, > eventhough I am not directly using the public key agreement key to do > so? (And ditto for decipherOnly.) > > Dave Simonetti > Booz-Allen & Hamilton Inc. ------------------------------------- Security & Standards Suite A 191 Moulsham St. Chelmsford Essex CM2 0LG U.K. Tel: +44 1245 495018 Fax: +44 1245 494517 Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id VAA14902 for ; Sun, 21 Sep 1997 21:46:06 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 22 Sep 1997 04:47:45 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id BAA25566; Mon, 22 Sep 1997 01:58:42 -0700 Received: from argus.posten.se by suntan.tandem.com (8.6.12/suntan5.970212) for id BAA25544; Mon, 22 Sep 1997 01:58:36 -0700 From: Received: (from smap@localhost) by argus.posten.se (8.8.6/8.8.5) id KAA01537 for ; Mon, 22 Sep 1997 10:58:27 +0200 (MET DST) Received: from info(147.14.7.70) by argus via smap (V2.0) id xma001531; Mon, 22 Sep 97 10:58:14 +0200 Received: from hkmail.cph.posten.se (hkmail.cph.posten.se [147.14.142.201]) by info.posten.se (8.8.6/8.8.6) with ESMTP id KAA27229 for ; Mon, 22 Sep 1997 10:58:20 +0200 (METDST) Received: from localhost by hkmail.cph.posten.se with SMTP (1.39.111.2/16.2) id AA041818699; Mon, 22 Sep 1997 10:58:19 +0200 X-Openmail-Hops: 1 Date: Mon, 22 Sep 97 10:58:13 +0200 Message-Id: Subject: Coding of national characters? To: ietf-pkix@tandem.com Status: We have a problem... In PKIX part 1, chapter 4.1.2.4 "Issuer Name" the issuer field (and the subject field similarly) is defined. There are no mandatory X.520 attributes (like country or commonName etc) but the the DirectoryString is defined in ASN.1 as: > DirectoryString ::= CHOICE { > teletexString TeletexString (SIZE (1..maxSize)), > printableString PrintableString (SIZE (1..maxSize)), > universalString UniversalString (SIZE (1..maxSize)) Below this definition it is stated that: > The directoryString is defined as a choice of PrintableString, > TeletexString 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 charater set is sufficient, > the string string will be represented as a TeletexString; > > (c) failing (a) and (b), the string shall be represented as a > UniversalString. The problem for us outside the US is how to encode national characters. In Sweden for example, PrintableString which is equivalent to 7-bit ASCII is not sufficient. According to the standard we would then make use of teletexString which is equivalent to the T.61 character set. Now, T.61 is an old standard that is very seldomly used nowadays. In particular neither Netscape Navigator nor Microsoft Internet Explorer make use of T.61. Instead both Navigator and Explorer uses the character set in ISO 8859-1 (Latin-1 which is equivalent to 8-bit ASCII). This character set is used for both the PrintableString tag and the teletexString tag. Clearly the use of ISO 8859-1 in conjuction with the teletexString tag is an error and some X.500 directories won't accept this. The effect would be that searching these directories becomes impossible. The other alternative (ISO 8859-1 with the PrintableString tag) looks very attractive IMHO and I would prefer that this solution were incorporated into the standard. There are still problems however: many complilers based on ASN.1 doesn't accept 8-bit characters in a PrintableString. Can anyone on this list see a solution to this problem? If so, I would suggest that the PKIX-1 draft is updated accordinly. Regards, /Lars Johansson Sweden Post Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA23519 for ; Fri, 19 Sep 1997 10:19:47 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Fri, 19 Sep 1997 17:21:20 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id OAA18429; Fri, 19 Sep 1997 14:44:35 -0700 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id OAA18425; Fri, 19 Sep 1997 14:44:34 -0700 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id OAA22303; Fri, 19 Sep 1997 14:44:00 -0700 (PDT) Received: from pwilliams-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id OAA08450; Fri, 19 Sep 1997 14:43:59 -0700 (PDT) From: "Peter Williams" To: "Arsenault, Al W." Cc: Subject: Re: Comments on [MANDATORY cert discovery capabiity] Date: Fri, 19 Sep 1997 14:46:39 -0700 Message-ID: <01bcc545$828809a0$b603a8c0@pwilliams-pc.verisign.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0028_01BCC50A.D62931A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.0 Status: -----Original Message----- From: Arsenault, Al W. To: Arsenault, Al W. ; Peter Williams Cc: Carlisle Adams ; 'Charles Moore' ; 'ietf-pkix@tandem.com' Date: Friday, September 19, 1997 1:13 PM Subject: Re: Comments on > >Peter Williams wrote: > >>We should be clear that PKIX-CMP is not a scheme for managing certificate >>or CRL distribution. This is the function of part II wherein operational >>requirements are considered; different solutions are part of >>the concept of part II, precisly as operational enviornments are >>so different even on the public internet. > >>We have already discussed CRL push a few times. Many parties >>are working on models/systems for CRL push over microsoft and marimba >>channels. One expects these underlying transports to become true (versus >>simulated) push over time... > >>One can imagine IETF standardizing in part II a set of message formats >>for CRL push which are transport independent, and perhaps profile >>for transport over modern channel-distribution technologies, much >>as PKIX-3 specifies information objects, and a number of >>transport technologies. > > >Then would you ban from PKIX-CMP ALL: > > cert announcement messages > revocation announcement messages > CRL announcement messages > CA Key Update announcement messages > >or just unsolicited ones? I would do as we agreed - operational protocols concerning status go into PKIX-II, and management (mainly certification) protocols go into PKIX-III (CMP, and other bits of a multi-part document). Management of predicatable, periodic management operations for CA certs, and even notice concerning a user's own about-to-expire cert, is reasonable for PKIX-III. This alert/notice concerning predictable future-status is reasonable use of "management channels". I would personally remove from PKIX-III the "alternative directory protocol" and certificate/CRL distribution service it evidently forces on the world, where said messeging is not for the above purposes. At least make it non-mandatory. One can allow "PKIX-3's online-directory" to be overloaded on the definition of a "CA" (making such entities rather more like an permanently online Key management Center, than a largely offline X.509 CA) only where highly centralised admin needs happen to prevail in the intended operational environment. " 4 Certificate/CRL discovery operations: some PKI management operations result in the publication of certificates or CRLs: 4.1 certificate publication: Having gone to the trouble of producing a certificate some means for publishing it is needed. The "means" defined in PKIX may involve the messages specified in Sections 3.3.13 - 3.3.16, or may involve other methods (LDAP, for example) as described in the "Operational Protocols" part of this series (see [PKIX-OP]). 4.2 CRL publication: As for certificate publication. " But thankyou - I had never previously understood the relevance of these messages to internet clients other than for simple notice/alert of future status. I had never realised the capability could be diverted for use to administering centralised access control (and uses therefore) to keys at remote EEs via its management of compromise status, and its mandatory status. > >If you want them all banned, then how does that affect the functionality of >PKIX-CMP? Would PKIX-CMP by itself still be sufficient for its purposes, or >would you require PKIX-CMP plus some (sub)set of PKIX-2? Your labelling of the issue as "banning" clearly deserves a comment about the legitimate purpose and scope of PKIX-III - which is defined to be a cert management service and accompanying protocol framework. It is surely not a key management service, nor a key recovery service per se; though it can clearly work in conjunction with such services particularly when, sometimes, the issued certs are addressing confidentiality and data flow control problems. Such problems are not the only problem set, however; many CAs in the Internet PKI are quite likely to serve authentication needs only. We clearly cannot make a cert mgt service which suits every operational need, those with rigorous requirements for unifed key/cert management are one group, and those which are using persona-fun certificates are another, for example. Nor, from the style of the comments received on the issue of previously-mandatory centralised key generation support, would the WG seems to favour a general direction to FORCE a link and mandatory deployed capability between cert management and other related key-management functions, including online CA-based revocation/comrpomised alerting. Certificates and their management service need to roam free to serve purely authentication-only purposes, and their CA may well be accessed only via offline transports. > >If you just want unsolicited announcements banned (i.e., these messages >would still be supported for use in specific circumstances during the >certificate management process), how can that be efficient? You would be >duplicating functionality by having the same things - cert announcements, >CRL announcements, etc. - implemented twice just to support some notion of >"protocol purity". Lets deal with this language, and consider internet standards goals. We have to recall that standards evolve and some parts are used in one environment and other parts in other enviornments. Its a toolkit. We are not designing here a national PKI/KMI/KRI. Rather we are setting standards for an "internet-management-cultured" PK infrastructure whose precise use and enviornment is rather unknown. Interworking is the goal, not uniformity of acess, or some particular quality(s) of service; this will evolve over time as residential/organizational/personal/ ... usage patterns are determined. Many EEs will also use propiretary or USgovt specified KM I or KRI protocols, also. We have to recall that we are fundamentally a X.509 group. The model of that standard is directory-centric, with offline CAs. One performs certificate management at the outset of a relationship with a CA, then one uses a directory to manage the certs thereafter. This model is built into the semantics; they are wholly cert-centric servifng to distribute authentication keys; not key-centric to control key usage by application protocols. In PKIX architcture, this comes down to a separtion of function - part III for initialization/registration/certification, and use of Part II to embrace various kinds of directories (ldap, http, and "real-time" so far). If one is renewing ones encryption cert, sure the CA should be able to alert you that your signature key expires next week. (Many CA-linked directories may well do the same as part of their competitive value-add.) yes - it seems that the 3.3.13 - 3.3.16 are attempting to force PKIX-3 conforming implementations to adopt a capability for users to use a non-directory mechanism for certificate and CRL distribution. I argue hat this must be optional, for reasons along many of the same lines that centralised key gen was made optional. Such interaction with a common cert discovery/alert services more naturally happens at layer protocols - e.g. SKIP, S/MIME, SSL etc if these implementations do not use directories for the same. SKIPs interface to a notice databased maintained by the CA concerning status of CA-cert foo, should happen in the natural SKIP way, protected via IPSEC. Similarly SSL, etc. > >Personally, I'd rather let those who want to support these announcements >using PKIX-CMP do so, if it simplifies their software architecture. Then >use the appropriate PKIX-2 delivery mechanism to distribute these >announcements. I am not in major disagreement; however certificate discovery support should be removed from mandatory requirements. Those entities which maintain constant online contact with a CA, can use that CA's PKIX-3 object discovery/announcement sub-protocol to determine (pending) status of certs and CRLs. An offline news reader program checking signature on mails should not be forced to implement such capability, however, for nothing; a CA which only offers weekly certs again should not be forced to provide the communications port for this online element of service. Many CAs will be wholly offline, and based on email or floppy transport only for the interaction with the CA. This is good discussion - we can now seemingly remove another mandatory service element designed for an atypical environment, though allow it to be optional. Anyone disagree with a motion to remove mandatory status from cert discovery service elements current required for conformance to PKIX-3? > > > Al Arsenault > > - speaking only for myself > > > Peter. Attachment converted: Lutefisk:Peter Williams.vcf (TEXT/R*ch) (0001BEDC) Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA20424 for ; Fri, 19 Sep 1997 08:19:56 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Fri, 19 Sep 1997 15:21:29 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id NAA04473; Fri, 19 Sep 1997 13:13:55 -0700 Received: from guardian.guard.ncsc.mil by suntan.tandem.com (8.6.12/suntan5.970212) for id NAA04464; Fri, 19 Sep 1997 13:13:54 -0700 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id QAA02047 for ; Fri, 19 Sep 1997 16:13:32 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma002040; Fri Sep 19 16:13:17 1997 Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.53.166]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id QAA23415 for ; Fri, 19 Sep 1997 16:10:24 -0400 Received: from smtpgw.missi.ncsc.mil (unverified [144.51.54.211]) by mimesweeper.missi.ncsc.mil (Integralis SMTPRS 2.02) with SMTP id ; Fri, 19 Sep 1997 16:14:46 -0400 Received: by smtpgw.missi.ncsc.mil with Microsoft Mail id <3422DE28@smtpgw.missi.ncsc.mil>; Fri, 19 Sep 97 16:18:48 EDT From: "Arsenault, Al W." To: "Arsenault, Al W." , Peter Williams Cc: Carlisle Adams , "'Charles Moore'" , "'ietf-pkix@tandem.com'" Subject: Re: Comments on Date: Fri, 19 Sep 97 16:13:00 EDT Message-Id: <3422DE28@smtpgw.missi.ncsc.mil> Encoding: 53 TEXT X-Mailer: Microsoft Mail V3.0 Status: Peter Williams wrote: >We should be clear that PKIX-CMP is not a scheme for managing certificate >or CRL distribution. This is the function of part II wherein operational >requirements are considered; different solutions are part of >the concept of part II, precisly as operational enviornments are >so different even on the public internet. >We have already discussed CRL push a few times. Many parties >are working on models/systems for CRL push over microsoft and marimba >channels. One expects these underlying transports to become true (versus >simulated) push over time... >One can imagine IETF standardizing in part II a set of message formats >for CRL push which are transport independent, and perhaps profile >for transport over modern channel-distribution technologies, much >as PKIX-3 specifies information objects, and a number of >transport technologies. Then would you ban from PKIX-CMP ALL: cert announcement messages revocation announcement messages CRL announcement messages CA Key Update announcement messages or just unsolicited ones? If you want them all banned, then how does that affect the functionality of PKIX-CMP? Would PKIX-CMP by itself still be sufficient for its purposes, or would you require PKIX-CMP plus some (sub)set of PKIX-2? If you just want unsolicited announcements banned (i.e., these messages would still be supported for use in specific circumstances during the certificate management process), how can that be efficient? You would be duplicating functionality by having the same things - cert announcements, CRL announcements, etc. - implemented twice just to support some notion of "protocol purity". Personally, I'd rather let those who want to support these announcements using PKIX-CMP do so, if it simplifies their software architecture. Then use the appropriate PKIX-2 delivery mechanism to distribute these announcements. Al Arsenault - speaking only for myself Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id HAA18610 for ; Fri, 19 Sep 1997 07:05:45 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Fri, 19 Sep 1997 14:07:18 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id LAA22644; Fri, 19 Sep 1997 11:48:45 -0700 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id LAA22634; Fri, 19 Sep 1997 11:48:43 -0700 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id LAA19652; Fri, 19 Sep 1997 11:48:04 -0700 (PDT) Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA01398; Fri, 19 Sep 1997 11:47:59 -0700 (PDT) Message-ID: <3422C982.D73FFB26@verisign.com> Date: Fri, 19 Sep 1997 11:50:42 -0700 From: Peter Williams Reply-To: peter@verisign.com Organization: verisign X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: "Arsenault, Al W." CC: Carlisle Adams , "'Charles Moore'" , "'ietf-pkix@tandem.com'" Subject: Re: Comments on References: <3422AD68@smtpgw.missi.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: Arsenault, Al W. wrote: > > > This may be a matter of semantics, but we'll see. I believe that there is a > need for a CA, RA, other entity to send out "unsolicited response" messages. > That is, a CA may want to send a CRLannounce message to users, even though > users have not asked for them, because local policy dictates that you push a > new CRL out whenever a key has been determined to be compromised. If one > regards such messages to be "response" messages, then the current PKIX-CMP > is acceptable. If one regards such a message to be a "distribution message > that was not a request or response", then that concept needs to be > supported. We should be clear that PKIX-CMP is not a scheme for managing certificate or CRL distribution. This is the function of part II wherein operational requirements are considered; different solutions are part of the concept of part II, precisly as operational enviornments are so different even on the public internet. We have already discussed CRL push a few times. Many parties are working on models/systems for CRL push over microsoft and marimba channels. One expects these underlying transports to become true (versus simulated) push over time... One can imagine IETF standardizing in part II a set of message formats for CRL push which are transport independent, and perhaps profile for transport over modern channel-distribution technologies, much as PKIX-3 specifies information objects, and a number of transport technologies. Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id EAA15252 for ; Fri, 19 Sep 1997 04:56:34 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Fri, 19 Sep 1997 11:58:06 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id JAA00282; Fri, 19 Sep 1997 09:45:55 -0700 Received: from guardian.guard.ncsc.mil by suntan.tandem.com (8.6.12/suntan5.970212) for id JAA00274; Fri, 19 Sep 1997 09:45:52 -0700 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id MAA00497 for ; Fri, 19 Sep 1997 12:45:31 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma000493; Fri Sep 19 12:45:23 1997 Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.53.166]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id MAA21674 for ; Fri, 19 Sep 1997 12:42:31 -0400 Received: from smtpgw.missi.ncsc.mil (unverified [144.51.54.211]) by mimesweeper.missi.ncsc.mil (Integralis SMTPRS 2.02) with SMTP id ; Fri, 19 Sep 1997 12:46:47 -0400 Received: by smtpgw.missi.ncsc.mil with Microsoft Mail id <3422AD68@smtpgw.missi.ncsc.mil>; Fri, 19 Sep 97 12:50:48 EDT From: "Arsenault, Al W." To: Carlisle Adams , "'Charles Moore'" , "'ietf-pkix@tandem.com'" Subject: RE: Comments on Date: Fri, 19 Sep 97 12:45:00 EDT Message-Id: <3422AD68@smtpgw.missi.ncsc.mil> Encoding: 96 TEXT X-Mailer: Microsoft Mail V3.0 Status: Responding to Charles Moore, Carlisle Adams wrote: >Hi Charles, >>ADD to 3.1.2 PKI Message Body >>Add an additional branch be added to the CHOICE. The >>additional branch would be: >> >> other [48] SEQUENCE { >> oid OBJECT IDENTIFIER, >> value ANY DEFINED BY oid } >> >>The tag number does not concern me. >> >>RATIONAL: Missed in update >I didn't mean to overlay too much semantic intent on my choice of the >name "GenReq" in this submission; I simply meant "request" to represent >any unsolicited message going out from an entity ("response", on the >other hand, was a solicited message, a reply to a message that was >received). >In any case, I can see why this might not be clear, so I'm willing to >add another branch to CHOICE. Can I make it perfectly general and >specify it as a SET OF {OID,value} pairs (as was added to PKIHeader)? For what it's worth, I agree with the suggestions from Charles and Russ. I'm in the process of trying to plan a migration of my hierarchy from an existing "custom" certificate management protocol to PKIX-CMP. My current protocol has (and my users will continue to need) a variety of messages dealing with things like firmware updates for hardware tokens, special "lists" of compromised keys, etc. These are almost certainly of no interest to most PKIX-CMP users. However, from my somewhat selfish viewpoint, it's a heck of a lot easier to implement PKIX-CMP, plus a few locally-defined "other" message, than it is to implement PKIX-CMP, and then add an extra protocol to do the rest of the stuff. I believe that the format that Charles and Russ suggested is the best/easiest/clearest way to do this. Re: SET OF {OID, value} pairs: I don't care about this. I'm going to implement as "one PKIX-CMP-extended message at a time". If you want to have the ability to send "multiple locally-defined messages at a single time", fine. I don't see any need for it, but others might. >By the way, one comment from your posting yesterday. You said "The >requested extension had the ability to define the symantics of the >operation, such as a distribution message that was not a request or >response." Note that PKIX-CMP is inherently a point-to-point protocol >for the explicit purpose of doing certificate management functions; I >don't think that distribution messages fit within this framework. This may be a matter of semantics, but we'll see. I believe that there is a need for a CA, RA, other entity to send out "unsolicited response" messages. That is, a CA may want to send a CRLannounce message to users, even though users have not asked for them, because local policy dictates that you push a new CRL out whenever a key has been determined to be compromised. If one regards such messages to be "response" messages, then the current PKIX-CMP is acceptable. If one regards such a message to be a "distribution message that was not a request or response", then that concept needs to be supported. >>REPLACE >>CertificateValidityDate ::= CHOICE { >> utcTime UTCTime, >> generalTime GeneralizedTime >> } >> >>WITH >>CertificateValidityDate ::= GeneralizedTime >> >>RATIONAL: There is no need to support the legacy UTCTime in the request. >This is only used in the certificate template and it's only there >because that's the way certificates are currently specified. In other >words, it was specified that way so that the template could be >constructed to look exactly like the requester wanted the certificate to >look. >I believe someone on the list requested this. If nobody has previously requested this, I'll make such a request now. I want to support the operational scenario where a new user creates his own to-be-signed-certificate, in the exact format (to include the user-generated public key :-) that the user desires the end product to look like - the only thing missing would be the CA's signature. The CA will then examine the certificate, determine that it is acceptable, sign it, and send it back. If the CA has to do a time-format change, that's an unnecessary burden that just slows down processing. Al Arsenault - speaking only for myself. Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id DAA12656 for ; Fri, 19 Sep 1997 03:16:03 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Fri, 19 Sep 1997 10:17:36 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA12472; Fri, 19 Sep 1997 07:55:19 -0700 Received: from foxhound.cisco.com by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA12464; Fri, 19 Sep 1997 07:55:18 -0700 Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id HAA22058 for ; Fri, 19 Sep 1997 07:54:46 -0700 (PDT) X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Sep 1997 07:54:35 -0700 To: ietf-pkix@tandem.com From: Fred Baker Subject: Costs of Mandatory Key Recovery Status: If you could email any hard numbers as to expected costs to Don Heath , it would be helpful. >>Date: Wed, 17 Sep 1997 10:55:55 -0400 >>From: Philip Webre >>To: heath@isoc.org >>Subject: Costs of Mandatory Key Recovery >>Content-Disposition: inline >> >>As I explained over the telephone, we are trying to estimate >>the private sector costs associated with mandatory key >>recovery in the US. Thursday the House Intelligence >>Committees passed an amended version of HR 695 that >>would mandate immediate key recovery in all encryption >>products sold, imported or distributed in the US after >>January 31, 2000. It further imposes this requirement >>on Internet service providers who provide encryption >>services when presented by a warrant from a duly authorized >>law enforcement official. >> >>We expect that within an organization like a corporate >>LAN, key recovery can be mandated in a straight forward >>manner. But since the relationship between an ISP >>and its client is more distant, very different mechanisms >>and cost structure would surface. I would be very >>interested in any information you could provide regarding >>the costs associated with such a mandate. >> >>Address: >>Philip Webre >>Congressional Budget Office >>Natural Resources and Commerce Division >>495 Ford House Office Bldg. >>Washington, D.C. 20515 >>Fax Number: 202-226-0207 >>Voice: 202-226-2940 >>Internet: Philipw@CBO.GOV > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Planning is bringing the future into the present so that you can do something about it now." Alan Lakein Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id CAA12143 for ; Fri, 19 Sep 1997 02:55:35 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Fri, 19 Sep 1997 09:57:07 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA07102; Fri, 19 Sep 1997 07:16:05 -0700 Received: from ietf.org by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA07098; Fri, 19 Sep 1997 07:16:04 -0700 Received: from ietf.ietf.org by ietf.org id aa07305; 19 Sep 97 9:46 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-pkix@tandem.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ipki3cmp-04.txt Date: Fri, 19 Sep 1997 09:46:19 -0400 Sender: cclark@ietf.org Message-ID: <9709190946.aa07305@ietf.org> 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-04.txt Pages : 69 Date : 1997-09-17 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-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki3cmp-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: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ipki3cmp-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: <19970917155743.I-D@ietf.org> [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 1 (EuSn/CSOm) (0001BE9F) Content-Type: Message/External-body; name="draft-ietf-pkix-ipki3cmp-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-ipki3cmp- 1 (AURL/Arch) (0001BEA0) Content-Type: text/plain Content-ID: <19970917155743.I-D@ietf.org> Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id CAA12129 for ; Fri, 19 Sep 1997 02:52:56 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Fri, 19 Sep 1997 09:54:29 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA08814; Fri, 19 Sep 1997 07:28:09 -0700 Received: from gatekeeper.entrust.com by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA08809; Fri, 19 Sep 1997 07:28:08 -0700 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BCC4E5.F401BA00@mail.entrust.com>; Fri, 19 Sep 1997 10:22:37 -0400 Message-ID: From: Carlisle Adams To: "'ietf-pkix@tandem.com'" , "'Charles Moore'" Subject: RE: Comments on Date: Fri, 19 Sep 1997 10:22:36 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: Hi Charles, >---------- >From: Charles Moore[SMTP:cmoore@signet.org.au] >Sent: Thursday, September 18, 1997 5:11 PM >To: ietf-pkix@tandem.com >Subject: Comments on > >REPLACE: >2.2.2 Mandatory schemes > >The criteria above allow for a large number of initial registration / >certification schemes. This specification mandates that conforming CA >equipment, RA equipment, and EE equipment must support the second >scheme listed below. Any entity may additionally support other schemes, >if desired. > >WITH >The criteria above allow for a number of initial registration / >certification schemes. This specification does not mandate a particular >scheme, but describes two schemes in the following sections. Any entity >may support these or other schemes, if desired. >A future PKIX specification will support key generation protocol >requirements. > >RATIONAL: Document agreements. This is analogous to the discussions on algorithms heard so often in various IETF Working Groups, and the reasoning here is identical. There must be at least one mandatory method otherwise you lose guaranteed interoperability. Just like every WG has had to pick a particular algorithm and say "you can support a million algs if you want, but you MUST support this one", I think we have to do the same with initialization schemes. >REPLACE >2.2.2.1 Centralized scheme > >In terms of the classification above, this scheme is, in some ways, >the simplest possible, where: > >- initiation occurs at the certifying CA; >- no on-line message authentication is required; >- "key generation" occurs at the certifying CA (see Section 2.2.1.3); >- no confirmation message is required. > >WITH >2.2.2.1 Centralized scheme > >In this scheme: > >- initiation occurs at the CA or RA entity; >- no on-line message authentication is required; >- "key generation" occurs at the RA or CA entity; >- no confirmation message is required. > >RATIONAL: Changes to align with stated requirements in previous sections >to allow generation at the RA. This scheme is chosen to represent the "simplest possible" scheme, where only one PKIMessage is sent in the initialization process. As soon as you expand it to allow an RA, you break this and go back to at least 3 (possibly 4) messages. Previous sections of course talk about key generation at the RA (or elsewhere), but this particular scheme, like the basic authenticate scheme, is one specific configuration out of all the ones that could have been chosen. >ADD to 3.1.2 PKI Message Body >Add an additional branch be added to the CHOICE. The >additional branch would be: > > other [48] SEQUENCE { > oid OBJECT IDENTIFIER, > value ANY DEFINED BY oid } > >The tag number does not concern me. > >RATIONAL: Missed in update I didn't mean to overlay too much semantic intent on my choice of the name "GenReq" in this submission; I simply meant "request" to represent any unsolicited message going out from an entity ("response", on the other hand, was a solicited message, a reply to a message that was received). In any case, I can see why this might not be clear, so I'm willing to add another branch to CHOICE. Can I make it perfectly general and specify it as a SET OF {OID,value} pairs (as was added to PKIHeader)? By the way, one comment from your posting yesterday. You said "The requested extension had the ability to define the symantics of the operation, such as a distribution message that was not a request or response." Note that PKIX-CMP is inherently a point-to-point protocol for the explicit purpose of doing certificate management functions; I don't think that distribution messages fit within this framework. >REPLACE >CertificateValidityDate ::= CHOICE { > utcTime UTCTime, > generalTime GeneralizedTime > } > >WITH >CertificateValidityDate ::= GeneralizedTime > >RATIONAL: There is no need to support the legacy UTCTime in the request. This is only used in the certificate template and it's only there because that's the way certificates are currently specified. In other words, it was specified that way so that the template could be constructed to look exactly like the requester wanted the certificate to look. I believe someone on the list requested this. -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id CAA11906 for ; Fri, 19 Sep 1997 02:51:36 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Fri, 19 Sep 1997 09:53:02 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA08574; Fri, 19 Sep 1997 07:26:30 -0700 Received: from booz-mail.bah.com by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA08570; Fri, 19 Sep 1997 07:26:28 -0700 Received: from bah.com (smtpnt-al1.bah.com [156.80.9.200]) by booz-mail.bah.com (8.8.7/8.7.3) with SMTP id KAA06735 for ; Fri, 19 Sep 1997 10:25:53 -0400 (EDT) Date: Fri, 19 Sep 1997 10:30 -0500 From: "Simonetti David" To: ietf-pkix@tandem.com Subject: encipherOnly and decipherOnly Key Usages Message-ID: <9E7D9D26@asq8po2.bah.com> Status: I have a question on usage of the encipherOnly and decipherOnly key usages. Assume I use the pulic key agreement key to protect a token. The token in turn houses the message key that was used to encrypt the message. Taking X.509 literally, setting encipherOnly means that the public key agreement key shall only be used to encrypt the token. In my example, is it possible (is it correct) to interpret the definition of encipherOnly to mean that I may only use the public key of that certificate as part of the process to encrypt a message, eventhough I am not directly using the public key agreement key to do so? (And ditto for decipherOnly.) Dave Simonetti Booz-Allen & Hamilton Inc. Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA17085 for ; Thu, 18 Sep 1997 08:58:44 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Thu, 18 Sep 1997 16:00:17 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id OAA14996; Thu, 18 Sep 1997 14:08:25 -0700 Received: from ntdev.signet.org.au by suntan.tandem.com (8.6.12/suntan5.970212) for id OAA14983; Thu, 18 Sep 1997 14:08:21 -0700 Received: by NTDEV with Internet Mail Service (5.0.1457.3) id ; Fri, 19 Sep 1997 07:11:25 +1000 Message-ID: <416170F33BD2D011A3A000C06C57717101CB44@NTDEV> From: Charles Moore To: ietf-pkix@tandem.com Subject: Comments on Date: Fri, 19 Sep 1997 07:11:23 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Status: REPLACE: 2.2.2 Mandatory schemes The criteria above allow for a large number of initial registration / certification schemes. This specification mandates that conforming CA equipment, RA equipment, and EE equipment must support the second scheme listed below. Any entity may additionally support other schemes, if desired. WITH The criteria above allow for a number of initial registration / certification schemes. This specification does not mandate a particular scheme, but describes two schemes in the following sections. Any entity may support these or other schemes, if desired. A future PKIX specification will support key generation protocol requirements. RATIONAL: Document agreements. REPLACE 2.2.2.1 Centralized scheme In terms of the classification above, this scheme is, in some ways, the simplest possible, where: - initiation occurs at the certifying CA; - no on-line message authentication is required; - "key generation" occurs at the certifying CA (see Section 2.2.1.3); - no confirmation message is required. WITH 2.2.2.1 Centralized scheme In this scheme: - initiation occurs at the CA or RA entity; - no on-line message authentication is required; - "key generation" occurs at the RA or CA entity; - no confirmation message is required. RATIONAL: Changes to align with stated requirements in previous sections to allow generation at the RA. ADD to 3.1.2 PKI Message Body Add an additional branch be added to the CHOICE. The additional branch would be: other [48] SEQUENCE { oid OBJECT IDENTIFIER, value ANY DEFINED BY oid } The tag number does not concern me. RATIONAL: Missed in update REPLACE CertificateValidityDate ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime } WITH CertificateValidityDate ::= GeneralizedTime RATIONAL: There is no need to support the legacy UTCTime in the request. Charles Moore Signet Systems Pty Ltd Phone: +61 7 3256 7465 Fax: +61 7 3256 6794 Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA17052 for ; Thu, 18 Sep 1997 08:52:09 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Thu, 18 Sep 1997 15:53:42 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id NAA09224; Thu, 18 Sep 1997 13:32:50 -0700 Received: from ntdev.signet.org.au by suntan.tandem.com (8.6.12/suntan5.970212) for id NAA09208; Thu, 18 Sep 1997 13:32:45 -0700 Received: by NTDEV with Internet Mail Service (5.0.1457.3) id ; Fri, 19 Sep 1997 06:35:47 +1000 Message-ID: <416170F33BD2D011A3A000C06C57717101CB43@NTDEV> From: Charles Moore To: Carlisle Adams , "'ietf-pkix@tandem.com'" Subject: RE: PKIX-CMP Date: Fri, 19 Sep 1997 06:35:45 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Status: > -----Original Message----- > From: Carlisle Adams [SMTP:carlisle.adams@entrust.com] > Sent: Thursday, 18 September 1997 2:03 > To: 'ietf-pkix@tandem.com' > Subject: PKIX-CMP > > Hi, > > I [Charles Moore] --deleted > 5) Charles Moore requested hooks for extensibility in the PKIBody > (this > was also requested by Russ Housley in a later message to the list). > It > turns out that the extensibility was already there; it just wasn't > obvious. (The PKIInfoReqContent and PKIInfoRepContent bodies are SETs > of {OID,value} pairs and so immediately fill the requirement.) > [Charles Moore] This is a different solution to what was requested. > Your solution has fixed symantics of request and response. > The requested extension had the ability to define the symantics of the > operation, such as a distribution message that was not a request or > response. > > I have > renamed these to GenReqContent and GenRepContent to emphasize their > general nature and have explicitly stated (see p.35) that these may be > used to define new request and response messages for future needs or > for > specific environments. > [Charles Moore] That is good, but is not related to the requested > change. > If the original request ( Russ solution is ok) could be added that > would be great. > > -------------------------------------------- > Carlisle Adams > Entrust Technologies > cadams@entrust.com > -------------------------------------------- > > > Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id DAA08161 for ; Thu, 18 Sep 1997 03:10:36 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Thu, 18 Sep 1997 10:12:08 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id HAA11775; Thu, 18 Sep 1997 07:21:34 -0700 Received: from ietf.org by suntan.tandem.com (8.6.12/suntan5.970212) for id HAA11772; Thu, 18 Sep 1997 07:21:33 -0700 Received: from ietf.ietf.org by ietf.org id aa06695; 18 Sep 97 9:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-pkix@tandem.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ipki3cmp-04.txt Date: Thu, 18 Sep 1997 09:50:03 -0400 Sender: cclark@ietf.org Message-ID: <9709180950.aa06695@ietf.org> 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-04.txt Pages : 69 Date : 1997-09-17 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-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki3cmp-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: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ipki3cmp-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: <19970917155743.I-D@ietf.org> [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-pkix- (EuSn/CSOm) (0001BE92) Content-Type: Message/External-body; name="draft-ietf-pkix-ipki3cmp-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-ipki3cmp-04 (AURL/Arch) (0001BE93) Content-Type: text/plain Content-ID: <19970917155743.I-D@ietf.org> Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA11840 for ; Wed, 17 Sep 1997 08:19:24 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Wed, 17 Sep 1997 15:20:55 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id NAA21493; Wed, 17 Sep 1997 13:13:35 -0700 Received: from gatekeeper.entrust.com by suntan.tandem.com (8.6.12/suntan5.970212) for id NAA21487; Wed, 17 Sep 1997 13:13:33 -0700 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BCC383.C9AAFE50@mail.entrust.com>; Wed, 17 Sep 1997 16:07:25 -0400 Message-ID: From: Carlisle Adams To: "'ietf-pkix@tandem.com'" , "'Peter Williams'" Subject: RE: PKIX-CMP Date: Wed, 17 Sep 1997 16:07:24 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: Hi Peter, >---------- >From: Peter Williams[SMTP:peter@verisign.com] >Sent: Wednesday, September 17, 1997 2:28 PM >To: Carlisle Adams; ietf-pkix@tandem.com >Subject: Re: PKIX-CMP > ><> > >>1) Centralized key generation (i.e., at the CA) is now optional; the >>"basic authenticated scheme" is the only mandatory initialization >>scheme. > >Please explain this. What does it mean, and what are the consequences >and the rationale? > >What is an initialization scheme? Re-read Section 1.3 item 3.1, Section 2.2.1.1, Section 2.2.1.2, and Section 2.2.2.2 (they're all short) and see if this helps. If not, ask again. All we're saying is that out-of-band means are used to bootstrap the process. >Preconditions: >1. The end entity can authenticate the CA=92s signature based on out-of- >band means >2. The end entity and the CA share a symmetric MACing key" > >And I ask myself (and hopefully it will be answered in response to >my non-leading question) how does one bootstrap the PKIX-CMP? > >I.E. How does one obtain satisfaction of the pre-conditions? > >Are these non-standard mechanisms shared between particular >entities using one bit of software, and some subsection of the >operational CAs also using that bit of software? "Out-of-band" simply means out of band. That is, information is passed between the EE (that wants to join the PKI) and the PKI entity (CA or RA) in a way not specified in this document. It might be a physical visit; it might be physical mail; it might be a telephone call; it might be e-mail; it might be a guy in a trenchcoat with a briefcase handcuffed to his wrist. [Whatever policy dictates.] As long as that information exchange is separate from the PKIX-CMP protocols, and is "trustable" by both sides, that's fine. Part of that out-of-band information might be the CA's public key (to satisfy precondition 1). Alternatively, the out-of-band information might only be secret information (a password) from which each side can derive a MACing key using PasswordBasedMac (this satisfies precondition 2, and when this key is used to protect the CMP initialization messages, then the CA can send its public key in the response, which satisfies precondition 1). I guess I'm not sure which part of all this you're questioning or not understanding... -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id GAA09484 for ; Wed, 17 Sep 1997 06:47:51 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Wed, 17 Sep 1997 13:49:21 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id LAA06197; Wed, 17 Sep 1997 11:27:03 -0700 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id LAA06181; Wed, 17 Sep 1997 11:26:57 -0700 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id LAA16011; Wed, 17 Sep 1997 11:26:23 -0700 (PDT) Received: from pwilliams-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA11850; Wed, 17 Sep 1997 11:26:19 -0700 (PDT) From: "Peter Williams" To: "Carlisle Adams" , Subject: Re: PKIX-CMP Date: Wed, 17 Sep 1997 11:28:53 -0700 Message-ID: <01bcc397$8cfcff80$b603a8c0@pwilliams-pc.verisign.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_004E_01BCC35C.E0968660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1703.0 X-MimeOle: Produced By Microsoft MimeOLE V4.71.1703.0 Status: >1) Centralized key generation (i.e., at the CA) is now optional; the >"basic authenticated scheme" is the only mandatory initialization >scheme. Please explain this. What does it mean, and what are the consequences and the rationale? What is an initialization scheme? (Im trying to ask open, non-leading questions; please do not abuse the questioner for so asking; assume the list requires tutoring) ------ Here is my understanding, and why Im bothering to comment. "B8.2 Basic authenticated scheme The end entity requests a certificate from a CA. When the CA responds with a message containing a certificate the end entity replies with a confirmation. All messages are authenticated. This scheme allows the end entity to request certification of a locally- generated public key (typically a signature key). The end entity may also choose to request the centralised generation and certification of another key pair (typically an encryption key pair). Certification may only be requested for one locally generated public key (for more, use separate PKIMessages). The end entity must support proof-of-possession of the private key associated with the locally-generated public key. Preconditions: 1. The end entity can authenticate the CA=92s signature based on out-of- band means 2. The end entity and the CA share a symmetric MACing key" And I ask myself (and hopefully it will be answered in response to my non-leading question) how does one bootstrap the PKIX-CMP? I.E. How does one obtain satisfaction of the pre-conditions? Are these non-standard mechanisms shared between particular entities using one bit of software, and some subsection of the operational CAs also using that bit of software? Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Attachment converted: Lutefisk:smime.p7s 11 (????/----) (0001BE7C) Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id EAA06359 for ; Wed, 17 Sep 1997 04:46:27 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Wed, 17 Sep 1997 11:47:57 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id JAA11781; Wed, 17 Sep 1997 09:07:35 -0700 Received: from gatekeeper.entrust.com by suntan.tandem.com (8.6.12/suntan5.970212) for id JAA11777; Wed, 17 Sep 1997 09:07:33 -0700 Received: tid MAA11700; Wed, 17 Sep 1997 12:05:05 -0400 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BCC361.9C5213C0@mail.entrust.com>; Wed, 17 Sep 1997 12:02:46 -0400 Message-ID: From: Carlisle Adams To: "'ietf-pkix@tandem.com'" Subject: PKIX-CMP Date: Wed, 17 Sep 1997 12:02:45 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: Hi, I have just submitted PKIX Certificate Management Protocols (used to be PKIX-3, but it was agreed in Munich that part numbers were to be removed from the various documents) to the Internet-Drafts address -- it should show up soon at the usual repositories. I believe this draft is now ready for last call, as agreed in Munich and reiterated (after some debate) recently on this list, and have asked the chairs to issue this call once the document is readily available. The changes incorporated are as follows. 1) Centralized key generation (i.e., at the CA) is now optional; the "basic authenticated scheme" is the only mandatory initialization scheme. 2) It is noted (see pages 10 and 21) that a general key generation request/response protocol, and that a PKCS #7 protection mechanism, may be specified in separate documents. 3) AlgIDs, references, and modulus lengths (where appropriate) have been given for all mandatory algorithms in Appendix B; see p.49. 4) In re-reading Section 4, I discovered that we were mandating "certificate update" (a new certificate for an existing key) as opposed to "key update" (a new certificate for a new key); see p.40 of the previous draft. [A slight cut-and-paste error that must have happened ages ago -- I'm surprised no one noticed this earlier...] This has been fixed (and Appendix B has been updated to support this). 5) Charles Moore requested hooks for extensibility in the PKIBody (this was also requested by Russ Housley in a later message to the list). It turns out that the extensibility was already there; it just wasn't obvious. (The PKIInfoReqContent and PKIInfoRepContent bodies are SETs of {OID,value} pairs and so immediately fill the requirement.) I have renamed these to GenReqContent and GenRepContent to emphasize their general nature and have explicitly stated (see p.35) that these may be used to define new request and response messages for future needs or for specific environments. 6) Rich Ankney, in conjunction with the above, requested extensibility in the individual messages as well, either in PKIHeader or in each PKIBody. It seemed to make more sense to put it in the header, so I have added an OPTIONAL SET OF {OID,value} pairs there. That's it, other than general editing/formatting/typo cleanup. -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- > Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id QAA16446 for ; Mon, 15 Sep 1997 16:57:40 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 15 Sep 1997 23:59:03 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id WAA21774; Mon, 15 Sep 1997 22:04:02 -0700 Received: from ntdev.signet.org.au by suntan.tandem.com (8.6.12/suntan5.970212) for id WAA21766; Mon, 15 Sep 1997 22:03:58 -0700 Received: by NTDEV with Internet Mail Service (5.0.1457.3) id ; Tue, 16 Sep 1997 15:06:48 +1000 Message-ID: <416170F33BD2D011A3A000C06C57717101CB22@NTDEV> From: Charles Moore To: Russ Housley , Warwick Ford Cc: ietf-pkix@tandem.com Subject: RE: PKIX Part I - Name Constraints Date: Tue, 16 Sep 1997 15:06:46 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Status: > -----Original Message----- > From: Russ Housley [SMTP:housley@spyrus.com] > Sent: Tuesday, 16 September 1997 0:34 > To: Warwick Ford > Cc: ietf-pkix@tandem.com > Subject: Re: PKIX Part I - Name Constraints > > At 08:07 PM 9/13/97 -0400, Warwick Ford wrote: > >>2. To deal with the exception that you propose, we need to add a > >>dependency between rfc822 alt names and X.500 Distinguished Names. > I do > >>not like this if we can avoide it. > > > >RFC822 names in altnames are not impacted. They are treated exactly > as in > >the standard. In fact, nothing related to the standard is impacted. > What > >I am proposing is simply one additional rule that PKIX imposes, which > is a > >perfectly reasonable thing for a profile to do. If there is an > RFC822 name > >constraint in force, we just impose one further check on the Subject > field. > > Very straightforward to implement (if you are already implementing > name > >constraint logic). > > > >Without this rule, I believe that many early Name Constraints > >implementations will have a major loophole. I think it is a PKIX > >obligation to provide the rules to secure the migration from the old > ways > >to the new ways. > > [Charles Moore] I think there are two separate issues here a) the > attribute support within the DN and b) the support for name forms. > > With regard to the first, PKIX should NOT limit support, all > implementations should be able to support any attributes here ( it > really not a big deal). The support for RSA SMIME is but one example > and should not be singled out within PKIX. But I would agree that if > there is support for the PKCS9 e-mail attribute then these should be > constant with RFC822, but others may have a different view. > > With regard to b) DN's are ok, altnames are ok as well, PKIX should > not force a particular implementation choice, just ensure support for > both forms is available. > > > > I would like to encourage the fastest possible migration to the use of > alt > names. And, I agree that we need to accomodate fielded solutions > during > that transition. > > In addition to changes in the name constraints section, a forward > pointer > should probably be added to section 4.1.2.6 too. > > Do you have proposed text? > > Russ Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA09450 for ; Mon, 15 Sep 1997 12:17:20 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 15 Sep 1997 19:18:43 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id RAA22079; Mon, 15 Sep 1997 17:12:17 -0700 Received: from smtp3.erols.com by suntan.tandem.com (8.6.12/suntan5.970212) for id RAA22073; Mon, 15 Sep 1997 17:12:15 -0700 Received: from rhousley_pc.spyrus.com (spg-as30s43.erols.com [207.172.46.234]) by smtp3.erols.com (8.8.6/8.8.5) with SMTP id UAA28635; Mon, 15 Sep 1997 20:12:12 -0400 Message-Id: <3.0.3.32.19970915103425.006a2a30@nile.spyrus.com> X-Sender: rhousley@nile.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 15 Sep 1997 10:34:25 -0400 To: Warwick Ford From: Russ Housley Subject: Re: PKIX Part I - Name Constraints Cc: ietf-pkix@tandem.com In-Reply-To: <3.0.32.19970913190725.00774c18@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: At 08:07 PM 9/13/97 -0400, Warwick Ford wrote: >>2. To deal with the exception that you propose, we need to add a >>dependency between rfc822 alt names and X.500 Distinguished Names. I do >>not like this if we can avoide it. > >RFC822 names in altnames are not impacted. They are treated exactly as in >the standard. In fact, nothing related to the standard is impacted. What >I am proposing is simply one additional rule that PKIX imposes, which is a >perfectly reasonable thing for a profile to do. If there is an RFC822 name >constraint in force, we just impose one further check on the Subject field. > Very straightforward to implement (if you are already implementing name >constraint logic). > >Without this rule, I believe that many early Name Constraints >implementations will have a major loophole. I think it is a PKIX >obligation to provide the rules to secure the migration from the old ways >to the new ways. I would like to encourage the fastest possible migration to the use of alt names. And, I agree that we need to accomodate fielded solutions during that transition. In addition to changes in the name constraints section, a forward pointer should probably be added to section 4.1.2.6 too. Do you have proposed text? Russ Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id JAA04625 for ; Mon, 15 Sep 1997 09:11:37 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 15 Sep 1997 16:12:59 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id MAA06574; Mon, 15 Sep 1997 12:40:47 -0700 Received: from caladan.verisign.com by suntan.tandem.com (8.6.12/suntan5.970212) for id MAA06568; Mon, 15 Sep 1997 12:40:44 -0700 Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id MAA12519; Mon, 15 Sep 1997 12:40:10 -0700 (PDT) Received: from pwilliams-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA04822; Mon, 15 Sep 1997 12:39:59 -0700 (PDT) From: "Peter Williams" To: "Mike Smith" Cc: Subject: Re: Policy Contraints Object Identifier Date: Mon, 15 Sep 1997 12:42:42 -0700 Message-ID: <01bcc20f$884bd3a0$b603a8c0@pwilliams-pc.verisign.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA-1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_009F_01BCC1D4.DBDC32C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1703.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1703.0 Status:

-----Original Message-----
From: Mike Smith <mfsmith@zionsbank.com>
To: jduffy@bbn.com <jduffy@bbn.com>; peter@verisign.com <peter@verisign.com>
Cc: ietf-pkix@tandem.com <ietf-pkix@tandem.com>
Date: Friday, September 12, 1997 8:04 AM
Subject: Re: Policy Contraints Object Identifier

>Policy mapping would imply re-issuance to get the new mappings onto the required certs. I believe this is a classic case for cross certification for each (BBN and GTE) authority, recognizing the root public key as a CA in their own hierarchy (if they have a hierarchy) or chain (web) of trust.
>
>Michael

Mike,

In the last 7 years, I have heard that offline cross-certification will
seemingly "solve" any cert domain- or management problem one cares to
characterise; its a magic bullet to be loaded & fired whenever a trust or
recovery (vs issuing) scenario is encountered. Under controlled management,
I'm not so sure this one-stop-shopping experience is quite so
sound as many make out. Lets look more deeply based on v. large-scale
environments which have received much actual analysis. (Just
as 1422 contained a domain-model and rationale, perhaps PKIX 1 (or 3)
needs to embrace some guidance on the authority/naming structures
anticipated for Internet PKI scenarios.)

I was (indirectly) thinking about a DoD ops concept when I wrote the
problem statement. It is expected that, every ~2 years, service men and
women will become based in new localities, even though their home
regiment, or core, or other organizational unit, stays constant
during the move, as does their personal rank and title.

This is a lot of regular name changing, either in the directory indexes,
or the names in certs, if cert subject-names convey any
locality info.

In a token-centric world, this means given your troops
a (re)new(ed) Fortezza-card (or RSA smartcard) every two years.
While you are at this expensive task, issue them a new cert (or
two) when they get to the new base and commence their
new job in a new command.

I do not imagine a cross-certification scenario here. Rather,
its more of a periodic re-org, where everyone gets new names/tokens, and
any associated privileges due to the change in their enviornment/job.

Many corporate mergers are re-orgs (and sometimes mass
layoffs/revocations) versus friendly merging of assets, know-how, etc.
Firing 2000 people overnight makes for a large CRL in the morning
even if you rehire 1900 of them next day on new contracts
with a new corporate identity.

As I say, this second-order domain management control is a fun topic. The
more you regulate it with complex name schemas, and perform key management,
based upon name-management dynamics, the more intractable it becomes even
with the support of a well-managed centralised and ubiquitous directory
performing name management (not certificate/CRL distribution).

In a "prototype" "Internet PKI" we have been running in
the PKI industry for 2 years now we had a philosophy of - keep names out
of the picture until momentum has built to undersatnd the obvious value of
certs per se: name management debates are endless! When its time (i.e the
market expects more and greater discretionay control) move to
schematise naming as an option to those local domains who desire
name-based controls.

It may be time to clean up all our acts generally on names, now that there
is a discerning corporate/organizational market attaching itself to the
residential PKI and the evolving, open management infrastructure for
inter-domain secured interworking.

Peter.

>
>>>> Peter Williams <peter@verisign.com> 09/11/97 03:55PM >>>
>>
>> >Thanks,
>> >Jean Duffy
>> >
>> >GTE Internetworking
>> >Powered by BBN
>
>
>I know BBN an GTE have been off and on friends for years; but
>its still a little sad for us Internet types to see any diminishment
>of the BBN name!
>
>Corporate mergers of this sort are, of course, common.
>
>Lets say BBN has issued 50,000 certs to employees, and GTE corporate
>dictum now wanted to change everyone over to [a-z]*@bbn.gte.com. (I
>do not know if they do or do not.)
>
>Obviously one way to do it is to revoke and reissue all certs (and
>handle 50,000 tokens if token-based).
>
>Another way is to revoke the BBN CA(s), and start again with
>new trust points.
>
>How would PKIX technology migrate folk intelligently? A policy mapping, or
>name mapping in a renewed BBN CA certificate, perhaps?
>
>This is a fun topic, after all the recent fuss. It will
>not be long before someone has to deal with precisely
>this scenario.
>
> !
>
>

Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Attachment converted: Lutefisk:smime.p7s 9 (????/----) (0001BDF7) Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id DAA27855 for ; Mon, 15 Sep 1997 03:10:56 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 15 Sep 1997 10:12:19 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id GAA13684; Mon, 15 Sep 1997 06:54:58 -0700 Received: from guardian.guard.ncsc.mil by suntan.tandem.com (8.6.12/suntan5.970212) for id GAA13680; Mon, 15 Sep 1997 06:54:55 -0700 Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id JAA09196 for ; Mon, 15 Sep 1997 09:54:34 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma009192; Mon Sep 15 09:54:07 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id JAA00660 for ; Mon, 15 Sep 1997 09:51:14 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id JAA14066; Mon, 15 Sep 1997 09:53:07 -0400 Date: Mon, 15 Sep 1997 09:53:07 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199709151353.JAA14066@argon.ncsc.mil> To: ietf-pkix@tandem.com Subject: Re: PKIX Part I - Name Constraints X-Sun-Charset: US-ASCII Status: > From: Warwick Ford > > I wish to propose a minor addition to 4.2.1.11 (Name Constraints) of PKIX > Part I. > > Regarding RFC822Name, the most common way to convey an e-mail address today > is as a PKCS#9 e-mail attribute in the subject DN. Migration to > subjectAltNames will undoubtedly occcur in time, and the profile correctly > covers that future. However, to ensure that the intent of Name Constraints > is met given current styles of naming, I propose that we additionally state > that "Restrictions for the rfc822 name form shall also apply to any > instance of the PKCS#9 E-mail Name attribute type present in a subject DN." I agree with the proposal. But that brings up the question of which name representations are "better" from a design perspective. My uninformed intuition suggests that name forms like email addresses, locally-defined (SDSI-type) names, the "persistent IDs" discussed here a few months back, as well as other AltName forms such as IP addresses/DNS names/URIs, would be most cleanly represented as Distinguished Names, with AttributeType OIDs (such as the PKCS#9 email attribute) defined for each type. This would: 1) put all name forms in a common data structure, reducing the need to parse separate data structures depending on the name type, 2) eliminate the "null-DN" problem, 3) allow directory operations (search & retrieval) based on alternative name forms to make use of the existing DN search machinery, 4) eliminate the need for the above suggestion on consistent email name form restrictions, since there would be only one place an email name could occur (a DN attribute), and 5) eliminate the need for changing the GeneralName structure to add additional name types (such as SDSI names) to the existing 9 types. Alternatively, if all future naming requirements are to be satisfied by lumping them into "otherName" and registering OIDs for new otherName types, then I don't see why the same effect cannot be better achieved by registering the new OIDs as DN attributes instead. Can someone explain the rationale for preferring the GeneralName extension over DN attributes, and in particular why new applications should migrate away from including email addresses in DNs? For the case where multiple different names are needed for a single entity, a structure like: Names ::= SEQUENCE OF Name could replace the need for GeneralNames. In fact, if the "subjectAltName" and "issuerAltName" extensions were replaced by new versions that used "SYNTAX Names" instead of "SYNTAX GeneralNames", then the extension would be needed ONLY in the case where a subject had 2 or more name forms. Entities such as PGP subjects who have only an RFC822 name would not be relegated to second-class status, using a null DN and the subjectAltName extension. Return-Path: Received: from consensus.com (consensus.com [157.22.1.143]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id CAA27568 for ; Mon, 15 Sep 1997 02:57:37 -0700 Received: from suntan.tandem.com (192.216.221.8) by consensus.com with SMTP (Eudora Internet Mail Server 1.2); Mon, 15 Sep 1997 09:59:00 -0700 Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id GAA13005; Mon, 15 Sep 1997 06:47:20 -0700 Received: from gatekeeper.entrust.com by suntan.tandem.com (8.6.12/suntan5.970212) for id GAA13000; Mon, 15 Sep 1997 06:47:18 -0700 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BCC1BB.983CFC70@mail.entrust.com>; Mon, 15 Sep 1997 09:41:51 -0400 Message-ID: